A Mini Ludum Dare Postmortem

A screenshot of Jumpstarter, my MiniLD 44 submission

Mini Ludum Dare 44

Ludum Dare is a fairly well-known game development competition in which the goal is for single developers to make a game in 48 hours, based on a given theme.  There have been 26 Ludum Dare competitions so far, and a number of smaller events have sprung up around the main event, including both a game jam and Ludum Dare’s little cousin, Mini Ludum Dare.

A few weeks ago (from July 22 to 29), I participated in the 44th Mini Ludum Dare, and my game was one of 99 submitted to the competition.  The hashtag for the competition perfectly encapsulates its theme – #7DRTS.  We were to make an RTS (Real Time Strategy) game in 7 days.  Because we were allowed to reuse code and assets we had the rights to, I felt I was able to participate, since I had a decent code base on hand for managing a window, user input and art assets; and because RTS games are a huge part of both, why I became a gamer in the first place, and why I want to become a game developer, I felt I had to participate.  The result was Jumpstarter (submission page here), a space RTS game that I created in 7 days.

In this post, I’d like to do a postmortem of the development of Jumpstarter, by laying out three things that I could improve upon, and three things that went well.

What Went Wrong

Stability Testing

Several of my players have reported that the game is somewhat buggy or, worse, crashes completely.  Even though others haven’t had these issues, crashes are a serious problem.  I personally played the game a great deal on the final day in order to make sure this didn’t happen, but what I neglected to do was test on many different PCs; I played primarily on my own laptop, and once on a desktop at school.  Also, there were some serious bugs with window resizing, which I hadn’t even considered as a possibility; my “fix” was to update the game to be fullscreen-only, but that isn’t a real solution.

To avoid these problems in the future, one thing to keep in mind, would be to test on as many machines as possible.  This might prove difficult, but might be aided by a second solution – next time I should get the game out to some testers, ideally as soon as I believed I had something playable, and have them note any problems they had with the game.  If in doing so the testers were using their own various PCs, all the better.  Finally, building an error logging system may have helped remotely identify the problems that users were experiencing.

Player Introduction

Part of the consequences of the limited timeframe were that I decided to scrap niceties such as a tutorial or even an instructions screen.  This proved to be a not-so-awesome idea, as several players have noted that they find the mechanics confusing.

While not a surprise per se (this was a conscious sacrifice on my part), the feedback from players highlights the importance of having some kind of instruction for the player.  In future games, I should consider dedicating some time to a player introduction of some kind, either an instruction screen or a tutorial.  Having two days to polish at the end of the competition, instead of just one, would have been immensely helpful.

Rest & Useless Coding

The development process was quite exhausting, and by four days in I was certainly feeling a little worse in general; I think this also impacted my ability to develop properly.  There were a few occasions during development when I was tired and found myself stuck in a rut for half an hour to almost an hour with a single bug or crash that turned out to be something completely trivial, like a null pointer I didn’t check for, or an integer variable I was using as if it was a float.

Added up, these ended up being a significant drain, costing me several hours that might otherwise have been used to polish the game.  Perhaps getting more rest, even if it means less raw development time, would have enabled me to catch those errors more quickly or avoid them entirely, ultimately making development more efficient.

What Went Right

Manageable Scope

I am still somewhat surprised to say that I managed to implement the game’s features within 6 days, but that is what I was aiming for.  Whether by luck or a somewhat experienced guess (I have been programming prototypes like this for a few years), the scope I set out for myself – six units, planet capture, two sources of income, basic AI, etc. – was entirely manageable within the time frame set.

There were some slight hiccups – AI was probably the biggest unforeseen timesink, and I had to completely rewrite the entire AI system once before it reached anything approaching decent – but all in all, I think I did a good job scoping for something that I was also able to achieve in the given timeframe.  In the future, I should try to keep that up by not overscoping on my projects, and keeping realistic feasibility estimates.

Simple RTS Fun

Several of my players have noted that the game is fun to play; this is really great to hear in any context, but particularly so because the RTS genre has long been one of my favorites.

I think it was good here that I trusted my instincts as an RTS player.  When thinking of the game’s design, I thought about what it was about RTS games that I enjoyed the most, and fundamentally, it was the act of clicking on many little units and sending them places.  I tried to focus the game’s design on this action, and I think I succeeded well enough in doing so.

I Participated

I’ve certainly seen these competitions or jams floating around the Internet before, but I was never motivated to participate in one until the #7DRTS came along.  Making a game in 7 days was definitely not easy, but it was a good learning experience, and I now feel a little more comfortable with the idea of rapidly working on a game under a deadline.  If I get the chance, I think it might be a good idea to participate in another such event, time and schedule permitting.

Conclusion

Participating in the Mini Ludum Dare competition was both exhausting and rewarding.  I managed to get something like a complete game out in seven days, I learned a bit about various aspects of game development, and I made some mistakes that I hope to learn from in the future.  I would like to continue working on Jumpstarter, in order to polish it, expand its scope a little and learn more about RTS development; but for now, at least, a little break from it would do me some good.  Off to code something else!


Guerric Haché is a student in the VFS Game Design program