The Attack of the Crimson Plumber! – Ludum Dare 25

Continuing on my current trend of writing blog posts about a year late, let me tell you about my last Ludum Dare game!

One of these days, I will make a Ludum Dare game with an actual opponent. My Ludum Dare 25 game was no such achievement, but I ended up happier with it than my last one. The tight deadline led to some very satisfying late changes and workarounds, and only a few disastrous omissions.

It all started with a hideous tile system demo, of course.
It all started with a hideous tile system demo, of course.

The LD25 theme was “You are the villain.” I managed to come up with an idea reasonably quickly: the player needs to place traps in a side-scrolling platformer modelled after a Mario boss battle. As usual, that idea ballooned into something way more complicated than I could have handled in 48 or 72 hours. I had to do the hard part (editing!) while I made the thing. At its fullest, this would have demanded some fancy game mechanics to ensure the player doesn’t break the game and some fancy AI that can actually navigate traps. And then some even fancier AI that can navigate traps without being predictable or annoyingly capable.

Dreading all the decision-making around that, I doddled along for the first day and a half, mostly just fiddling with the base technology. I wanted some practice with HTML Canvas, so I grabbed the Dart SDK as well, since I thought that language looked pretty interesting. As might be expected, this was a really great combination — I barely had any trouble with it. Eventually, I came up with some rudimentary behaviour for the opponent, so it always walks ahead and jumps (or doesn’t jump) according to certain combinations of blocks in its path. The graphics looked bad and I felt somewhat relieved thinking that I just wasn’t going to bother subjecting anyone to this thing.

It got more complicated, and worse in just about every way.
It got more complicated, and worse in just about every way.

Then a friend convinced me to release it for some reason. What a jerk.

The painfully unreliable collision detection reminded me of those old handheld LCD games, so in the last few hours I changed most of the graphics to snap to a grid and I switched to a grey colour palette with a coloured background. I think it looks quite handsome, for about half an hour of work.

The rest of the game turned out a little more complicated than I was expecting, so it all kind of falls apart of you look at it for more than a minute, but it was fun to explore Dart and HTML Canvas. I hadn’t used them before, and now that I’ve had some time to play around I feel really good about both of them. I hope I get to use them again some day! Next time, I’ll remember to implement timing code first.

That background gradient worked wonders.
That background gradient worked wonders.

If you want to play the game for some reason, it’s available on the web. It should work with any modern browser. The source is in a single .dart file (I mentioned it was terrible, right?), and all the rest is on the game’s entry page at

As always, other people made some way better things. Here are some of my favourites:

  • Age of Umpires. Sort of reminds me of Konami Ice Hockey. Also, believe me: the referee mode is incredible.
  • Dance Man. This one is by Andrew Brown, my friend who did Baby Farm for LD23. Bizarre and yet brilliant, again, as usual.
  • Space Lord. Space invaders. Need I say more?

Space Bees Attack! – My Ludum Dare 23 entry

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.

You can download the game for Linux and Windows. If you want to play with the source code, you’re welcome to it. It’s all there in the Linux download.