Tag: devblog

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. 😉


Scrum in team Ettin

How a Scrum Works

This is to make the un-initiated understand the basics of what Scrum is, and how it can be used as a framework. Feel free to skip if you understand Scrum.

The basic principles of Scrum is to work in an iterative environment consisting of small teams that self-organize tasks that need to be performed in order to ship a product. Some roles in the team are:

Product Owner– The person or entity the team is working for, and determines the overall priority of features and their order of implementation. The product owner is the one who sets out the requirements for the project. For our purposes, the Product Owner role is a combination of the faculty responsible for Game Design 2, and the Project Manager.

Scrum Master – Facilitates communication between the Product Owner and the team, and ensures that critical meetings can occur. Irons out any hiccups in the production pipeline, keep the team up to date and improve their productivity in whatever way possible. Is the keeper of the “Scrum Bible” and is there to answer any questions and make sure Scrum is utilized to it’s fullest potential.


What is essential for Scrum?

Product Backlog – detailed list of features, assets and artifacts that are planned for the product, with varying levels of priority.

Sprints – 1 or 2 week periods that start on Monday and end on Friday, where work is done on small contained parts of the product, planned in the Sprint Planning meeting and reviewed on the Sprint Review meeting, on Monday and Friday respectively.

Sprint Planning – Plan out and allocate time for tasks that need to be done for the current sprint. Each member takes on tasks that they feel they can perform, and estimates the amount of time they expect to be able to put into that task. A Quality Assurance reviewer is assigned to each task, to aid in keeping the task do-er accountable.

Sprint Review – The estimated time for each task is reviewed and evaluated. How well the feature is implemented and notes for what worked and didn’t work are noted down.

Daily Stand Up – Quick 10-15 minute meetings that occurs every workday where the members can share what they worked on since last stand up meeting, and what they will work on next.

Minimum Viable Product– The idea that most steps, assets and parts of the project will contribute to a minimum viable product for shipping. We are not building a car over 12 months by painstakingly crafting every mechanical metal part and putting them together at the end. We are putting a stick between two wheels and adding bits and bobs until it’s safe enough to stand on, and build from there. Iteration is the name of the game.

What benefits have we experienced?

Gif of the Game.gif

What I deem the most valuable aspect of Scrum is that it empowers the individuals in a team to find work they would like to do. Most work is “grabbed” by the individual who wants it, and in most likelihood the person most capable to complete the task. The process is more satisfying than to be assigned a task, even though that might happen to tasks that no members want to tackle every now and then. Overall it leads to a more gratifying workload where you work on things that you feel a slight excitement for, most of the time.

It rewards strong willed and motivated people with a good sense of progression and development. If using good documentation it’s easy to see how much work has been put into the project, and get a sense of satisfaction. In our project specifically I have been very happy to be able to test out my assets through every step of the way and detect problems early in the process. From this I have had enough time to change the work pipeline to prevent a lot of work from being wasted. These changes include:

30x30 and 60x60

  • Size of the Player Character  compared to other objects
  • Size of Tiles
  • Types of Tiles that need to be created
  • Size of the Big Enemy
  • Distance of camera from play-area
  • Visual design of certain objects (Testers pointed out the Shield Pickup looks like a mine)
Early Shield powerup.

These changes are especially important to me as an Artist, since re-scaling assets is tricky and doesn’t work for Pixel-art most of the time, and re-drawing high detailed art leads to a lot of wasted time. Through iterative development most of these issues were discovered organically, using low-effort art assets. But development is more than just art, and we also worked on these issues:

small gif of shooting

  • Constant change of player movement mechanics
  • Focus (or non-focus) on lighting for game-play mechanics
  • Mechanics of aiming and shooting

Through iterative development where we could constantly test these aspects of the game, problems would be discovered and eventually resolved throughout the process. This might have saved us from many hours of wasted work, or work being put into a faulty product.

So what’s the Verdict?

One of the biggest strength and weakness of the framework is that it puts a lot of trust on the individuals to find and do work. Sometimes people do not feel confident enough in their own ability to tackle a problem, and tasks that are within their skills fall to other members who might be better suited to handle other problems. A well functioning team can compensate and make sure that everyone does tasks that are suitable for them, but this can sometimes be tricky.

Scrum works best in a team of self-motivating, closely knit and interdependent teammates that hold each other accountable and are excited about the project. Individual work is highly valued and easy to see, and feeds back into the motivational aspect of wanting to do work for the group. Quick feedback loops and visible progression, both in the moment and over time strengthen the feeling of cooperation towards a common goal. It is a valuable tool, but it can be abused intentionally and accidentally.

-Benjamin Thomas Harbakk


EDIT: Here is the Comment I made for this week’s assignment