After participating in two Ludum Dare game jams, I decided to expand my horizons and try out an Alakajam! I’d been curious to try out other game jams in general, but Alakajam in particular seemed to have a really nice website, plus lots of neat community stuff like tournaments where people competed for high scores in previous game jam games.

I ended up finishing and submitting a game for Alakajam #5, which ran from February 22 to February 24, 2019 – and as usual, I’ve put together an excessively long postmortem blog post about the experience!

Plans & Preparations

I learned from my first game jam that taking a vacation day from work was a good idea if I planned to attempt one of these. And Alakajam had a start time of Friday at 7:00 pm UTC – which translates to 1:00 pm in my time zone, overlapping with a good chunk of the work day. Knowing this, I submitted a request for a vacation day as soon as it was on my radar, way back around New Year’s or so.

But then came a small curveball in the form of a career opportunity: I ended up taking a new job at a new company, starting the very same week of Alakajam… and taking a vacation day on the first week didn’t seem like such a good idea. Between that and some other family obligations, I wasn’t sure if I’d actually have time to participate, as reflected in my obligatory “I’m in” post.

When the theme was revealed on Friday though – “Spellcasting” – I felt super motivated to try participating anyway, since it seemed to fit in really well with my usual game development interests. (Which typically tend to involve RPG type mechanics and progression systems… And my current game project even involves a spell-casting wizard as the protagonist.)

The Idea

I went in thinking this game jam could be an opportunity to feel out some really barebones variations on mechanics I’d been considering for my “real” game, and landed on an idea for a magic-themed grid-based puzzle with three elements, limited MP, and the possibility for upgrades. In the end, it would involve the following:

  • Conveyor belts with blocks in three different colors (elements), with the ability to “process” the one on the end. Processing a block costs 1 MP, and gains you 1 magic orb.
  • MP potions appear randomly among the blocks, and restore 10 MP each.
  • Upgrades can be purchased to increase the “efficiency” of refining blocks of each type (lets you refine multiple blocks for the cost of a single one)
    • Goal: Get the highest score possible (as measured in total orbs collected)
    • Lose Condition: Run out of MP

The idea was admittedly fuzzier in the beginning, though – compared to my previous game jams, I felt like I was “winging it” a lot more rather than having a solid plan, which maybe wasn’t ideal. And given the tighter-than-usual time constraints I was looking at, the entire concept was probably pushing the limits of a reasonable scope too.

The Development Process

Since the “phase” based development strategy seemed to work pretty well in my previous game jam, I figured I’d take a similar approach with this one. The planned phases were as follows:

  1. The minimum playable game. Defined here as having some kind of puzzle grid that you could click on to remove blocks, a score that increases, and a “game over” condition.
  2. Bonus mechanics. Spell upgrades, MP potions, and a few other ideas that didn’t make it into the final game.
  3. Polish. An introduction / tutorial screen, improving the appearance of buttons / icons, etc.

But it was hard to say if this approach would work as well here – after all, it would need to be crammed into a smaller time span than I’d had at my disposal for Ludum Dare.

Day 1 (Friday)

Basically nothing got done on Friday, other than setting up the beginnings of the project fairly late in the evening after the kids went to bed. (But this was expected, what with it being a work day and all.)

Day 2 (Saturday)

A lot more visible progress happened on day two. I ended up being able to work on it some in the morning, which I wasn’t expecting. (The afternoon, on the other hand, went more or less as expected as far as some family obligations and such.) But it was shaping up into something vaguely resembling a game, as shown by this functional puzzle grid set up along with the beginnings of a magical contraption on the left:

A screenshot showing the game as it looked on the first day of the game jam.
Progress as of Saturday night, showing the initial grid setup.

If you’re thinking it looks like some kind of circus cannon, you’d be right – I definitely based it off of a cannon, and was even thinking of more of a “shoot the monsters” setup in the very beginning. I pivoted to the magic factory idea a few hours in, but repurposed the asset to be part of the machinery.

Anyway, I probably stayed up way too late working on it, but by the end of the night I had very nearly finished everything from the 3-phase development list. Which was good, because…

Day 3 (Sunday)

The final day. With the deadline looming at 1:00 pm, I finished the last of the mechanics and made a few more visual improvements. At that point, I was feeling pretty good about the state of the game overall. It had music (procedurally generated using this nifty Abundant Music tool), sound effects created in BFXR, animations, particle effects, a little intro tutorial screen… And while there were no doubt lots of things I could’ve done to make it better (which we’ll get to later in the feedback section), I felt like it was in a pretty submission-ready state.

An animated gif showing gameplay of a simple block-based game jam entry.
The final gameplay in action.

So with an hour or so to spare, I leisurely started creating the actual submission. I set up the game page and description on the Alakajam website, exported the web build from Godot Engine, created a game project for it on, and uploaded it.

But then… Upon attempting to actually play it on for the first time, I was mildly horrified to realize that it didn’t actually work at all. The smooth animations and pretty particle effects were nowhere to be found, and instead it would just glitch out when clicking on the blocks, rendering the whole thing confusing and barely playable:

An animated gif showing a game with glitchy behavior.
The jittery, awful-looking behavior of the final submission.

In retrospect, I should have been testing out the web export as I went. My previous (and only other) time using Godot Engine, the web export went so smoothly and effortlessly that I never even considered the possibility that it wouldn’t work exactly the same as the version I’d been testing in the editor.


Luckily, the Alakajam rules do explicitly allow post-jam changes in order to fix bugs, so I ended up pushing out a change a few hours after the deadline to address the issues with the web build. (For anyone wondering, the culprit for the crazy jittery behavior turned out to be the particle effects – once those were removed, the rest of the animations worked fine. Though I also ended up needing to make some changes to the spells upgrade popup, which similarly wasn’t working correctly in the web build.)

A thumbnail for a game jam entry on the Alakajam website.
The final thumbnail for my submission.

Since the rules also allow porting your game to other platforms after the deadline, I ended up adding versions for Windows and Mac a day later. Those kept the original particle effects in – might as well allow for at least the possibility of seeing the game as it was originally intended to look!

The final game page on the Alakajam site can be found here. Overall, this was definitely my shakiest game jam submission yet – but it also resulted in my first-ever Windows and Mac “releases” for a game, which I hadn’t planned for going in. So that seems like some kind of happy milestone worth making note of.

Time Spent

All told, I ended up spending 22 hours on this game jam over the course of the weekend (including the post-jam fixes)… And to be honest, that’s quite a bit more than I was expecting to have time for in the beginning. The following is a breakdown of how that time was spent:

Pie chart showing the percentage of time spent on different aspects of developing a small game for a game jam.
A breakdown of time spent on different aspects of the game.

It’s interesting to compare this to my last Ludum Dare, where over a third of the time was spent on graphics and audio didn’t even get a sliver. This time around, the majority of time was spent in Godot Engine, with Inkscape in second place, and everything else trailing far behind.

Feedback Received

Over the course of the two-week rating period, the game received 10 comments, 14 ratings (I think – it doesn’t seem like the totals on this are visible any longer on the Alakajam site), one review on, and one piece of feedback on Twitter. As usual, I went through and tried to pick out the recurring themes in these, and order them by how often they came up:

Positive Feedback

  • Nice art: This was the most commonly brought up bit of positive feedback – most of the comments reflected that the visual style was simple but consistent, and worked well overall.
  • Nice audio: The second most common positive feedback. A few comments mentioned being able to tell that the music was procedurally generated, but that it worked well overall (especially in a weekend game jam where many entries didn’t have music at all).
  • Has potential to be taken further: This usually came up in the context of specific suggestions given (more details on that in the section below).
  • Well suited for mobile: This was nice to hear since mobile has been the target for my “real” projects, and one of my few goals going into this game jam was to stick to mouse-based controls that might have the possibility of being adapted for touch screens later.

Room for Improvement

  • Balance issues (not enough MP potions): This was the most common criticism – MP potions appeared completely randomly, and usually not often enough. Numerous players also reported that the potions would appear only in the beginning, and then stop appearing, so there may have been something off about how I was randomizing them.
  • Not enough meaningful choices (lack of control over outcome): This ties in with the previous item somewhat, in that players were largely at the mercy of the random nature of the MP potions, and the upgrades didn’t feel like interesting or meaningful enough choices.
  • Too short (want to be able to play a single run for longer): This came up a few times, and it kinda makes sense that a game with a progression system involving upgrades should last longer than a minute or two. (Though I think it also ties in with the issue of MP potions running out.)
  • Art is flat (needs more “juice”): This was fair considering the simple nature of it – given more time it might’ve been nice to add more shading and embellishments and stuff.
  • Theme feels tacked on: This was also fair – the whole “spellcasting” aspect of it could have been replaced with lots of other things just by switching out a few graphics.
  • Board isn’t reset between runs: Only one player seemed to really notice this issue (which I’d just glossed over due to the time constraints), but they chose to use it to their advantage by lining up a bunch of MP potions, purposely dying, and then starting the next run with a huge advantage and getting the highest score I’ve seen (complete with screenshots). I hadn’t given any thought to that possibility, and it was interesting to see someone interact with the game in a way I hadn’t expected!

Specific Suggestions

  • Ability to create combos (vertical interaction): This was the most common suggestion, and it seems like a good one – it would add a bit more strategy to the game, and the potential for more control over the outcome.
  • Ability to purchase additional MP potions: This suggestion makes sense, though might be less necessary if the balance issues relating to the MP potions were addressed.
  • Ability to destroy or change color of blocks: This was another interesting suggestion, and another potential way to give players more meaningful choices with different strategies to use. It could be a second kind of purchasable upgrade, and maybe play into the process of lining up combos.

Final Scores

At the end of the two-week rating period, the final results were released. Here’s how I did in my first-ever Alakajam:

A screenshot showing the scores received in all rating categories on the Alakajam website.
The final scores received in all categories.

So pretty average overall – slightly above average in a few categories, and below average in a few others. It’s interesting that the highest ranking (Audio) was the aspect of it that I spent the least amount of time on! And the rest of the scores make sense based on the feedback received.

Lessons Learned

So what have I learned from all this? Here are my main takeaways from this game jam experience:

  • Need to test the web build early and often. Don’t just rely on the web build working the same way as what you’ve been testing when clicking the play button in your engine – make sure to test it out periodically as you go. I got blindsided by this in the submission process this time around, but next time will be sure to test better throughout the development process.
  • Game design: Need to have interesting choices. Players need to be able to make interesting and meaningful choices – this is probably one of the most important principles in game design. And it’s something I’ll need to put more consideration into from the beginning of the idea phase, especially when attempting little puzzle games like this in a game jam setting (where some of the planned features may end up in the “cut due to time constraints” bin).
  • Players will think of clever ways to exploit your systems. If there are any holes in your gameplay mechanics, players will figure it out – especially if it helps them gain an advantage. Maybe this goes without saying, but it was neat seeing it in action during this game jam with the board reset issue.
  • Audio makes a big difference. Even generic or procedurally-generated music, and the most basic retro-flavored sound effects, can have a really big impact on how finished the game feels. And the level of effort (time wise) to get them in place is way lower than I might’ve assumed before this.


Overall, my first Alakajam experience was a good one, and I’m glad I took part in it. Going in, I was actually a little worried about whether it would be “worth it” to participate in a smaller game jam like this – historically, Alakajam has had only a few dozen submissions for each game jam, compared to a few thousand every time in Ludum Dare. But the quality and quantity of the feedback was excellent – just as good, if not better, than what I got out of those larger game jams. I’m definitely hoping to participate again in the future!

As for what’s next? This may be my first game jam project that I’m strongly considering iterating on in its current form (as opposed to a total rewrite) – incorporating some of the feedback and suggestions received during the jam, and releasing an updated “2.0” version. It may also be a good opportunity to experiment with using Godot Engine to build for mobile, since I’ve been considering making the switch over to it from SpriteKit. But that’s not something I’ve dug into just yet.

For now, I’ve been focusing on trying to finish and release my first “real” iPhone game – which you may remember as that “small” 2-3 month project that has now dragged on past the 8-month mark, ha. But that’s a subject for a future blog post.

Anyway, that concludes another excessively long game jam postmortem! Until next time, feel free to check out my Twitter for smaller updates and/or to follow, and as always, thanks for reading!