Mini Jam Postmortem

This was our fourth game jam, my brother and I. I think we delivered our most polished and finished game yet. But then again, I think it’s only the second one we can really call “finished”; our first two games were overly ambitious, and our skills… not there yet. The third one, done only a couple of months ago, is not that bad, but feels a bit too chaotic, uses mainly stock assets, and does not have as much cohesion or fun factor as this latest entry, Neon Impaler.

What went well

1. Preparation and tools

I put these two points together, as I feel they’re related in our case. We knew which tools we wanted to use, and had some experience with them. I took some time in the weeks preceding the jam to fiddle in our engine of choice, Godot, so that I would be more comfortable when the jam started.

Following our last jam in November, I also went ahead and augmented our template project. It now contains the basic flow (prelaunch, intro and game scenes), the pause and options menus, French and English texts, and some more. Starting with this template, we could start working on the game more quickly.

For the organization, we used Trello, like we did in our other jams. It allowed us to quickly note ideas down, and have a sense of what was left to do. It was also very motivating, each morning, to archive all the cards representing the work we did the day before. It was a powerful way to start the day.

We had an objective, this game jam, to create our own graphic assets as much as possible. Except for our very first jam, we were mainly using and slightly adjusting stock assets I bought in numerous bundles in the past. As we’re not artists (we’re both programmers), creating our own “art” was quite a challenge, but we learned in the process. I can now create a neon effect in Paint.net, woohoo! Hexels was also very useful in creating our somewhat abstract world.

For the audio, we went with pre-made tunes from Pixabay, and sound effects generated in JFXR. Both are services we used before, so we were able to gather what we needed from them quite easily (not that it’s overly complex anyway).

As for the general preparation, we made sure our computers were in order and updated prior to the jam starting, using the same version for relevant tools (Godot, VS Code and godot-tools extension), we tested that the template ran properly, etc. The only (minor) blind spot we had was for file sharing. The project itself was on github, but we didn’t want to use that to transfer large files like reference images, source Hexels and Paint.net projects, etc. Our mixed Linux and Windows setup made this part a bit harder than it should have, especially in the middle of a jam where you want to be doing something else than troubleshooting samba shares.

2. Limited scope and focus

This being our fourth game jam, we can now recognize what a proper scope looks like for that kind of project and delay.

I still remember our second jam, where we were confident that we could integrate multiple mini-games for the player to gather different types of resources, then craft using those resources, all that while trying to survive in an ever-evolving environment with night and day cycles. At least, we kept it realistic and aimed for 2D! In the end, we were only able to submit a basic Sokoban game hidden in an overly complex and confusing series of screens.

This time, we quickly decided on a core idea: A runner with a jetpack and a harpoon to grab fishes. We started with that, then added more as we went along: a store to buy upgrades, a series of level patterns with a system to push them in a way that wouldn’t break the player’s run (by e.g. having two patterns overlapping and leaving no place for the player to survive). Every time we realized an idea was taking too long or getting too complex for the context of a jam, we simply added a card in Trello in the “Nice to have” column, then went to work on something more relevant.

Our development process fell into a pattern that I only realized on the third day. In short:

• Day 1 (and start of day 2): We developed the core engine and its subsystems (patterns, shop).
• Day 2: We produced the content (levels, gear and upgrades) and assets, and tested a lot.
• Day 3: Time for some extras, like more patterns, improved sub-systems, and some more testing and balancing.

In fact, at the end of day 2, we had something probably as finished (or more) than any of our other jams.

For the theme, we initially aimed for some “space” setting. The jetpack was to be some instantaneous compost machine, and the player would need to circle his station to capture the space fishes that destroyed or tried to destroy it for some reason. It made very little sense, and with our very limited artistic talent, it was hard to produce art to fit that theme. The synth wave music that had been now playing for hours clearly inspired us, as we turned around and went with a “neon” theme instead. There might have been some Tron soundtrack in that playlist that kept us going that weekend.

3. Testing

Somewhere around the middle of day 2, I decided I would test the web export, you know, just in case… Good thing I did, as I encountered multiple issues that were not that obvious to fix. Most of the web-related issues were around file listing and loading. For example, we list all the level patterns from folders (one for each difficulty level), and do the same for gear items, sorting them by cost. In the end, we were able to take advantage of other people’s experiences and posts all over the interwebs (forums, Reddit).

Following those fixes, we were determined to try to break the game as early and as often as possible. We know way too well how last-minute debugging only leads to bugs multiplying. Again, we found and fixed a lot of weird cases. Each time one of us would add a new system or any other substantial change, we went back to trying to break the game.

The game is probably not without any bugs, but it is certainly way more stable than it could have been. Also, this continuous testing-and-fixing mindset gave us enough confidence in the state of the project to add more stuff without risking toppling down the whole thing.

What went less well

1. Last-minute crunch

We realized near the end of the jam that, for some reason, there was one hour less than expected. The jam was supposed to be 72 hours long, but the submission time was an hour before that mark. And we realized that when we had about 3 hours left… oh no, make that 2 now! It sent us into some kind of last-minute frenzy, and we were forced to make choices. Only two sound effects made the final product, and the in-game how-to-play instructions could never be completed in time (more on that below).

Everything was going so smoothly during the rest of the jam that I think we became a bit complacent. There were still things left to do, but “we still had time”. Simple things like sound effects became way more complex to debug when the deadline was approaching.

Why is the death sound effect only playing when we respawn? Oh yeah, it’s attached to the player, which gets paused when it dies. No easy fix there, let’s skip that sound!

2. Communicating with the player

There are two aspects where I think we failed in properly communicating with the player.

First, the cover image for the game. It’s not much, but it’s still the main thing other jam participants see when they look at the 200+ submissions. And our cover image was a quickly hacked screenshot of our main intro menu, without the buttons. It kinda looks like crap, and does not properly reflect what the game is. As such, even if I tested and reviewed more than 30 submissions, we only received 10 ratings after two full days. That number is the average at this time (more than 2000 ratings for the 236 entries), but considering how many submissions had no cover image or mentions of not being finished, I can help but feel like it’s a missed chance.

Second, the in-game instructions and controls. There were none of the former, and we never stopped to review the latter. After being so immersed in our game, we did not realize how clunky the controls were. Considering the game only requires two inputs, one for the jetpack and the other for the harpoon, we could have used a scheme that was possible with only one hand (e.g. WASD - or W - for the jetpack, and spacebar for the harpoon) so that the player could keep their other hand on their mouse, or drink, or snack or whatever. And in addition to those unintuitive controls, there were no in-game instructions. With the very short range of the starting harpoon, I cannot blame people for not understanding how it worked, for thinking that it was broken, or not even realizing that this mechanic was present. If you remove the harpoon from our game, it does not fit that much in a jam with a “fishing” theme and probably does not justify the “Impaler” in the title. And the shop is impossible to use without the cash given by fishing, so that’s one more mechanic inaccessible to the confused player.

3. Web version

As I said above, it’s a good thing that we tested the web version early enough in the process. It had a couple of unexpected issues (then again, when do you expect issues?), which took us a couple of precious hours to debug. I don’t think it put the game at risk of being submittable, but it certainly felt like it a couple of times during the debugging.

Lessons for the next jam

Considering how well things went in general, I feel next time will look a lot like this jam. I plan to improve our Godot project template, to include some fixes and features we added during this jam. The goal is to have something that allows us to work on a game idea with as few roadblocks as possible. I also plan to make that template publicly available, so that every participant who desires it could have the same kind of “headstart”.

One thing we’ll try to keep in mind for the next jam though, is how the game presents itself to a new player. After testing more than 30 games during the voting period, I had a feeling for which games were easy to get into, and which ones were too obscure or convoluted. Sadly, I think Neon Impaler falls into the second category, which is a disservice to the work we put in there.

The future of the game

We may still be surfing on the high of this intense weekend and the very positive feedback we received, both from jam participants and work colleagues, but we plan on working some more on that game. I don’t know if we’ll bring it exactly where it could go: we have a lot of nice ideas, some more easy to realize than others. We added everything we have in mind to our Trello board, and we’ll see where we go from there.

I’m pretty certain we’ll release at least another version, once the voting period is over, to fix what I consider the biggest issues: the controls, the lack of instructions, and the (almost-)absence of sound effects. I already worked on some updated visuals too (I needed a small break from the programming), which would make it into that next version.