Sponsored By

Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.

Puzzle design through forecasting and assumptions

This write-up is about how I used the player’s expectations about the puzzle platform genre to create puzzles with the aid of some examples from Metrico.

Roy van de Mortel, Blogger

March 16, 2015

10 Min Read

In Metrico you traverse an abstract world of infographics through increasingly complex puzzles. It came out in August last year as part of that month’s PlayStation Plus free line-up, exclusively for PlayStation Vita. Essentially it’s a puzzle platformer in which the bar graphs and other info graphics you walk on react to certain inputs and variables from the game. Ergo: the platforms go up, down and sideways with your actions. These actions can be as obvious as jumping, walking and shooting, or less conventional and even obscure like airtime; the degree at which you tilt your PS Vita or the percentage of red light your camera catches. The goal of the game is to figure out what the infographics in each puzzle react to and planning your steps setting them up in the right way and traversing them towards the exit.


In this write-up I’d like to explain how I used the player’s expectations about the genre to create puzzles with the aid of some examples from Metrico. This piece may contain spoilers for those who haven’t played it yet.

An idea is born

Most of Metrico’s puzzles started out one of two ways. Either from an idea I’m trying to convey as the starting point or the layout from a puzzle.

For example, I knew I wanted at least one puzzle in Metrico where you had to tilt the PlayStation Vita across two axes to progress, because I thought it would be a good idea. How that would actually look was not immediately evident. I also knew we needed a puzzle in which the player had to make use of the timeframe between firing a projectile and hitting its intended target. These examples started out with a clear purpose in the back of my head.

More commonly though I start off with a layout. I simply start drawing random lay-outs on paper that look interesting in terms of composition and come up with the actual puzzle in a later stage. This approach rarely works immediately and often requires a lot of adaptations and iterations, but it’s a good technique to come up with ideas if you have none.

Of course there’s always those (unfortunately rare) occasions where the whole picture just unexplainably pops up in your head and turns out to need only few iterations to be fun. But you can’t sit around and wait for those. Whichever way puzzles are born they all go through the same process of (paper) prototyping; blocking it out, making it functional and tweaking the values.

Arguably the most important step comes next. After deciding whether or not the puzzle is good enough to even make it into the game comes the decision of where to put it. The puzzle on itself may be difficult or easy to your knowing, but the final difficulty of a puzzle in the game as a whole isn’t determined until its relative location to others in the game. A puzzle can be either insanely hard or stupidly easy based on where it’s placed. The immediate adjacent previous puzzle is the most important factor to consider in this. It has planted a certain idea or mechanic in the player’s head that might be interesting to contradict or complement and enhance. Placing the puzzles in order was harder than designing them.

I created a system that categorized puzzles in terms of difficulty, type and certain tiers that tell me what mechanics they use. In the first world for example, there are only puzzles with basic platform variables such as landing and distance. These are tier 1 mechanics that although should still be present in later worlds, must decrease in quantity.An example of a late game tier 4 mechanic is the use of the PS Vita camera. Using this system I decided in which world a puzzle fits best, based on which tier mechanics it contains.


Breaking the assumptions

What’s cool about Metrico for me as a level designer is that, unlike a lot of other games, we did not try and add a lot of stuff on top of the level after the core of the puzzle was done. What you see is what you get and whilst playing you won’t get distracted by elements that aren’t an essential part of the puzzle. In the end most puzzles can be solved through deductive reasoning and a little bit of skill, but it was more interesting to achieve with very limited puzzle parts.

Metrico’s clean presentation ensures that all vital information is visible and readable for players. This allowed me to fully focus on puzzles on a mechanical level and it came with an interesting and intended side effect. Players will easily be tricked and confused by adding non-essential elements to a puzzle once they are in the mindset in which they only expect the bare minimum.



A good and simple example which occurs a few times in Metrico are spawn points that aren’t actually needed. In this example the appointed spawnpoint can be completely ignored, yet isn’t by 90% of the players.





As opposed to adding irrelevant elements it is also interesting to remove them. This example shows the first puzzle where bars that move to your actions are moving off-screen thus confusing the player. At this point it has become a convention in the player's mind that only bars visible to the player move, making it an interesting mechanic to play with.




For me the beauty of Metrico, or any other puzzle game for that matter, lies in the seemingly easy puzzles with very little variables that are yet still challenging and teach the player something. A good example is a puzzle in the first world that we dubbed ‘Quick Jump’

The player is confronted with three consecutive static platforms and to the right of them is a bar that raises each time you land thereby blocking your exit. 95% of the players jump these platforms because they are pretty much taught to do so from other games. Even after several failed attempts and knowing that the obstructing bar reacts to landing, players feel the need to traverse the platforms. The solution is to ignore the platforms al together and land just once, on the ground floor, at the start of the puzzle.


This puzzle does not only help get the player into the mindset of the game, it also teaches that landing without actually jumping still counts as landing and is therefore a viable action to consider in the rest of the game.

Next up I wanted to have an early moment in the game where the player would really feel a bit cheated by the game and maybe even slightly stupid for not coming up with the solution quicker. Even though this might leave the player with a not necessarily good feeling.



In this puzzle it appears the way is blocked by a bar that reaches to the ceiling while in fact the level is a bit higher so the player can go over it rather than through it. The camera will always be centered at the player so all the players needs to do is get to higher ground and try this.



I felt it was a valuable lesson to be thought early on in the game. Think outside the box if your hypothesis about the solution doesn't seem to work. If you teach these kinds of lessons too late in the game in the more complicated puzzles, it’s a lot harder to accept them and doesn’t contribute towards getting the player into the game’s mindset.

I would not feel good about this puzzle if there wasn’t the slightest hint towards the right solution. Because than it would just feel random. It’s hard though to create subtle hints in a game that looks as abstract as Metrico. In this case, if you paid attention to the percentage the appointed bar shows, you could see it can go up further than you initially might have thought.

These types of puzzles lay the foundation of the player’s expectation and ensure that we can get away with even weirder stuff later on in the game. A brief moment of feeling stupidity causes a player to try and think outside of the box more than they normally would or could.

Another good example of playing with the players expectations are Metrico’s enemies. Kill first, ask questions later is a convention that in most games will get you quite far. In Metrico, there are several puzzles in which you need to think about other enemy related variables such as:  the order in which you kill antagonists; the execution speed; the amount of damage they take or whether you kill them at all. This makes for some interesting puzzle variables and means of disconnecting the player expectations with the game. It is so tempting for players to shoot once you can.




Balancing a puzzle game without an adjustable difficulty setting and explicit tutorials can be a troublesome task. A player might be desperately stuck at a point that another player crossed in mere seconds. I think we did well in leaning more towards keeping it difficult than simplifying things.

We’ve discussed this a lot internally. Finding out the right input is an important part of Metrico’s experience so we wanted to tread careful around any help systems if you get stuck. A good system where we would communicate what certain infographics react too, was hard to come up with (especially without text, since a textless game was one of our design goals) and would take away a lot of the fun.

Needless to say I start off testing my own puzzles which, since I know the intended solution, is nothing more than thoroughly testing its functionality. I then go to one of my colleagues to get a good picture about whether or not a seasoned player will get my intentions. Frequently they’ll come up with a better or worse method of solving the puzzle. After isolating the problem I choose to either waterproof it, or to just let it be. In some cases the alternative solution is more interesting than the one I intended. It’s an iterative process of trying to estimate what solution will give the most satisfaction to players.

I won’t preach to the choir by affirming the importance of external play testing, especially for puzzle platformers with a non-adjustable difficulty setting. It’s as much part of being a level designer as designing levels is. Unfortunately as the only level designer in a team that already is as small as it is, we’ve only had limited time and resources to accomplish this. Luckily the first three worlds have been thoroughly tested and improved through people at events we showcased at, such as Pax Prime, Gamescom and E3. Generally speaking it’s safe to assume the more iterations a puzzle undergoes the better it gets, so it makes sense the first half of Metrico is significantly better than the second.


I used a variety of methods to playtest but my most important one was the affect Grid invented by J. Russel, A. Weiss, and G. Mendelsohn as part of a study at University of British Columbia and the University of California. I used it to capture the general feeling a player is left with when playing and upon completing a puzzle. I use this emotion to create a flow in the puzzles and worlds.




Even though I am quite happy how Metrico turned out, the fact that I am the only level designer on the game left me with a feeling it could have been better. Having different puzzle approaches from different designers might have made puzzle selection and order even harder, but it would have improved the game.

Read more about:

Featured Blogs
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like