Game Hours: 409.25(previous two years) + 117.5 (current year) = 526.75 / 1000 Game Ideas: 710 (previous two years) + 36 (current year) = 746 / 1000
I spent part of my week making the goal look obviously different from the obstacles in the game. If you’re wondering why I bothered, you should read Game Design for the Color Blind Player.
I spent the other part of my week in crunch at the day job or resting from it.
[tags]game, game design, productivity, personal development, video game development, indie[/tags]
Overall, my game placed very low. Still, I managed to come away with the gold medal for my journal and the bronze medal for my food entries. My timelapse video came in 4th place. I rule at participation.
I intend to rule LD#13 in December, though. I’m going to spend the next couple of months getting ready for it.
Game Hours: 409.25(previous two years) + 116 (current year) = 525.25 / 1000 Game Ideas: 710 (previous two years) + 36 (current year) = 746 / 1000
I had every intention of working at least an hour each day to guarantee that I’ll have at least five hours by Saturday. Instead, crunch hit at the day job, and badly. I was working on Saturday and Sunday for the first time in…months? That’s sad.
I made a little progress, so that’s good, but eating, sleeping, and working at the day job is taking up most of my time, and I’d rather not take away from the only things keeping me healthy.
[tags]game, game design, productivity, personal development, video game development, indie[/tags]
My 2nd Ludum Dare didn’t go as well as my first. While I managed to get Tower Defender submitted, it can’t be called a game so much as a tech demo.
What Went Right:
Simple game mechanics still work.
Like my LD#11 Minimalist entry, I wanted to use simple mouse-movement-only controls. I feel that mousing over your units to make them attack made sense, and while I only had archers available in the end, it seemed to work. It’s too bad there wasn’t more of a game built around the mechanic, but I intend to flesh it out after LD.
I had an office door I could close.
My cats are incredibly reliable. If I am doing anything that looks like productivity, they will insist on sitting on my lap, resting on my arms, and otherwise preventing me from working. Being able to close the door on them helped keep me focused on game development. Towards the end I got lax about keeping the door closed, but the cats left me to work for the most part.
Using Test-Driven Development
Test-Driven Development, or TDD, is great for designing your code. Also, since code changes often, you can feel confident that your changes won’t break functionality since your tests will tell you if they did break. More than once, I was surprised that a seemingly innocuous change resulted in failing tests, so I was able to keep the game working at all times. I know that I wouldn’t have caught one specific crash problem right away, and it might have resulted in a non-working game for hours, preventing me from submitting anything. Since I found those problems sooner, even in code that wasn’t directly being tested, I felt that using TDD was the right thing to do.
What Went Wrong:
Learning Test-Driven Development while using it.
I know quite a few people would disagree with the use of TDD during Ludum Dare, but I think what burned me was my inexperience with implementing it. I spent too much time trying to figure out how to apply it to rewriting code that I already had written. My first bunch of tests were helpful, but all I ended up with at the end was a slightly smaller Game class with a separate Timer class, and it seemed that if I applied TDD to the entire project I would barely have an SDL window by the end. While my normal projects might benefit from test-driven design, my LD game needed to get finished in 48 hours, so I had to alternate between writing tests first and skipping tests. I’m sure once I get some TDD experience, I’ll be much faster and know when it is in appropriate to write tests. For LD#12, it was a learning experience.
I still didn’t have a good handle on SDL
Last LD, I noted that I hadn’t practiced using SDL much, and right before LD#12 started, I realized that I still hadn’t done so. I never had to render animated sprites in SDL before, and I skipped it in favor of static images moving around, but not before spending precious time learning what I would need to do it. Again, there was too much wrestling with technology instead of game development, and this time it prevented me from finishing my game.
Working long hours really does screw with your productivity
It’s common in the programming world to find people working Twelves, especially in the game development industry. Crunch times are intuitive. If a project needs to get done in a week, and there are two weeks of work to be done, then have everyone work longer each day. Well, it is common knowledge, even if that knowledge isn’t applied, that working longer hours doesn’t translate into greater productivity.
I experienced these issues firsthand with the 2nd day of LD#12. I realized I had worked about 12 hours straight by the end, and I was making sillier and sillier mistakes. Sometimes my tests would save me, but since I didn’t write tests for a good portion of my code, I had to figure out what I did wrong most of the time. Bugs were finding their ways into my code a lot easier, and debugging was painful. When I did LD#11, I got plenty of sleep and took frequent breaks, and ended up with a finished game. I wonder if I could have done LD#12 better if I took a few more decent breaks during that 12 hour stretch.
I didn’t get game play until the very last minute.
I knew that getting game play up as quickly as possible was important, especially in a timed competition, and yet I believe I struggled so much with the technology that the game didn’t start to form until I had minutes left to package it up and submit it. I think if I had used a few more hours in a productive way, I could have made something enjoyable.
What I Learned:
I still have a lot to learn.
It’s weird when you feel confident going into a competition like this and then hit a wall due to your own lack of knowledge. I was depending on TDD, SDL, and common game programming concepts such as OnMouseOver, but I didn’t have much experience with them before this competition started. I like using LD as a learning experience, but next time I’ll focus on learning only one tech or tool for LD at a time.
Test-Driven game development is awesome.
Yes, the learning curve slowed my productivity down, but I already saw many benefits from using a test-first design for my coding. I could see that my code base was going to be much better for it, particularly in terms of my ability to make cross-platform games, but I had to stop applying it due to time constraints. I was already trying to incorporate TDD into my main development before LD, but now I see that it’s going to provide better benefits than I originally thought.
I need to work on my pacing for LD.
It seems most of my productive work happens during the 2nd half of Ludum Dare, and it makes me wonder what happened during the first 24 hours. I saw that more than a few people had working prototypes up and running within a matter of hours, and I want to make sure my future LD entries are in a playable state as early as possible, too.
Once again, 48 hours resulted in a bunch of code and experience I didn’t have before the weekend started. Even though my submission can’t really be called a game, it has potential, and I had a lot of fun working on it. The next LD is in December. A few months should give me time to develop my skill and technology base.
I was rereading Programming Linux Games the other day. I love rereading books because there will always be something that you didn’t notice the first few times through. This time, I learned two ways to render sprites much more efficiently than I was currently doing. I had heard about these two techniques, especially from my first readings, but I forgot about them.
Understanding colorkeys
In Chapter 4, Mastering SDL, John Hall talked about setting colorkeys to simulate transparency when drawing sprites. If you’ve ever seen the image files in many games and tutorials, you’ll notice that they aren’t transparent images. See Aaron Cox’s sprite tutorial for an example. Usually the sprite being rendered will be surrounded by a certain color, sometimes hot pink, but no matter what, there is a color instead of complete transparency. The reason why the sprites render as if they are transparent is because that color is set as the colorkey, and SDL knows not to render it.
Why not just use alpha values in an image? You get the same effect, right? While the end result might look the same, the amount of processing power you need is not the same. To render alpha values properly, there are calculations needed for each pixel. The surrounding pixels are taken into account, and the final value is determined before the color is set. With colorkeys, the pixel is either rendered or not rendered.
If you have a game in which it is possible for many sprites to overlap, calculating alpha blending for otherwise blank areas of multiple sprites will slow down rendering time. Maybe faster computers won’t even blink, but you might be increasing your game’s minimum hardware requirements needlessly.
Understanding Display Format
SDL allows you to load images from a file into an SDL_Surface. To render them to your screen, which is also a surface, you simply blit them together using SDL_BlitSurface(). Hall also warns that doing so with slightly incompatible surfaces can slow down rendering. If your sprite is in one format, and your screen is in another, SDL must convert the sprite to the screen’s format before rendering. It does this transparently so you don’t need to specify anything, but do you really need to do these calculations every time it renders?
No. SDL_DisplayFormat() will take a surface and return a surface that is in a format that is optimal for fast blitting to your screen.
Here’s what threw me off. My code was organized like so:
if (!isSDLVersionUpToDate() ||
!initializeSDL() ||
!initializeWindow()) ||
{
My code first checks to make sure you have an up-to-date SDL version on your system. Assuming that’s cool, it initializes SDL using SDL_Init() and gets my program ready. Then it creates the window and sets up my main screen surface for rendering.
All fine and good, except my sprites were getting loaded in initializeSDL(). (NOTE: Yes, this is bad. The name of the function didn’t indicate that it was also loading sprites. I was the one who wrote this code, and I was the one getting burned by it). When I tried to change my sprite loading code, SDL_DisplayFormat() kept returning NULL, which indicates failure. Why was it failing, though?
After asking on IRC and doing research online, I found out why. SDL_DisplayFormat() converts your surface into an optimal format for fast blitting to the screen. Well, until you create a screen, how does it know what that format should be? In my code, SDL_SetVideoMode() gets called in initializeWindow(), which was after the sprites got loaded, so of course SDL_DisplayFormat() would fail. It didn’t know what the optimal format would be because we hadn’t created the format target! Well, that’s an easy fix. I just moved the sprite loading code to its own function, which I called AFTER initializeWindow(). Now SDL_DisplayFormat() returns a valid surface.
Of course, I hadn’t set the colorkey yet, and I wasn’t ready to make the changes to the graphics as it was getting late, so to make sure my game otherwise looked the same, I changed all calls to SDL_DisplayFormat() to SDL_DisplayFormatAlpha(). Now it converts the surface to allow for faster blitting, and it handles alpha transparency correctly. It isn’t the most efficient, but it is definitely an improvement over what I had before. I still intend to convert my transparent images to opaque ones that get rendered properly using colorkeys since there is still a performance gain there.
Hopefully, my efforts helped someone out there, if only by allowing them to play games without needing to spend the money on upgrading hardware.
Game Hours: 409.25(previous two years) + 114.5 (current year) = 523.75 / 1000 Game Ideas: 710 (previous two years) + 36 (current year) = 746 / 1000
I managed a few hours of development this past week, which is quite a few less than I expected to do, but progress is progress. I reorganized my subversion repositories with the goal of separating common libraries into their own project that can be included by my own projects. Before this change, each project was in its own repository, and they had the same build scripts for the same custom libraries, which was a lot of duplication. Subversion has something called svn:externals which allows my checked out project to essentially include a different project under it. It should be pretty handy for common tools, scripts, and code across projects.
I finally got around to changing the drawing of the goal in Minimalist from a blue filled rectangle to an actual sprite image.
I want it to animate with the text spinning around it, but the important thing is that it does a better job of standing out from the red rectangles.
Also, I would like to change the name of the game. Minimalist got its name from the theme of Ludum Dare #11, but I think the game should be named something more appropriate. I’m thinking Walls, since the game now features obstacles that close in on you.
[tags]game, game design, productivity, personal development, video game development, indie[/tags]
If you’ve ever discussed copyright infringement, indie game business models, or even chess with Cliffski, you would know that he vehemently HATES so-called piracy. In fact, if you even argue that it isn’t the same as stealing and that piracy is a silly name for it, get ready to be flamed.
Or maybe you don’t have to worry about it as much. In a move that surprised many, he wrote a blog post asking “Why do people pirate my games?” in which he invited people to explain their true motivations. In fact, it would have been expected if he would have turned around and tried to prosecute anyone who admitted it to him, but instead, true to his word, he kept an open mind, and came away with some lessons.
He details what he learned in Talking to Pirates, and he’s changing some aspects of his business.
A big one: No DRM.
I only used DRM for one game (Democracy 2) and it’s trivial. It’s a one-time only internet code lookup for the full version. I’ve read enough otherwise honest people complain about DRM to see that its probably hurting more than it help’s. I had planned on using the same system for Kudos 2, but I’ve changed my mind on that. I have also removed it from Democracy 2 today. I now use no DRM at all.
Again, I’m surprised that of all the indies out there, Cliffski was the one to not only ask why people prefer to not pay for his games but also listen to the responses, but I’m pleased. I know that I’ve made these arguments, that people don’t like DRM because they don’t like being treated as a criminal, but I’ve been dismissed before as not knowing what I talk about. Now Cliffski comes and does this, and getting rid of DRM is justified as good for business? Huh. Who’d have thunk it?
I suppose even if he didn’t get this beneficial feedback, his sales would still pick up significantly from getting the publicity from Slashdot and Digg. Whether or not he expected to get this much traffic from this article, or such good feedback, I don’t know, but hopefully we’ll find out soon.
Game Hours: 409.25(previous two years) + 110.25 (current year) = 519.50 / 1000 Game Ideas: 710 (previous two years) + 36 (current year) = 746 / 1000
Wow, I did a lot of game development this past weekend! Ludum Dare #12 wasn’t a big success for me, but I’ll have more to say in a post-mortem of Tower Defender. Along with my LD#11 entry, Minimalist, I intend to properly finish these games and release them. Minimalist should hopefully be out by the end of August at the latest.
[tags]game, game design, productivity, personal development, video game development, indie[/tags]
My first time lapse was over 10 minutes long, and so I had to cut out a lot of the repetitive images to shorten it. I also found a way to combine music with it.
Unfortunately I only got game play in at the last few minutes, and there are problems. For one, there is no way to win or lose. The enemies don’t know that they’ve already stormed the walls and will keep going until they hit the sky, but they do this cool floating thing…which is a bug. Mousing over the archers will make them fire arrows, and they take a bit of time to reload before letting you fire again. The arrows do hit the enemies and make them disappear.
the other day. I love rereading books because there will always be something that you didn’t notice the first few times through. This time, I learned two ways to render sprites much more efficiently than I was currently doing. I had heard about these two techniques, especially from my first readings, but I forgot about them. 
