How are puzzle games designed? Teddy Lee 5


Teddy Lee (from Cellar Door Games) created several popular flash games, among them the platform puzzler My First Quantum Translocator (MFQT), the infamous adventure puzzle game Don’t Shit Your Pants, and recently I Have 1 Day, an adventure puzzle game with an interesting meta task-scheduling puzzle on top.

In My First Quantum Translocator the player is trying to escape from a building, assisted by the mysterious Steve and of course a quantum translocator. The translocator can be used to teleport instantly from one position to another one previously set up, while maintaining momentum. Impassable, moving lasers and platforms that are too high to reach by jumping make up some of the difficulties the player has to overcome. In addition to brainpower, the game also requires some skill in performing the jumping and timing actions to execute solutions.

My First Quantum Translocator was one of Indie Games’ selection of top 10 free puzzle games of 2010.

Below, Teddy Lee responds to our questions (part of our puzzle game design interview series).

Dev.Mag: What are the qualities of a good puzzle?

A good puzzle to me is when the designer uses the core mechanic in ways players don’t expect. I feel like when we design something clever, players enjoy it just as much as we do.

Dev.Mag: What process do you follow to design puzzles?

When we made puzzles for My First Quantum Translocator (MFQT), we had a few guidelines which we tried our best to follow.

1. Never re-use puzzles

If two stages were too similar, we would can one of them. It makes things difficult since you’re always trying to do something new, but the end results are always worth it. We found that starting with the solution and then going backwards worked well for us.

Excel Snapshot

A lot of our stages were originally designed in an Excel doc before being put into the game.

2. Each room highlighted one trick, or mechanic

If you add too many steps to a puzzle you lose the player because you can’t always assume the player is following your train of thought.  We also removed any filler/time wasters/red herrings in order to keep this visual clutter to an absolute minimum (unless the puzzle itself was a red herring).

3. Do not have any “Misleading Paths”

This means that if our player is doing a puzzle incorrectly, they should immediately know they are doing it wrong.

For example, if you are playing a platformer, and the user is always just millimeters away from making a jump, then the user might keep trying to make that impossible jump. So we spent a lot of time trying to remove every possible instance of a “Misleading Path”.

4. The joy in solving a puzzle games is in the success, not the attempts

The core mechanics for MFQT required a certain amount of dexterity on the player’s behalf, but we tried our best to keep it to a minimum while still retaining the core feel of the stages.

For example, we added the “tele-jump” later in the game which automatically jumped and teleported the player. That way they no longer had to pull off that difficult maneuver.

In one of our more skill-based levels, we revamped the bottom right junction and stretched the upper platforms.

Old Wall Ceiling Move StageOld level. New level.

Dev.Mag: In a sequence of puzzles based on a small set of mechanics, how do you make sure the puzzles stay interesting?

The misconception is that having a small set of mechanics means you’ll be very limited in the things you can do. That’s not necessarily the case though.  As long as you can keep wringing out new puzzles from the core mechanics, then the game will stay interesting.

A rule of thumb I follow is if I can think up five or more puzzles on paper with a single mechanic, then there’s a good chance I can come up with plenty more later on.

Dev.Mag: How do you judge whether a puzzle is fun, and how difficult it is to solve?

It’s impossible to know off the bat whether a puzzle is fun or not.  The only thing you can do is playtest it, and if you like it, have someone else playtest it and see if they like it.  If we don’t enjoy completing a level though, we usually look at it and see what’s not fun about it. That way we won’t make the same mistake again.

As for difficulty, we generally base that off of how much dexterity is required to complete a stage, and how much of the stage’s puzzle is built off of previous knowledge.  Of course, extensive playtests from other people help us isolate the trouble spots.

When designing MFQT, we also staggered puzzles which had a similar theme (such as modifying trampoline bounce height) so that players wouldn’t get similar puzzle types in a row. We also staggered the difficulty, so that after a particularly difficult stage, a player might bump into a few easy ones to sort of keep their morale high. Small things like that helped to keep the game fresh.  We had to tweak the stage layout for our game a couple of times to get it to where it is.

One of our regrets with MFQT was the second last level (the rotating squares with the red cross). I really liked the level, but in the end a lot of people couldn’t complete it.  Even though we had a skip button, nobody really wanted to use it, especially when they were so close to the end.

Quantum_Compilation_Change This image shows how levels have been re-arranged over time. Click on it for a larger view.

Dev.Mag: Do you use strategies in your design to guide the player towards the solution, and help them understand the logic of the puzzles?

When we design a puzzle, we try to keep visual clutter to minimum so as to not distract the player from the actual goal.

Also, when the solution requires a certain amount of dexterity, we sometimes leave visual “markers” so that players know where to position their attempts. For example, in our “elevator” stage in MFQT, we used 2 background assets as indicators to show the player when to jump, and when to set a shadow.  That way, when a player knows the solution, they have some type of marker they can compare themselves to in order to refine their solution.

Elevator IndicatorsLevel with markers to help the player time actions.

Dev.Mag: Do you have any advice for those who want to design their own puzzles?

Make sure to iterate, refine, and polish your stages off. I feel like many designers making puzzle games think they can skip these steps since their games may require little to no dexterity. So you end up with all these physics based puzzle games, where the solution always end up being more about pixel perfect placement and less about clever solutions.

Oh, and if you run into problems with a level and things aren’t working out, don’t be afraid to cut. It’s always better to have someone beat your game than not.

About Dev.Mag

A game development magazine featuring tutorials and game development insight. Created by South African game developers and hobbyists.