(Please note: the following article discusses the game Escapade! in some depth, so it will contain spoilers.)

I'm not much of a puzzle enthusiast myself. The problem with puzzles is that they tend to come in the way of a good story. Now, to contradict myself completely, so far I have released mainly puzzle games myself. With Escapade! the purpose was to make a puzzle game I myself would enjoy as a player.

In Escapade! your goal is to escape a jail cell. The twist is that there are many ways of escaping, but after all but one of the escapes (the final puzzle) you are caught and returned to the cell. At the end of 2008 the game was submitted to the One Room Game Competition 2008 where it took the second place.

Design goals

The number one problem for me when I play puzzle IF is that when I get stuck on a puzzle I don't have the patience to just stop and think about it or start hammering it until I find the answer. I would rather have several puzzles in front of me so that I can go work on another when I draw a blank on one.

The design goal here was just that -- to have more than one puzzle available for the player to work on at all times. (Until they are down to the last one, of course.) In Escapade! there are 11 ways to escape the jail cell, plus the initial puzzle of lighting the room, making a total of 12 (main) puzzles. As is the usual case, each puzzle requires taking some actions in sequence to solve it. Some puzzles require other puzzles to be solved first so that some precondition is met (usually that some item becomes available).

While I wanted multiple simultaneous puzzles, I didn't just want to throw all the puzzles to the player at once, so some of them had to become available gradually as the old ones were solved. Enter H.R., the sarcastic little black monster with acidic spit and a bottomless sack with stuff he's eager to trade. This was an extremely easy way to control what items the player was given and when. After an item was used to solve a puzzle, the player could trade it in for something else.

The puzzle structure map

After coming up with a couple of puzzles I had to find a way to write them down and not just keep everything in my head. Drawing some inspiration from Emily Short's Making of Bronze article I made this mind map of the puzzles and the game states.

(Those who have played the game before might notice that this doesn't represent the game's actual structure 100 % accurately. There were some minor changes made during the end stages of development when the map wasn't of as much use, so I just didn't bother to update it.)

The map was created with CmapTools, a free multi-platform mind mapping software.

In this map

• yellow nodes are escapes, the final solutions to puzzles when the player scores a point.
• green nodes are changes in the world state.
• gray nodes are player actions.
• nodes with no background (just one in this map) are external conditions: timers, plot devices, dei ex machinis, or compex conditions that can't be represented otherwise.

There are arrows leading to and from each node. If an arrow leads from a state to an action, it means that the state makes the action possible: when the light is green (state) you can cross the street (action). These are if-and-only-if conditions: in other words the action requires the world state that is pointing to it. Unless all the state requirements are met, the action fails or does not lead to anywhere meaningful in regards of the world state. If an arrow is pointing from an action to a state, the state change is a result from that action.

There are several benefits to this kind of puzzle map and I used it all the way though the implementation up until the beta testing phase:

1) the map makes sure that there aren't any loops in the puzzle solutions. A loop means you have to do A before you can do B, and you have to do B before you can do A. This is of course impossible which makes the game inevitably unsolvable. An example would be a safe that can't be opened without a key, but the key is inside the safe.

While it might seem like nobody could make such a silly mistake, the image of the whole structure becomes more and more blurry when the design's complexity increases. The loop might consist of fifty nodes in complex patterns and a mistake might be left unnoticed. The developer no doubt notices that the game doesn't work at latest when they have implemented the puzzle, but in the worst case then they will have to re-design the puzzle and discard the unnecessary work they have made in implementing the nonfunctioning puzzle. This is of course less of a concern in a game with more linear plot and puzzles.

How do you know if there's a loop in the design? The rule is that if you can arrange the map so that every arrow points to the same direction, there are no loops. If you use CmapTools, there's a function (ctrl-L or command-L) to auto-arrange the map. The result is a nice and (usually) tidy picture with all arrows pointing down or to the right. If any of the arrows point to the wrong direction, there's a mistake in the design.

2) you have a structure by which to program the game. You can track your progress on the map (I kept a printed copy where I checked off with a pen when a node was programmed). Even more importantly, when you feel like you need to add or change or remove a puzzle you can try the change on the map and see how it affects the rest of the structure.

3) You can control the pacing and the amount of "knots" in the structure. A knot is what I call a puzzle that has to be solved before you can continue with any other puzzle in the game. A knot looks like this in the map (the yellow node):

I had one knot in the game, the initial puzzle. It was there to give a breather between the intro and the 'actual' game and to prevent information overload from overwhelming the player.

My goal was to give the player about three puzzles to solve at any given point, so I made sure the map stayed relatively evenly thick at all points. In different kind of projects you might want the structure to have more variation in this regard.

Consider the following example: in a scifi game the player must find parts to fix their shuttle and escape the moon base. The next scene takes place in a space station with no access back to the moon base. Fixing the shuttle should be a knot because otherwise something in the moon base is a requirement for a puzzle in the space station, and if the player didn't do the required action they've made the game unwinnable. (or you must make sure the required action is something the player can't avoid doing.) Moving from an area to another without the possibility to go back should thus show as a knot in the map.

If you don't mind making a cruel game this is all irrelevant of course. Just let the players know that's the case.

Some reflections on the end result

Overall I'm satisfied with the puzzle structure the game has. Some of the puzzles are not as successfull as others, although I don't consider any of them a complete flop. Apparently some players seemed to think so as well, considering that the game was nominated for the best puzzles and the best individual puzzle XYZZYs.

The game has quite a few pop culture references, but at the beginning it was supposed to have a lot more. Basically it started out as a patchwork of things loaned from other sources, but when the idea refined the characters and items started to form their own identities. (H.R. started out as the Alien from the movie; the Screaming Communists were at first Communist Nazis, borrowed from the Simpsons; Chell from Portal was scheduled to make a cameo and so on.)

At first the idea was to have the "real" escape puzzles and some "bonus" escapes that would be very hard to find unless you knew some obscure reference. For example, you could say XYZZY and you would be teleported in front of the White House. The player character's name, Scotty, is a remnant of a vague idea of having the player "beam up"... This idea was, fortunately, dropped mostly because I couldn't think of any more bonus escapes besides those.

Personally I dislike the flux capasitor puzzle. Some players have specifically mentioned that they liked it, but I think it's too much of a direct steal... uh, loan from the BTTF movies. I'm most content with the catapult puzzle in which you have to repair the catapult and then find something to use as ammunition. Too bad it appeared late in the game so most players probably didn't get that far unless they went back and went for the full score (the final puzzle becomes available after five points (out of the maximum score of 11) so it is possible to win the game before all puzzles are solved.)

The most enlightening part of the whole project was probably the realization of how useful the puzzle map was. I consulted it very often during the implementation because the non-linearity made it impossible to remember such a (relatively) complex structure. I successfully used the same technique with the next game and I have no reason not to use it again in future projects.