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.