Game jam retrospective or: how to finish that side project

Last November I participated in GitHub’s Game Off 2019, one of the many game jams hosted on itch.io.

The idea of a game jam is similar to a hackathon: participants have a short amount of time to design, develop, and release a functional game. Often, they specify a theme that submissions should adhere to or be inspired by. There can also be a competitive element whereby games are judged and rated against each other.

One evening in late October, I saw a “Game Off 2019” call for submissions on Twitter and decided it would be fun to try out. I have never participated in one before, nor am I a game developer. Luckily the competition wording was very welcoming, featuring a prominent “Help—I’ve never created a game before” section, so this did not seem to matter.

A month later, following some weekends and weeknights of poor Photoshop and even poorer Python, I debuted my creation to the world: get dem nuts¹, a squirrel-themed, 2D, tile-based survival game.

Ultimately (and despite the adorable premise) get dem nuts didn’t do particularly well, coming 216th out of 234 entries. This wasn’t particularly unexpected and I’m grateful that even a couple of people took the time to download and score it. However, this retrospective is not about what I could have done to improve that score, but rather the lessons I learned from the way I approached this as a side project, and how I can apply those lessons in future.

Goals and approach

My motivations for taking part in “Game Off 2019” were twofold.

First and foremost, I wanted to have fun by building something that is very different to the kind of things I normally work on. This I undoubtedly achieved. I had an absolute blast. The overall experience reminded me of hacking together similar games in QBasic almost 15 years ago, the genesis of my journey in programming, computer science, and my career in general. I found Python with pygame to be very similar in spirit to the QBasic environment: a blank canvas, ripe for projecting one’s imagination directly onto. It brought back floods of nostalgia and memories of a simpler time.

My second goal was to ship something usable by a deadline. Like many people, I have problems finishing side projects. Often once the initial novelty of an idea has worn off, or I’ve developed a sufficiently working prototype, I get bored and move on to something else. I felt that having the external competition deadline imposed on me would help me maintain motivation. With this in mind I realised that a different approach was needed. I had to treat it more like a focussed work project than an open-ended side project.

What does this difference mean?

• Prioritisation: Often with side projects I jump straight in with little regard to where anything is going. With “get dem nuts”, however, the first thing I did was dedicate an evening to sketching out what an MVP (minimum viable product) would look like. This was then broken down into a list of features and supplemented with more ambitious stretch features. My initial aim was to hit all MVP features, and around 50% of stretch features. This gave me a solid target to aim for and reduced my risk of getting sidetracked. Some features that I’d like to have added didn’t make the cut, and that’s OK!

• Time management: The competition’s one-month deadline and the fact that I have a full-time job meant that I’d have to be smart about how I spent my time. This partly influenced my decision to use Python as it’s a language I know well, and I find it quick to develop with. Additionally, the time constraints fed back into the MVP plan: clearly it had to be achievable in only a month of hacking at evenings and weekends. I estimated development times for each feature and fit them into a rough roadmap that spanned the submission period. MVP and stretch feature assignments were adjusted accordingly. This helped to limit project complexity and keep the MVP truly M.

• Pragmatism: For most features, I was ruthless about not spending more time on them than I had estimated. This allowed me to put aside my perfectionism to ship features that were “good enough”. Without this strict timeboxing I might have spent hours making tiny tweaks to graphics, or optimising code, for little benefit. On the other hand, I was mindful of the scrutiny of having to release a working game (along with source code), and having other people judge it during the competition period. This forced me to polish certain things relating to software release that I wouldn’t normally for a side project, including writing clean user documentation, and packaging the game for users to download and run easily².

• Iteration: In true agile fashion, my plan was modified as I went along. When features took longer to implement, I’d reduce timeboxes on cosmetic features like graphics. When I was able to finish features more quickly than anticipated, I’d reprioritise stretch features that initially didn’t make the cut. This flexibility made me resilient to setbacks and quick to capitalise on successes.

Applying these lessons in future

The techniques above are not new to me: I use them in various forms every week at work. The problem is finding the motivation to use them to see a project through to the end.

At work, motivation for completing projects is in no short supply as there are consequences—both good and bad—for hitting or missing deadlines. At home, less so. In self-help parlance, this is the distinction between extrinsic and intrinsic motivation. I believe that the external deadline of the game jam, even in spite of its low stakes, provided just enough extrinsic motivation to trigger a change in mindset. A positive feedback loop then ensued, keeping my intrinsic motivation “topped up”, and enabling me to complete this project.

So, the question is: how can one emulate that extrinsic motivational trigger when the stakes are even lower for the next side project that is not being judged in a competition? Some ideas:

• Become invested by setting a reasonable goal and be explicit about it. Write it down as an MVP plan and commit to a deadline. Put that deadline in your calendar.
• Ask an “accountability buddy” to check in with your progress and remind you of the target you set yourself.

Once that initial motivation has been sparked, use the techniques above to maintain momentum: plan, prioritise, retrospect, and iterate in response to feedback and insights.

Finally, remember to be pragmatic and prepare to adjust expectations as the project evolves. Trying to stick to clearly unachievable goals can be highly demotivating.