This was my third (completed) entry to the ludum dare 48 hour game design contest. Drawing from the experience on the last two entries, I tried to keep the entry simple and ended up spending relatively small amount of time actually working on the entry, concentrating on the essentials.
Using SDL and fmod yet again let me concentrate on the game. The game itself does not plot a single pixel, but mostly consists of filled rectangles. Only two image-based things exist in the game, namely the font printer and the help screen, both of which are implemented using simple blits.
I've been thinking about some 'ground rules', following which would make the survival in ludum dare easier. I wrote the rules down after the contest, and they're available at http://iki.fi/sol/ldsurvival.html - I almost managed to follow all of them this time.
I didn't have any really great idea when the theme was announced, so I decided to make a toy first. The game itself kind of followed naturally.
Although I didn't do much game testing, the gameplay ended up being surprisingly good. Some people have commented that it's addictive, and the different stages let people set the starting difficulty to be suitable to their skill and/or controller (such as wacom or touchpad instead of mouse).
Before the contest I did some research on generated music and found a couple of fractal-based music tools. Thus, I was able to 'compose' the rather repetitive tense.mid for the game. The sound effects came out surprisingly well. I used my webcam microphone (which is one of those 'auto-gain' ones, a feature that apparently can't be switched off) and audacity to edit the sounds. The audio frequency thingies I've learned in school helped somewhat as well in the editing.
There are a couple of mistakes in the code (for instance, I implemented the noise function wrong, and so on), but I'm not aware of any actual bugs. I didn't spend significant time hunting any specific bugs during the whole contest. I attribute this to the 'ground rules' mentioned before.
While the gameplay may be good, it's rather repetitive, and eventually gets old. Based on the gameplay theory, the game shouldn't be boring or frustrating; this 'flow' state appears at around stage 10. More gameplay testing would have revealed this and I could have set the start stage there. The game becomes pretty impossible at around stage 20. This could have been avoided with further gameplay testing and tuning, stretching the 'flow' state further.
I could have spent the whole 48 hour contest just tweaking the visuals. Instead, I just whipped something together and didn't touch it afterwards. The result is what you can see. I thought about implementing motion blur, glow effects etc, and would have had time to do all those things as well, but decided to take it easy instead. I think I was a bit afraid to touch the visuals, as when you get above a certain "level", it no longer looks like "good crappy graphics" but "crappy good graphics" =)
The coordinate system in the game is a bit confusing. I'd tell you how confusing it is, but I've already forgotten how it works. Good thing is, it does, but it would make it rather difficult to add more stuff to the game.
The portability of the game would have been tiny bit better if I would have bothered porting it to some other platform during the contest. I didn't, so I missed one fmod call in the AUDIO_ENABLED blocks. Thus, if you want to compile the game without fmod on some platform, you'll not only have to disable the audio define, but also find the one call. After that, it works.
While I think you should either work on the game or not, there were some moments of indecision when I had already said that the game is done, but didn't feel like doing something else either, so I kind of just browsed the code and didn't end up doing anything after all.
Compiler: Visual Studio .net 2003
Notable libraries: SDL, FMOD
Notable tools: audacity, musinum
Time span: 48 hours
Working time: about 12 hours total
Time spent playing Psychonauts: probably more than 12 hours total