My friend Andrew convinced me to participate in Ludum Dare 23 — a fun and informal 48-hour (or 72-hour) game making competition. He created an insane, brilliant little game called Baby Farm. I went ahead with a poorly thought out idea: “I’ll make a game where you have to build a structure to defend your world where evil things are falling from the sky! With physics!”
The “with physics” part is where it went wrong. Words for the wise: physics are evil.
It sort of evolved in an interesting way, though. I decided I would commit to some specific technologies and make them work, rather than worrying constantly about my choice of tools like I usually do. I decided on Python and I grabbed a very nice hardware accelerated 2d graphics library called pyglet (which I had been meaning to learn) as well as pymunk for 2d physics, and I planned to do any graphics as quickly as possible with Inkscape. I started off just making it possible for the player to dump objects in the scene. Originally, the defensive structure was going to be assembled from different materials like bricks and pieces of wood. The results were kind of uninspiring.
After some fiddling, I erased a lot of code and switched to Tetris blocks: they fall from the sky and you place them to form sturdy towers. This is one thing that turned out really well. I have played a few Tetris + physics games, and they tend to be unbelievably frustrating. I wanted something that felt a lot like normal Tetris, so the blocks are easy to fit together and the one you control is fluid and reliable. Of course, this is where I finally explored a very important point first hand: video game physics are not real physics. To keep everything stable, blocks gain a whole bunch of extra mass when they are released, and some custom collision handlers ensure that blocks are as steady as possible while they are being controlled. The block being controlled by the player is pulled along by a set of constraints: one handles rotation (in 90° increments) and another forces the block to snap to a specific point on the X axis.
I then spent a bizarre number of hours trying to rotate a group of sprites around an arbitrary point. Because, of course, it’s great that you can have a physics library that tells you how to position and rotate everything, but if you can’t draw those objects the way it wants, you aren’t getting anywhere. Suffice it to say, I was getting nowhere for a very long time. I think part of this may have been a misunderstanding about coordinate systems, but in the end I solved it by borrowing the Sprite class from Cocos2d, so it could deal with that stuff for me. Yes, I suck at math.
My big regret here is that I completely ignored the point of the game — the Space Bees — until something like six hours before the deadline. This meant very little testing, so I ended up sticking to the first terrible idea that landed in my head: ‘they’ll fly like real bees, and just be really heavy blocks so the physics stuff will take care of itself.’ No, it doesn’t happen that way: I spent five minutes making them fly, and five hours tuning them, fruitlessly. In retrospect, I should have gone for something more like falling rocks, and I should have removed them from the physics simulation. Having these falling bees inside the simulation provided no gameplay benefits and created some rather horrible visual issues. Most importantly, I think it would have helped me if I had focused on establishing some kind of (preferably amusing) challenge as early as possible. As it turns out, that really is a big priority in making a game.
At any rate, this is my first Ludum Dare entry! It is possibly the first time I have built a game with any kind of playability, however brief the amusement may be. It was especially fun seeing the comments people left for my game. I was terrified at first, but they were all lovely, constructive and encouraging comments. The Ludum Dare community is amazing and I definitely look forward to doing this again, armed with the lessons and the confidence I gained this time.