Before the competition started, I made a list of ideas for all the finalist themes. Luckily The Tower was pretty much my first choice (along with escape) so I had a pretty clear image of what I wanted to do right away. In the end the game turned out to be pretty close to the one in my head :).
My development process was rather odd, as I did pretty much all the coding on my mac and all the graphics on my ubuntu box. I think most people would expect the opposite. The reason for using ubuntu for the graphics is that I’m used to the gimp and it kind of sucks on OS X, however I don’t have a really good reason for doing the code on the mac, I guess I just like using this machine more.
What went right:
I had a pretty clear plan in my head for this theme so I was able to get started right away and have something playable very fast. After that I had a lot of code-test-fix-test-refix-code-… cycles which I think were a pretty good way to make progress fast while not breaking everything along the way. Python is probably a good choice for this kind of development since with no compiling and linking to do I often felt free to test after even very small changes. Btw, by test I mean playing the game and trying to make it misbehave, not automated unit testing.
The game was not too ambitious. I figured it would be better to have a small rather polished game than a big unfinished and buggy one, so I tried to set my aim rather low to something rather simple but that I could pour a lot of chrome on. I feel I did pretty well here with the small details. The game was almost done on the first day and the second day was spent mostly on fixing little details and tweaking the levels.
The sound, this was the first game I included sound in and I think it worked out pretty well, I used three tools to make the sound effects: cfxr an OS X port of sfxr; say a text to speech tool; and Audacity.The level 2 sounds were recorded in Audacity along with one of the robot’s killing sound, the robots were done with say and the beeps and jump sound were made with cfxr. Then I used Audacity to transcode to vorbis.
What went wrong:
The collision code was horrible for a rather long time. I tried doing single rectangle to rectangle collisions and figure out where to place the character depending on his current speed. That didn’t work out for me as the player would often pass through walls or get stuck in ceilings when changing direction or jumping into walls. So I made a new system with two rectangles for the player, one tall thin one for vertical collisions and a short fat one for horizontal collisions. That didn’t work either despite quite some time lost fiddling with it. In the end I just made 4 rectangles for the player, one on each side, and tested them against all the walls. I feels horribly inefficient, but it was simple and it seems to work.
The levels are a background image and a list of rectangular walls, that seemed like it would be much easier to code efficiently than collision against a black and white bitmap, but it made making levels much harder. In the end I wrote a level tool that displayed the level image and let you drag rectangles onto it and spit out the list of rectangles. This made it a bit less tedious to make levels but it was still a pain.
Difficulty, since I was testing the game a lot, I got pretty good at it so I think I made the levels too hard. My girlfriend did some testing, but since she doesn’t play computer games a lot I didn’t didn’t weigh her concerns about difficulty as much as I should have.
Bits left out:
Originally I had planned to include a gun in the second level where the owl head is now and have a mass of zombies on the bottom floor that you couldn’t jump over, but in the end I figured it would break the flow of the game and that it wouldn’t be that much fun.
Another idea that didn’t make it was having boxes the player could push around. Unfortunately I had that idea rather late and while I probably could have coded it in fast enough, I would have had to redo a lot of the levels or make new ones and that would probably been too much work. I wish I’d thought of that at the beginning since I think it would have allowed for some more interesting “puzzles”.
Finally, in my first image of the game there would have been a first level without monsters but just rather static fire to avoid. I decided to cut that very quickly though because there is no way I could have drawn decent looking animations for fire (and I didn’t add animated characters until rather late and wasn’t sure I wanted to deal with it) so I left it out. I’m not sure whether it was really a good idea since it might have softened the learning curve. On the other hand it might have been less fun and players could lose interest right away.
Lessons learned:
Make proper resource loading right away, for almost all the development cycle all the files, code and media were in one big directory and were all loaded directly. First I noticed that when the sound didn’t initialize that caused crashes so I made a quick audio module so I only needed to do error catching in one place instead of all over the code. And do get some caching as before sounds were reloaded almost every time they were used. Finally near the end I decided to put all the media in a subdirectory to make things cleaner and have an image module to cache images. Which brings us to lesson two:
Don’t make big wide ranging changes right before you release. Changing the way I loaded images was a pretty straightforward thing, but it required changes in tons of places all over the codebase. Inevitably I missed a few, usually that would be a problem because I test a lot, however I wanted to get the game out of the door, so I didn’t test it nearly enough. So the first version I released would crash in some common conditions. Thankfully it was still well before the deadline so I managed to fix it in time but it was rather embarrassing to ship something so broken.
There we go, sorry for the wall of text.
). If you’re making your game in Python (or its pale imitator ruby 
, or any other interpreted language for that matter) you might think you don’t need binaries but you’re wrong, people aren’t going to install a different environment for every single game. Same for Löve games.
) you can shove it up your… 
I decided to try something a bit different so I made three mini games that are all played with only mouse. The games are wrapped in a story mode and you can unlock arcade versions by winning the story versions. The sound effects are rather crappy so you can press “s” to toggle the sound.
