The Postmortem Megamix

Postmortems are an important step in game jams. It's a rushed process, and it's easy to get caught up in the experience and not notice the mistakes you're making. Hindsight is 20/20 though, and rather than write lengthy explanations of what went right/wrong each time, I thought I'd lay it out simply to show what mistakes were made each jam, and which ones we figured out how to prevent.


Things that went right:Things that went wrong:

The generated world for Every Night worked well right from the start. Everything was prototyped on paper first, which helped nail down the generation process early.

My goals for the art were too high, and I fell short of them, due mostly to inexperience in doing pixel art. The game may have been better served with flatter graphics that were more consistent.

The very first thing that was prototyped was enemy behaviour. The first playable build consisted of the player character and continually spawning enemies as dots. Every enemy type was a variation on the same behaviour loop, so tweaking the enemies later was easy.

There was not enough of a feedback loop between the player's actions in the "dream world" and the "waking world" - this could have been as simple as adding a sound effect, but I didn't notice the disconnect because I knew what aspects of the dreamworld were important.

Every Night was very limited in scope, consisting mostly of a single engine, a single player loop, and a single enemy loop.

If the game went on too long (due to the player not unlocking things), the player eventually became massively overpowered, and required an even more overpowered enemy to force a fail state.

The core gameplay was the first thing built and tested, which allowed continual tweaking throughout the process as more things got added to keep it fun and challenging.

There were massive memory issues when starting a new game, and in fact, if the game restarted too many times, the game would slow to a crawl.

"Levelling up" felt meaningful - there were obvious, immediate, visual changes to the health bars and slash animations.

Due to the goals not being clear, the game went on a bit too long and got a bit repetitive.


Things that went right:Things that went wrong:

Mid-way through the development, I stopped working on the game itself to make a level editor gui, which greatly sped up the creation of levels later on, and made fixing problems much easier.

Mallow drop suffered greatly from a continual scope creep. There were many aspects of the game that were cut towards the end of development which should have been closed off earlier on.

Spritesheets were implemented early on, which meant the game looked good and animations were built into the the game early.

The number of levels was set early on at 100. This was very ambitious, and if I had the time back, I'd have launched the game with 20 levels, polished, and released other levels as updates.

Mallow drop started out as a physics sandbox, which allowed the creation of a lot more elements than actually made it into the game, and the core gameplay was distilled from hours of experimentation, rather than starting with an idea and following it.

The dual gravity system was too ambitious for a first game. This lead to several updates and revisions of the core physics system, which meant that previously working levels needed to be changed as well.

The event tracking in-game works fairly well, and showed where things were going wrong early on.

The enemies were kind of boring.

The interaction and controls were built around the device, and ended up fairly polished.

The gameplay required lots of geometry for complexity. Interesting levels meant more geometry than low powered devices could handle.


Things that went right:Things that went wrong:

The hand-drawn background looked great and worked well, and contributed to the feel of the game really well.

The graphics were too dark, and not very readable.

The core gameplay stood out and was made possible through figuring out the process with paper prototypes.

The levels were too samey, so there was no sense of progression.

The engine and object pooling worked well.

The random generation occasionally created levels that couldn't be completed. This was a problem that wasn't caught before release.

Lighthouse pushed a complex idea in a simple 'prototype' environment which let me spend most of the dev time on getting one thing really right, rather than making sure different systems worked together.

The on-screen controls were not made clear enough for some users.

Randomly generating the levels got the game to the playtesting phase quickly.

The platform tiles didn't match the style of the background very well.


Things that went right:Things that went wrong:

The time frame was extremely short (8 hours) and the scope was kept reasonably in step with that.

I didn't leave time for start/end screens or menus.

The object pooling system adapted from lighthouse worked well from the start.

The game didn't have an end, other than running out of life.

The gameplay was fun, if short.

There was no graphical indication of damage or progress.


Things that went right:Things that went wrong:

Theft had a very simple level design structure, and so it was easy to go from 1 level to 3.

There were persistent memory issues through the development process. Guards frequently disappeared because the object pool didn't work properly.

There was a good game concept at the core. Get in, take something, get out.

The AI was not great - I had planned that the guards would walk back and forth between two points, but this was scrapped and the guards just walked from one side of the level and out the other side. This led to some cheap deaths when a guard entered from the side.

The gameplay was balanced well, with moments of tension caused simply by the differing speeds between when you are carrying the painting and when you aren't.

The colour-changing mechanic was not terribly intuitive

The game was hard, yet simple enough that it was clear HOW to win the game.

The UI was hard to take in, as the colour indicators were not near the character.

The EGA colour scheme was fun to work with, and fairly quick to get basic mockups working.

There was not enough in-game messaging of what to do


Things that went right:Things that went wrong:

Memory issues were well managed from the start

We were all separated during the brainstorming stage, which lead to a relatively unimaginative concept.

The AI was fairly simple, but looked more organic than in other games.

There was too much information for a simple UI to work well - Important things like health and weapon status got left out due to time limit.

The game had a very simple control scheme (arrows, jump + shoot) which let people jump in and get moving quickly.

There were asset pipeline issues going from a coloured-rectangles build to a full graphics build.

The gameplay was fun, and reenforced by the humour in the notifications.

The sprite based backgrounds were too time consuming to finish in time.

The music and graphics plugged in quickly because all the audio code was pre-built.

The 3-way balance system too complicated, perhaps 2 would have been for a first level.