Post Mortem: GGO17 - AA Battery

After GitHub Game Off 2017, someone posted an invitation in the forums to all the participants to write a post-mortem of their game jam experience while it was still fresh in their memory... I didn't have time then, so I quickly copied-and-pasted the guidelines for writing a post-mortem into an empty post and left it for later.

It's a bit more than 2 months later now, but at least we did write daily development diaries to provide a bit of hindsight into how the jam went - this post will merely condense those posts along with more general sentiments.

Before I start just a quick note on the scope of this post-mortem. The Google dictionary defines post-mortem as an examination of a dead body to determine the cause of death. While a medical post-mortem is very definitively at the end of life, this post is being written long after the jam finished for a game that is still under development, so I will make no attempt to focus only on lessons learnt during the jam. Also unlike a medical post-mortem, I need not focus only on the causes of failure, but can also look at causes of success and other lessons that might be learnt from the jam.

If you want to have a look at the game we made you can get it here.

What Went Well


Coming up with an idea was very quick and painless as the theme naturally suggested remaking something and I'd been looking for an excuse to remake Paratrooper for years...

Scoping and prioritization

After we figured out what we were going to make we sat down and came up with a list of ideas for mechanics to implement, which we stuck onto a Trello board and then we prioritized those features so that we would get to a minimum viable product (MVP) as soon as possible. Thanks to this we had a basic remake of Paratrooper as an MVP by about 25% into the jam!
Our Trello board

Lots of content

We managed to cram a lot of content into our game this jam. We got the MVP out quickly and then went on to add:

  • Sound effects
  • Particle effects
  • Melee attacks on the bunker
  • Shopping for upgrades
    • Guard upgrade
    • Flak cannon upgrade
    • Repair upgrade
  • Difficulty progression
    • Bombers
    • Increasing enemy spawns over time
  • Some basic art on the menu screens to make them less boring
  • Score screen
Good Results

Sas's sound effects got us a rated in the top 10% for Audio and finishing in the top 20% for Theme Interpretation, Gameplay and Overall was a huge improvement over any of our previous game jams!
Our results from other jammers' ratings

Almost everyone that has played the game loved the sound effects, so the zany sound effects is definitely something we should embrace in our future development of this game.

What Went Poorly


Scoring 80/200 for Innovation doesn't bother me too much... layering some role-playing elements onto any other genre isn't innovative anymore and trying to revive a somewhat dead genre like a single screen shooter is probably a bit dumb as there's only so much depth you can put into a game with 1 or 2 main mechanics.

Getting 90/200 for Graphics - that hurt! We consciously decided to go for the 4 colour CGA palette as a link to the original game we were remaking and to avoid spending too much time on art - we were hoping for a reaction of "it looks the same, but look the gameplay is so much deeper!", but it seems that even though pixel art is cool, going as far back as CGA was perhaps a bridge too far...

To prevent this recurring in future jams I don't think we'll ever go lower than 16 colour EGA graphics and 256 colour VGA pixel art would probably be the safest bet... that said a smaller palette does help to produce a more cohesive art style, so ultimately I just need to practice practice practice.

Scene Transitions

Every time we make a game that proceeds beyond a single screen we end up in the painful position of having to figure out how to transition between multiple scenes in Unity... well switching scenes isn't hard. It's not losing your data in between scenes that's hard.

Since we're usually only working on games during jams or in very short time boxes, I inevitably end up reaching for the same old hammer, in this case the Singleton pattern, just to get the job done as quickly as possible... The pain usually comes when we try to do further work on a game and find that the code is a giant fragile ball of spaghetti that's very difficult to modify without breaking anything.

Since we are doing some post-jam work on this game with plans to try and get it onto Steam, I am trying to find a better solution (and to figure out saving games in Unity while I'm at it), but it has caused the post jam work to drag on for very long without tangible result as I need to make an enormous number of interdependent changes to multiple systems to get everything into a better structure.

Hopefully this painful R&D time will pay off for our next game though...

Post-jam Unproductivity

Poorly structured code was one reason for the lack of productivity in post-jam work on this game, but there were few other contributing factors:

  • Work: Cramming development of 2 new feature sets into 2 months was already going to be rough... volunteering to revamp the Spring MVC & Security content for Entelect's Graduate Bootcamp as well was a bit too much.
  • Vacation: I really can't complain about being on vacation for around 3 of the last 10 weeks, but going on vacation is really hard work and it plays hell with your routines.
  • Burnout: I worked insane hours towards the end of this jam to try and get all the bits into a cohesive whole. Then without a break we spent the first weekend of December failing to do Ludum Dare 40 to try and make it 3/3 LDs for the year and then I spent all my game development time for the next 2 weeks reviewing other submissions to GitHub Game Off and trying to gather more reviews for our submission. So I guess by the end of December I needed a bit of break instead of trying to push on with post-jam improvements.

I don't really know how to prevent this in future... it was just an unfortunate confluence of circumstances. The extra time spent on this jam was absolutely worth it and shows in the results we got... trying a second jam in such short succession was probably a mistake, so we should try to avoid that in future.

Points Of Pride

Some of the achievements from this jam that I'm particularly proud of are:

  • Polish: If you disregard the rough CGA style graphics this is probably one of the most polished games we've ever made and we made absolutely everything ourselves!
  • Game Design: I think our jam version is already a better game than the original we were remaking and there's still so much more we're planning to add.
  • Top 20%: Finishing 40/200 was amazing! I don't think we've ever managed higher than 60% in any of our other jam entries.

Efficiency Improvements

The two items that probably took the longest time in the jam were:

  • Object Pooling: We were worried we'd start taking a frame-rate hit from the large number of dead objects still flying about outside the screen edges, so we decided to tackle object pooling quite early on in the jam.
  • Bombs: This feature turned out to be an enormous time sink that ended up with both of us having to get involved to get it across the line.

Implementing object pooling was probably slightly premature optimization on my part, but then again I was doing most of my game development on a weak-sauce laptop that's not equipped for gaming, so perhaps I didn't imagine the slowdowns after a long game... In any event, I think implemented a pretty nice version of object pooling and I should turn that into a library to re-use next time the problem comes up.

Bombs, I suspect, were just too damn complex... Sas struggled with it for a few days and then I jumped in to try and help and once I finally got past a really obtuse bug produced by the interaction of the object pooling and the bomb code I found that the bombs didn't have quite the punch I envisioned. So then I ended up spending even more time improving, tweaking and balancing before I was happy enough with the result to use it. Not much to do there in future except KISS I guess.


I'm perfectly happy with how we prioritized our features this jam.

Nothing on our backlog list is going to make earth shattering changes to the gameplay. It's rather a case now of just adding more stuff for the player to buy and to play with to give the RPG elements a bit more depth and then to use all of that in a campaign mode that has a bit of story progression to draw the player through the game.


New skills learnt in this jam are:

  • Unity's ScriptableObjects as an alternative to using MonoBehavior for everything.
  • Getting the Unity UI to scale correctly across multiple resolutions.
  • First good implementation of an increasing difficulty curve.

Skills I want to learn or improve for next jam:

  • How to art better. I really want to make a game that's fun and beautiful this year.
  • How to compose music. It's the only area where we are currently still completely dependent on 3rd party assets.
  • Figure out a way to structure our projects that will make post-jam work less painful.

Player Feedback

Absolutely everyone loves the sound effects!

At least one person mentioned that the commander I drew on the title screen looks like a badass.

Although no-one mentioned it, from watching people play I suspect the game is a bit too hard for most people and doesn't do a good job of guiding the player through their first few days.

I was quite surprised by some of the positive feedback from other jammers, although in retrospect I wonder how much of it was sincere and how much was just people being nice to try and get a review of their own game in return... I often worry that I am being too harsh in my reviews of other jammers' games, but a part of me also wishes that people reviewing our game would be more brutal in pointing out its flaws. I'll take sincere criticism over insincere flattery any day.

I'm a bit disappointed that only 4/10 jammers that reviewed our game left a comment and of the 4 only 1 had any suggestions for changes or improvements we could make.


I think I might be in love with month-long game jams! Practically speaking we probably don't spend any more hours working on the game in a month long jam than we do in a 72 hour Ludum Dare, however all the extra time for conscious and unconscious thought about the game in between the hours actively working on it are invaluable.

This is without a doubt the best game we've made so far and I can't wait to get past this nasty crew system refactor / scene transition refactor / save games implementation that I'm currently stuck on to see where we can go with this game.