Designing Puzzles Backwards (Part II)

In Part I of this article, writer-designer Steve Ince gives an overview of how story, plot, and gameplay feed into puzzle creation in a game. In Part II, he gives an example of the process.

During my time at Revolution Software I was fortunate to work with some talented people and much of what I learned about developing and refining of puzzles comes from that period. When we developed the second Broken Sword game, The Smoking Mirror, the designers came up with one of my favourite puzzles (I was actually producer on that title).

The player character, George, arrives at the Marseilles docks at night and needs to find a specific warehouse. Unfortunately, there is a fence barring his way. The objective here is to get over that fence – it’s clear what the player needs to do and only by getting over the fence can the story progress.

Now we know the player character’s objective, how do we stop him from simply climbing over the fence? (We’ve started asking the questions.) A vicious dog is placed at the other side of the fence which makes its intentions clear as soon as the player interacts with the fence.

How will the player deal with the dog? It needs to be distracted in some way.

What can we use to distract the dog? There are biscuits inside the hut.

How do we make this more complex? There’s also a man inside the hut and the door to the hut is on the other side of the fence.

We now have two additional sub-objectives to complete that feed into the main objective of distracting the dog to climb the fence – the player must distract the man and find a way into the hut to get the biscuits.

Of course, it’s possible for George to talk to the guy in the hut, but although the conversation is fun and somewhat informative, it’s not the solution to this puzzle. What the conversation does, though, is to give the player logical options to try. If the player sees a guy in a hut it’s natural to tap on the window and have a chat.

As the details of the puzzle were expanded, not only did they add to the richness of the puzzle, they also helped define the geography of the location. For instance, the need for a trapdoor in the floor of the hut meant that we needed the player character to be able to get to the area beneath the hut without this giving a means to get to the other side of the fence.
Anyone interested in learning further details may like to play the game for themselves. :)

It may seem to make sense that, when working backwards in this way, you continue the process until you reach the previous objective conclusion. However, this only works if the game is completely linear.

It may be that you need to work backwards until you reach the point the player finds out what this objective is. During gameplay, reaching the previous objective could give the information to player about this objective, but there might be other ways the player gets such information. Half way towards an objective the player may discover information that gives him additional objectives that will now run in parallel to the current one.

With multiple objectives, working backwards must end up with the same starting point for each, which can be a good check that the puzzles are sound.

Like anything else used in the development of a game design, working backwards in this way is just a tool as part of a whole range. No matter how well used this tool is, it isn’t a complete solution.

The ultimate test of this kind of puzzle is to think it through forwards as if playing the game in your head, looking for potential problems, logic flaws, lack of clarity and ways to refine the steps of the puzzle.

Design it backwards, think it through forwards. Reiterate.

Steve Ince is a Writer-Designer with 17 years in game development. After 11 years with Revolution Software, Steve turned freelance in 2004. In 2008 he received an award nomination from the Writers’ Guild of Great Britain for the game, So Blonde.

November 2010 Poll

Please vote for the November 2010 topic!

You'll see the poll to the right. The choices are:

• Cheats
• Sequels
• Designing for Demographics

Please vote by November 1. Thank you!

Designing Puzzles Backwards (Part I)

In Part I of this article, writer-designer Steve Ince gives an overview of how story, plot, and gameplay feed into puzzle creation in a game.

I’ve spent most of my game development career working on various story-based games; mostly traditional adventures but other types, too. Although there are different kinds of puzzles involved in the creation of such a game, the kind I find most satisfying are the ones that tie the gameplay directly into the story by the means of shared objectives.

When I’m fortunate to have the opportunity to create both the story and design of a game, as I did with So Blonde, for instance, I like to work in a very iterative manner. I get the basic structure of the story sorted before working up some detail, which then allows me to start defining the gameplay objectives based upon that story, which then feeds back into the developing plot. By working this way, the plot becomes a high level structure that gives both the gameplay and story the shape it needs and enables me to start working up the puzzle details.

When I’m in a position to work on an objective related puzzle, I find it’s best to start with the objective and work backwards. By taking this approach I ensure that each step of the puzzle – or other gameplay that feeds into the puzzle – links to the objective in a clear way.

As I work on such puzzles I loosely go through a series of questions that help with the process.

• What is the objective?
• What is stopping the player character from reaching that objective?
• How will the player deal with that blockage?
• How will the player get the items/skills needed to do so?
• Are there separate or side objectives the player has to deal with in order to get what’s required?
• How can I make this more complex?
• How can I make this more fun?
• Is this series of events logical?
• Is it clear to the player what they need to achieve and what they need to do to achieve it?

There may be plenty more questions relating to the specifics of a puzzle or the objects used and even the user interface, but the main thing to remember is that if you’re not asking yourself these kinds of questions, you’ve got to ask yourself why not.

Steve Ince is a Writer-Designer with 17 years in game development. After 11 years with Revolution Software, Steve turned freelance in 2004. In 2008 he received an award nomination from the Writers’ Guild of Great Britain for the game, So Blonde.

October 2010: Puzzles

October 2010's topic, Puzzles, was submitted by postdoctoral researcher Clara Fernández-Vara.

She writes:


Puzzles are one of the most common design challenges in games, and yet their design practices remain largely undiscussed. This is because puzzles come in many shapes and sizes. Professor Layton includes a wide range of traditional puzzles (logic puzzles, riddles, jigsaws, etc.). Metroid, Zelda and Ico are packed with environmental puzzles where the player must make sense of the space and manipulate its objects in order to traverse it; adventure games bring together story and gameplay by having each puzzle be an event in the story of the game. There is also a whole genre we refer to as puzzle games, such as Zuma, Tetris or Bust-a-Move / Puzzle Bobble.

This month, Game Design Aspect of the Month wants to encourage everyone to think about their practices to create puzzles in their games, and realize that puzzles are much more common than most designers will readily admit.

• How do puzzles contribute to the gameplay of the game? If the game is puzzle-driven, how is it fun? If puzzles are just one type of challenge in the game, how do they relate to the rest of the activities in the game?
• How can the story be supported by puzzle design? How do the puzzles relate to world design?
• How does one get started devising a puzzle? How can designers evaluate if it is a good puzzle? What practices should be avoided?

Clara Fernández-Vara is a Postdoctoral Researcher at the Singapore-MIT GAMBIT Game Lab. Her work concentrates on adventure games, as well as the integration of stories in simulated environments.

Using Collectibles for Player-Controlled Difficulty

In this article, game designer Doug Hill discusses how game designers can use collectibles to allow players to adjust difficulty levels in games.

In his article Risk Vs. Reward: TACOs, Achievements, and YOU, Ryon Levitt discusses the relationship between the risk a player must consider in getting a collectible versus the reward of obtaining it. This article will consider the opposite side of this problem: taking a risk by not collecting something.

In the original NES classic The Legend of Zelda, you don't have to collect everything to beat the game. You don't even have to collect half of the items. If need proof, search for a speed run of The Legend of Zelda and you will soon see players beating the game from start to finish in around thirty minutes. These players manage to beat every boss and finish every dungeon while only getting a fraction of the game's plentiful power-ups.

So how these players accomplish something like this? Practice and planning. They learn the game forwards and backwards. They learn the enemy's attack scripting and spawn algorithms. They become so proficient that they no longer have to worry about getting all of the Heart Containers to increase their health. They don't have to worry about gathering enough money to buy the Blue Ring armor upgrade. They don't have to find the hidden letter to access the medicine shop. They have more than enough skill to beat the game without these items.

Most of us mere mortals, on the other hand, need a bit of a boost. The question is – how much of a boost? The nice thing about The Legend of Zelda and other games like it is the decision is left (mostly) in the hands of the player. It lets the player continue to collect all kinds of power-ups until they feel they have enough firepower to get through a dungeon. If the player fails, they can also go and collect more power-ups so they'll have a better chance when they try again. That is, unless the player has collected all of the power-ups already.

This school of game design is one of the primary reasons that many genres of games have garnered such a widely diverse fan base. Consider the role playing game, where players have the option of trying to collect extra treasure in order to become more powerful. In this case, the player is actually choosing which risk to take – go on to an area with stronger enemies or possibly a boss without getting stronger, or go after the treasure while having to fight additional foes? Even levels and experience can be considered collectibles that put the player in control of how strong they are before they attempt to move forward.

The point I'm trying to make is that, as game designers, we should not focus on making our games specifically easy or hard. Instead, we should try to leave as much of the difficulty level decision as possible in the hands of the players. If they want their game to be easy, we should let it be easy. Give the players cheat codes. Give them extra power ups. Litter useful items everywhere. Give them difficulty levels where they barely take damage and almost never run out of ammo. If your game is fun to play in and of itself, being easy shouldn't hurt it too much.

On the other hand, make sure you give a challenge to the players who want it. This can be through harder difficulty levels, achievements and trophies, or more difficult replays after they've defeated the easy mode. Most importantly, make sure they have choices during the game, not just before they start and after they finish. Give players weapons and power-ups they can skip and not use. Give them shortcuts they can choose to ignore. Give them easy and hard ways to kill bosses.

In the end, you'll get more players to appreciate your game. It won't feel too hard, while those seeking a challenge will find one without having to look too hard.

Doug Hill is a freelance game designer and writer who has worked on a variety of published video games over the past ten years. His current focus is developing intellectual property for use in both interactive and non-interactive media.