(Try it out at http://www.ludumdare.com/compo/ludum-dare-29/?action=preview&uid=11177 !)

Last night, I was quite tired and decided to call it ‘done’. The first thing this morning, I checked the comments and saw a crash notice… Great. Well, turned out to be a really small thing in the end. Now, time for an early post-mortem!

The first thing that comes to my mind is that I should have done a lot more work during the first 24 hours. I slacked, doing about 8 hours of work, and it backfired on Sunday. I had planned for tons of features (namely, more enemies, more defenses, and a repair function for defenses), but as time went by, I had to scrap most of them and focus to get single things to work.

The second problem was that while I had laid out the basic code design in my head before I started coding, it didn’t work out as intended. In the end, I had to write exceptions and exceptions of exceptions in order to get everything to work – not something you’d like to see in your code, especially if you’re going to maintain it later on. Some things were fixed so delicately that after I saw them finally working (for example, the way workers enable turrets to be built), I was afraid to touch the code so I wouldn’t break it again.

On a more positive note, I surprised myself at how quickly I was able to make the graphics and sounds. In total, I probably used about three hours drawing the graphics, and about an hour making the music and sound effects. Granted, there’s not that many sound effects involved, but still.

One thing I especially liked about was the water. I’ve always struggled with animating water, or even creating nice-looking, non-animated water. This time, I used just single-colored, semi-transparent blue planes, stacked and slightly animated to move up and down and rotate a bit. I was surprised how well it worked considering how simple it was!

So, what have I learned?

• Making graphics for this kind of game is surprisingly fast.
• Code should be refactored / redesigned / repurposed multiple times during the first 24 hours. Later on, broken code causes even more broken code.
• 48 hours is both a short and a long time. Flesh out all ideas you can, but prepare to scrap most of them and focus on the core things first. If you have time, adding more stuff shouldn’t be that difficult if you’ve prepared for it.

All in all, I’m pretty satisfied about the results. The code is at awful state, and if I’m going to continue on this, I have to spend a lot of time cleaning and restructuring the code first. Most of the worker and defense code should be erased and re-written.

I’m also thinking of porting this for Android. Whaddya think?

Tags: post-mortem