An Analysis of Level Designs in Spring It

I wanted to put Spring it, the game I made in 2015, on to Steam.  I think its puzzle style lends itself well to the PC platform and with only a few minor tweaks, we would have it playing well on PC.

Unfortunately, upon playing through it again, and remembering some of the criticism we received previously,  I realized there were some changes that we needed to implement.  I really wanted to tackle the difficulty curve that we had in the game.  The game is hard.  We do not do an appropriate job teaching players about the game before they are thrown into the difficult puzzles.  A lot of this stems from lack of play tests during development and the level of comfort we, the developers, all obtained with the basic mechanics while developing the game.

I went through each of the first 10 levels to analyze what we assumed the players knew and what we expected them to learn.  I then wrote down wrote some of my initial thoughts.  

Tutorial

Assumption: Players know nothing about the game.

Players Learn: They can drag a spring into the game from the UI in the bottom left

Problems: We overlooked the fact that people did not know they could drag springs on top of conveyors and that the conveyors would then hide.  This was probably our biggest failure for the design of the game due to us making the assumption they knew how to do this the entire game.

Level 1 

Level 1 SPring In Action.png

Assumption:  Players learned that they can drag a spring into the scene from the UI and those spring can be placed on top of conveyors. Players do this 3 times to reinforce this action.

Players Learn:  How to better drag springs, Maybe eve how far the springs will launch a robot horizontally.

Problems: Players can still complete the level without ever learning that springs can be placed on conveyors.

Level 2

In this level players need to deal with the aspect that robots launched from springs have a height component as well as their horizontal one.  Player also must place springs on both the floor and over top of conveyors. This is the first level where players can use less springs than they are provided to obtain a better end level score.

Assumptions:  Same knowledge as last level, just improved comfort with actual mechanics of placement.

Players learn: If they use one too many springs, they will only get two bolts instead of the usual three. (I feel this is a bit too early to teach the players the aspect of mastery)

Level 3

Level 3 Spring It Design Blog.png

Assumption:  Players know they can place springs over top of the conveyors and that this hides the conveyor, springs can be placed on both floor and conveyor. Same assumptions as levels 1 and 2.

Players Learn: Reverse conveyor cause robots to move int he opposite direction and how to solve the 3 length gap problem with a spring (players need to place a spring in the middle of a 3 length gap on the floor).  

Just looking at these first three levels, I can tell there is too much being thrown at the player and we did not really analyze what they were doing at each step.  This gave me a better idea for how to reorganize the flow of the game levels.

Proposed solution

Have the tutorial level start with the three length gap problem and teach the players just to place springs into the level on the floor.  This way we are only teaching placement rather than both placement and replacing conveyors and we are embracing the what the player's inutively thought, that springs cannot replace conveyors.

Level 1 is then modified slightly so the players place the springs on the floor.

Level 2 is where we teach that springs can be place on top of conveyors to replace them

Level 3 is the previous level 2 so the players can practice placing springs on the floor and over top of conveyors.

Just this simple change should ease players into the game play more comfortably than before while still keeping in mind how people play the game when first starting out.

The Remaining 7 levels

The biggest shock the players face is when they see level 10. 

Level 10 is daunting.  It has almost every previous mechanic presented being used but to a new player, these all feel like unfamiliar mechanics.  Rather than a test or boss fight combining all that they learned, it appears as a string of entirely new problems.

Here I listed all the mechanics and problem we were trying to introduce up to this point along with their quantity present in this level:

  • Doors - 2
  • Magnet - 1
  • Cannon - 1
  • Furnace gap - 1
  • Fans - 0
  • Moving an object after it was placed to continue to progress a level - 1
  • Reverse conveyors - 1 set (I am only counting the upper length because they obstruct the player's progression while the lower set helps the player)

Now the above list can be daunting but is expected of a test level.  So the level's design is not necessarily the problem.  The problem is preparation leading up to the level itself.

Looking at the previous 10 levels, I created a list tallying the number of times each mechanic was used in the first 9 levels:

  • Doors - 1
  • Magnet - 1
  • Cannon - 1
  • Furnace - 3 (but only 1 Furnace gap)
  • Fans 2
  • Moving an Object after it was placed to continue to progress a level - 1 
  • Reverse Conveyors - 3

As you can tell although players have seen all of these mechanics before, I would argue that only the reverse conveyors and the furnaces are problems the players are familiar with.  So we, as developers, did not provide enough practice leading up to this level, and as a result this level comes across as daunting and near impossible.

Conclusion

This is not a post I would have been able to write when we released Spring It! in 2015. I just did not have the correct mindset.  Due to my involvement with the development itself, certain actions, like dragging objects into the level and the functionality of the mechanics were already second nature to me.  So when I personally played the levels, I only played them to make sure I was still being challenged, if only slightly, and that the levels themselves were interesting.

The obvious way to prevent this problem would have been, play test more often and more efficiently, but that is way easier said than done.  It can be difficult to find frequent quality play testers.  I am writing this to present a mindset or methodology to think about your levels in a way to better teach your players how to play your game.  Now this will not replace good play tests, but it will narrow down what you are focusing on when you do play test, so you can better analyze the results and maybe even catch things before you start testing.

For each level, try and only teach the player 1 new thing.  Write what the goal of the level is, along with what you assume they will have known at this point.  When you watch them play you can see if your assumptions hold true.  If they do not, you needed to provide them more or better practice previously.   Next you can analyze the level itself to ensure it is properly teaching the players what you wanted.  

People talk about interest curves for player excitement but I think it is important to reference them when teaching new mechanics as well.  The peaks should be your new mechanics being introduced, while the troughs are the reinforcement of those mechanics.  I included a image of Star Wars: A New Hope's interest curve as a reference because I frequently use it myself.

pacing-example.gif