So it's finally over. I'm not much more rested, since I have a sudden rush of homework right now, but at least I can say that I completed a mostly playable game for the 44th Mini Ludum Dare. Jumpstarter is one of 99 entries to the competition, and in this post I'd like to do a brief postmortem of its development process. First, let's start with three things that could have gone better.
What Went Wrong
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.
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 that I 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
Honestly, I am 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've certainly seen these competitions or jams floating around the Internet before, but I was never motivated to participate in one until the #7DRTS game 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.
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. That, and I need to get around to reviewing Shadowrun Returns.