Tag: postmortem

Dr Strangelove or: How I learned to Playtest and Love Iteration

f590d454– A Post-Mortem


What went right

We made a game, and it was playable. I am honestly proud of this simple fact.

We used the MDA and achieved something adjacent to the aesthetic goals. We cut features in the concept document that would not have aided those goals, and in general had a consideration for the player. Our goals were;

  • feeling of being overwhelmed
  • Constantly in Danger
  • Pressured
  • Fear of a relentless pursuer

We made assets that were regarded positively. We had a very cohesive visual design that was rough around certain edges but in the end mostly worked out.

People seemed to enjoy the game, and I heard a lot of positive feedback from testers in different stages. The game never felt like a complete bore.

We made good use of user stories and we had clear ideas of what the game needed at various stages. We had mostly clear communication and workflow, with some kinks in the mix.

We took Playtest feedback seriously and made changes that took further steps towards the aesthetic goals. We kept consistent data from each playtest

I now feel comfortable navigating and exploring features in Unity, as well as implementing assets. Having one Programmer was an incentive for some of the team to get familiar with Unity. Me, Hampus (game design) and Wiktor(Programmer) became the Unity team, working in Unity Collab since it only allowed 3 people to share a project.

What we ended up with

We made a nail bitingly intense and difficult game where the goal of the player is to guide a submarine through a treacherous and dark 2D environment filled with narrow caves, spiky rocks and hostile fish, all the while being pursued by a giant and evil-looking creature from the depths. The player could shoot small torpedoes at the fish to kill them, and could use a rechargeable speed boost to move forward. The fish damaged the player if they came into contact, and also hindered the player from moving forward, thus aiding the large pursuing fish in catching up to the player. If the creature catches up it eats the player, resulting in instant death. Several checkpoints are strewn about the level, and the player could pick up health as well as a shield boost that would protect the player from damage for a limited time. The player always had to play through an easy tutorial level before being exposed to the real pursuer. If the player got to the end they were greeted by a victory screen.

What went wrong – and what we should have done

We could have done more game designing effort. Too many assets were imported in the game, implemented, and then tested until they fit the minimum criteria for being an asset. We could have done more experimenting early to get something excellent. I can think of plenty of features right now that would have deviated from the concept document, but increased the likelihood of reaching the aesthetic goals if tested.

Gif of the Game

More prototyping. Not just with software, but paper. Make something barely playable and test it. Make ugly art and spaghetti code and throw it away. I have come to learn that Unity is a good engine to prototype in and getting something playable and dirty up and running. Next time I’m getting my hands filthy.

We should have made more mistakes early and failed faster. This could apply to all of us. None of us have been in a similar production pipeline before, so coordinating what needed to be done and when was difficult. For the coder and artists to know that they don’t need art assets because Unity offers squares and shapes. Artists needed to realize that all art created early would be replaced no matter the amount of effort, so make trash before you make fidelity.

The artists of the group (Ellen and me) didn’t always have good ideas of how long individual art assets would take, and so would spend more (or less) time on certain aspects than necessary. These problems were evident on a few items of significant magnitude. This comes with experience, and isn’t something we could have done better at the time. But a good rule of thumb is; if you don’t know how to do something, double your time estimation. Sometimes you should add 25% for good measure. The product backlog exists for a reason; if you finish early you just keep working.

Current state of game Beta 2
Late Beta

We should be slaves to the aesthetic goals, not the mechanics. Don’t be afraid to change something that isn’t working, and examine critically why something is in the game. Does it adhere and add to the aesthetic goal? if not, you can cut it. If it does, make it do that, but even better.  At some point during development the submarine Player character was given 3 health as a placeholder. It was also decided and tested that the player should take damage when colliding with walls. The damage added to the feeling of being constantly in danger, pressured, but it negated the main enemy as the main source of death. This was amplified when the fish enemies also started dealing damage. This didn’t truly become a problem for the aesthetic goals until we changed the level design.

Since those decisions were made the level design had changed a lot due to playtesting and increased experience. The level became harder and more difficult to navigate, and player death was much more likely. We had made checkpoints because we knew the game was difficult and players would need to feel progress in order to stay with it. This was in the concept document, but didn’t really feed into the aesthetic goal. It was at this point (after alpha but before beta) that we became too rigid in certain designs that we had become accustomed to. We didn’t stop and critically examine the mechanics themselves, and rather tried to reinforce the aesthetic goals using the mechanics we already had. Putting mechanics on the chopping block didn’t occur to us in a meaningful enough way to voice those thoughts, as we all believed the game to be good where it was.

All-animationsWe could have doubled down on certain things that made the game engaging; the speedboost mechanic was implemented late in the cycle, but it became apparent to me that it was the main thing that made our movement engaging, and should have been emphasized more.

And finally; group dynamics. Making it clear early what is expected from members when it comes to commitment and engagement, distribution of work and similar. There are many things I could have done to ensure all members were on the same page and engaged with the project; encouraged learning and working in Unity, working in the same room, and making contributions feel meaningful. A better strategy for group coordination would go a long way.

Game Final2

All of this is made possible because I have the luxury of not being in the workforce yet, I am a student. Having a minimum viable product is good but my main objective is knowledge and gaining skill.

I am here to learn, and the best way I learn is to do it wrong with the right intentions.

I count my failures as successes.

I hope these hurdles will aid me in failing faster in the future, because life is like a videogame. If there are obstacles in front of you, at least you know you’re going the right way.


-Benjamin Thomas Harbakk


Thanks Team Ettin for making this an enjoyable experience. I hope you fail quickly in your future endeavors. 😉