April 28th-30th was the eighth ld48 game making competition. The chosen theme was "swarms" and I created a RTSish game named Bee Commander. This is the fourth ld48 that I have participated in, and I think that it has been my best entry. I put about 25 hours into the game, most of which were very productive. Happily I didn't run into any major speed bumps, and the only thing that really cut into my game making time was going out for Jay's birthday Saturday night.
Keep it simple - The past two ld48's I went with complex concepts that required a lot of features for the game to work the way I wanted it to. Going into this compo, I decided that I would work on the simplest concept that I thought would be fun and fit the theme. I initially decided that I would make a game where a swarm of bees had to attack wasps in large groups to kill it by cooking it with their body heat. When I got the basic technology and gameplay done with lots of time to spare, I was able to add more elements like the pollen and worker bees. Aiming low and working your way up seems to be the best approach to an ld48.
Start polishing early - Again, this is a lesson that I learned from my last two ld48 experiences. In those events I was adding features and gameplay until the deadline. I didn't take the time to add polish like menus and help. This time around I started working on the basis for these features when I still had 12 hours left.
iPython - I recently blogged some thoughts on game tuning, and one of the things I decided to look into was using a python interactive shell for game development. Initially I tried running my game under the iPython shell, but I just couldn't get a good system working for testing changes. I need to find a tutorial on how to work with gui code under the python shell. One thing that did work really well for me though was embedding ipython into my game. By hitting the ~ key, I could pause the game and use the shell to inspect and modify it's state. Contrary to my initial expectations, I didn't use this for much game tuning. But it was excellent for debugging purposes, making a lot of things easier to get right.Sound - This is the first time I've made sounds for a game. I used Audacity with the built in mic on my iMac, and it turned out to be much easier than I expected. My results weren't amazing, and the bee death clip sound like "bee!" instead of "aieeee!" But I'm quite happy with what I got considering the short amount of time invested, and my lack of experience.
Copy 'n' Paste coding - The game has Wasps, Worker Bees, and Warrior Bees, all of which have very similar properties. I should have made a base class insect type that everything inherited from, but instead the code for all three types is duplicated in all three classes. Bad bad bad. Other problems with the code include some really ugly spaghetti interconnections between objects that was put into place to track things like which bees were targeting which flowers, and if there were wasps protecting those flowers. I'm sure that I could have avoided the spaghetti, but I don't feel so bad, because with only a few hours left before the deadline, hacks and shortcuts were much faster than properly planned code design.
Level framework - I stored all of my level data in a giant nested python list with a little bit of special case code for level init and end condition checking. I created new levels by adding hand written sublist of coordinates. At first this seemed to work well, but as I added more levels, and the level complexity went up, it became very difficult to work with. If I had created a better system, the game would have ended up with better levels, and more of them. Perhaps I should look into a level editor package like Phil's PGU.
Lack of Uniqueness - For some reason I thought that a 'swarm of bees' game would be uncommon in a swarm themed competition. Silly me. I expected most people to make games that involved a lone player interacting with computer driven swarms, and that player controlled swarms would be rare. It turns out that the opposite was true. Plus there were bees everywhere. In retrospect it seems obvious that a lot of bee games would be made, but I was very surprised. In fact, Wyzfen even had a concept that was almost identical to mine. I don't think my lack of originality hurt my game too much, but I wanted to show the other compo participants something unique.
Making a game mostly from scratch in 48 hours gets easier with practice. There is still a big list of things that I would like to get better at, but it all comes with experience. In terms of new code/game technology use, I didn't really try to do anything new, other than the small step of embedding iPython. This is good because keeping it simple allowed me to produce a good game. But it's also too bad, because the competition environment is a great motivator for learning new things.
After finishing an competition I always think that the next one can't come soon enough, but I guess that 6 months is a good buffer to balance out real life and to keep me sane. As usual, the ld48 was a great time, and I'm proud of what I've built. The only other thing I need to say is thank you to Geoff for making the competition happen.