Ludum Dare 48h game contest, post mortem on 'orbital sniper'   The standard 'gamasutra' formula for postmortems contains 5 things that have gone right and 5 things that have gone wrong, so here we go. What went right Simple idea   When deciding on the game idea I automatically discarded all the ideas that would be either content-bound or that would require lots of tweaking to make a sensible game. This meant dropping all 3d games, for example, because I didn't feel like doing collision detection, and I didn't know whether the 'ludiengine' would be enough. In any case, 2d art is easier to do than 3d.   I actually ran out of features to implement. Right now I have plenty of ideas how to turn orbital sniper into an actual full-blown game, but about 8 hours before the end of the contest, the game was essentially done. Enough sleep & food   I slept the 6 first hours of the competition, and 8 hours in the middle. This let me keep my head and spend most of the competition time doing more or less sane code.   While others seem to have written some game frameworks beforehand, I spent my time preparing food. I could have cooked even more food beforehand or gone microwave, but instead I spent a total of 4 hours just cooking during the contest. This gave me time to think things over and not do stupid things. Also, it enabled me to work without being hungry. =) Deciding not to make OOP code   Because the game didn't explicitly require any OOP code, I decided to make everything global. The resulting code is rather ugly and while it caused some problems when doing the 'new game' feature, it enabled me to make fast and straight changes to the way the code works without having to refactor the codebase, and thus saved time. SDL   In the end, SDL was everything I needed to make a game. Controls, framebuffer, audio and image loading. And it's very easy to use as well. If I had been doing a 3d game instead, I would probably have written it on dx7 instead. #ludumdare   The IRC channel, which I only used briefly in the beginning and a lot later on, was a great help; in the beginning someone told me how to implement the mouse wheel support in SDL (which is unobvious), and in the end people told me things that are irritating in the game, enabling me to fix some of those.   The game would have no sound or play again options if someone on the channel hadn't mentioned about doing them.   I think I made the right decision not to hang on IRC from the beginning, in order to get the work done. What went wrong Not enough playtesting   While the game was complete, I didn't do enough playtesting, and the game ramps from being boring (in the beginning, for experienced players) to being too hard (too early, for inexperienced players) pretty quickly. I did some gameplay tweaking in the last 8 hours and ended up uploading 4 different versions on the server; the last version is pretty decent. Too infrequent backups   At one point my machine crashed and I lost the 'main' cpp file. The last backup batch I had done was 6 hours old, so I lost all my audio code and some of the gameplay tweaks. Luckily I remembered most of those, and reimplementing sound only took about 30 minutes. Keeping time log also helped, as I could see what main features I had worked on after the backup had been made. SDL debugging   I was inexperienced in debugging under SDL. I managed to spend a total of 2 hours finding one fatal bug in the code; 30 minutes of which was spent rewriting the audio code. If I had known about the SDL_INIT_NOPARACHUTE flag earlier, I might have caught the bug earlier. Underestimating the power of modern PCs   Having concentrated on programming low-power handheld devices recently, I was surprised to find that most things that I did had no effect of any kind on the framerate. I originally planned on doing some 256 pedestrians, for the fear that their AI code would eat too much CPU power. As a joke, I threw 16384 of them in, and the game still ran at a decent speed. I dropped the count down to 1536 since that looked good. Another thing was that I ran the AI code 20 times per second originally; I upped that to 100hz and it had no noticeable effect on the framerate either.   I might have saved some time by not bothering to do all that fixed point math stuff in the beginning. Work the next day   Going to work after crunching a game all weekend, and being awake at 4am on moday morning, was a bit of a killer. Project stats 2502 lines of code, totalling 82704 bytes, of which 16516 bytes in comments (19.970%). 30e spent on groceries (most of which was not consumed during the contest, though) Equipment used: Development machine 800MHz p3 with 768MB RAM and GeForce3 Canon powershot S10 (for audio) Ancient, crappy & cheapo casio(?) microphone The game can be downloaded from here (1101280 bytes); the zip contains all binaries and source code, plus my time log. Comments are appreciated.
Site design & Copyright © 2008 Jari Komppa