Wrong. Players would play for some while, then LOOK and go “Didn’t I pick that up already?” or INVENTORY and “* BUG: I never dropped those items”. They hadn’t noticed or didn’t remember anymore that the game had said “(first dropping X, Y and Z to make room)” when they had picked up something big earlier.

Lessons learned:

• Don’t put relevant information to places where the players don’t expect to find information. Players don’t expect command clarifications to contain anything other than notifications of implicit actions, and they expect TAKE ALL to just list items and “taken”, so they don’t pay them any more attention than that.
• Don’t expect the players to read room descriptions anymore after the first time. If a room’s description changes during the game and that change contains important information, make sure the players know they should re-read the description or convey the information to them also in some other way.
• Don’t expect the players to remember what they have read after a few turns.

It’d be interesting to hook a couple of players with different levels of playing experience into an eye tracker and study what parts they tend to skip or skim when playing.

We’re aiming to release at the beginning of September, in time for PAX Prime and before IFcomp starts to avoid being overshadowed.

For my part the project progresses roughly according to following plan:

1. Sketching the general theme, plot structure and characters.
2. Writing more accurate character bios, rough but complete plot from start to finish and details of the fictional world where the game takes place.
3. Plot map, similar to the puzzle map used in Escapade! (although the game is essentially linear so it’s just an overview of puzzles and plot events.)
4. Mock transcript of a complete playthrough of the game. When we start coding we’ll use the mock transcript as a model with which to craft the game.
5. Alpha testing where other people read through the mock transcript and other design documents and offer their opinions. The purpose is to find large-scale problems at this point (changes to plot or puzzles, map structure, character voices) that can be fixed before they are coded. When a project reaches beta-testing stage it’s usually too late to do anything other than relatively minor changes to the game structure.
6. Coding the game. Unlike previously announced, this will be done in Inform 7 for two reasons: the main reason is that you can’t play TADS games online yet, which is a major factor if you want the barrier to entry to be as low as possible. The other reason is that I’m more familiar with I7 so I don’t have to spend the relatively short implementation time learning the system. I’ll set up a project at Google Code where anyone can follow how the coding progresses and contribute to the issue tracker.
7. Beta testing. This is the phase where bugs, typos and minor design problems are ironed out.
8. Release at the beginning of September if everything goes as planned.

Right now I’ve just started with #4. The schedule is such that approximately 1/3 of the time is used for preparations, 1/3 for coding and the rest 1/3 for testing. This seems like a reasonable divide, especially if the thorough planning speeds up the coding phase.

If you have any ideas regarding the project you can leave your comments here, on the wiki, or by e-mail (juhana.if @ this blog’s address.) We’ll be needing people during alpha and beta testing so keep that in mind if you have extra time later this month and during August.

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.

The puzzle structure map for Escapade! (partial, click for full image)

(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.

1. Proofread the intro

Naturally you should proofread and have others proofread the entire game, but pay special attention to the intro text and the room description of the first room. Go through the text twice, then twice more, then with proofreading software, then let someone else proofread it. With every word you’re not 100 % sure how to spell it, check it with a dictionary.

Players are willing to forgive occasional typos and stray punctuation the further in the game they are, but when they see one right as the game starts they go “oh, it’s one of those games again” and it takes a lot of effort to win back their confidence.

2. Add a description of the player character

There’s nothing that says low quality louder than “As good-looking as ever” or “You look the same as usual.” Even if you have designed your player character to be AFGNCAAP you should have something to say about the main character of your story.

You don’t have to spend hours fine-tuning the player character’s description. Anything is better than the library default, even if it’s just “You’re ok.”

At this point I would also like to add that having a witty twist of the default message, like “Not as good-looking as ever” or similar, has been done about ten million times already and is not witty anymore. The same goes with going for irony or trying to emphasize the anonymous nature of the player character by leaving the default message as it is on purpose — it just won’t work, and players won’t get it.

3. Add a response to ABOUT

The players often want to know more about the game and its author. ABOUT could contain a summary of available in-game instructions and hints, credits, mention about other included files and feelies, game’s home page and the author’s email address. Making INFO and HELP synonyms to ABOUT is also a good idea (unless HELP is used to invoke a hint system.)

4. Have VERBOSE on by default

VERBOSE means that all room descriptions are fully shown every time the player enters a room, even when they have seen the description before. Brief mode in contrast shows the descriptions only for the first time the player enters the room and after that only when the player types LOOK.

This is possibly the controversial one of this list, but most players I know of turn long room descriptions on as soon as they see that they aren’t already. I don’t know of anyone who would switch to brief descriptions if verbose is enabled by default.

Edit: The new Inform 7 release (6E59) has made VERBOSE mode the default and removed scenery from GET ALL, so thankfully future I7 games won’t suffer from those faults.

The game can be set to verbose mode in Inform 7 with this line:

TADS has verbose mode on by default. I don’t know why Inform insists on preferring brief room descriptions; possibly because of historical reasons.

5. Remove scenery from GET ALL

In Inform when the player types GET ALL (or any other verb that supports multiple nouns) the game interprets it as an attempt to pick up absolutely everything in the location, including scenery, people and things fixed in place. It’s a well known trick to type GET ALL to see all the objects that are implemented in the room and force the game to reveal its secrets.

These lines remove abovementioned things from GET ALL in Inform 7: (fixed in 6E59)

(This is another thing that TADS’s library handles better by default.)