One of the most useful advice that has proved its worth to me again and again, both in creative work and in business life, is "fail early, fail often." It might sound counterintuitive, but it simply means "have a lot of ideas, discard the bad ones before you've spent too much time on them." The word "failure" is used here in the most positive connotation it can have.

Not all ideas are equal. In the best case scenario you get an idea, realize immediately that it's not viable, and discard it. Even though the idea was a failure it was useful because you can now focus on better ideas. If you have 100 ideas it's best to shift through them quickly instead of finding the hard way which of them is the gold nugget.

Even if a project is based on a good idea, the details will need constant revisiting.

Don't let a bad idea get past the point of no return.

The creators of Back to the Future had always envisioned Michael J. Fox to play the protagonist, Marty McFly. When the filming started Fox was unavailable because he was starring in a popular sitcom Family Ties. Eric Stoltz, an up-and-coming young actor, was cast instead.

In an alternate timeline, Stoltz was the star of the film. (Screen capture from Fringe.)

In late 1984, after a few weeks of filming, it became clear that Stoltz wasn't right for the part. He was by all accounts a good actor but he just didn't have the personality or the comedic sense that the part required.

At this point they had basically three choices. Keep filming with Stoltz, risking an inferior end result; change the lead to someone else; or try again to get Michael J. Fox on board. Thankfully they went with the third option and managed to strike a deal with Fox and the producers of Family Ties. Fox joined the cast, Stoltz had to go, and the movie was better for it.

Changing the lead actor was a dramatic decision and it was made right before the point of no return. Recognizing the failure earlier would have saved them a lot of money and wasted effort.

Above: Eric Stoltz as the original Marty McFly.
Below: Michael J. Fox in the final film.

Other famous but less dramatic "failures" were the first drafts of the script where the time machine was built from a refrigerator instead of the iconic DeLorean, and the original ending in later scripts which involved getting the 1.21 gigawatts of energy to power the time machine by driving it into a nuclear explosion test.

A frame from an early version of the Back to the Future storyboard

The moral of the story is that it's best to fail as early as possible. It opens up a possibility for choosing something better.

The important thing to acknowledge is that you can't plan for success when you're doing experimental or creative work. Failure is always an option. The only time you can plan for success is when you're doing something that's already done and tested before, like assembling Ikea furniture or designing a game by cloning an existing one. When you're creating something new, no-one can tell if it's really going to work or not before you can see it in action.

It's also important to not take the principle too far. Some ideas need time to grow to their full potential, so discarding them would be a mistake. Balancing between being bold enough to discard probably bad ideas and holding on to potentially good ideas is the hard part.

Identifying failure points

Coming back to game design, failing early means identifying potential failure points, testing them, and making correcting moves or even discarding the project if needed.

Pretty much every aspect of game design is a potential failure point. To name just a few:

• Game mechanics
• Plot and story structure
• Characters and character relations
• Setting
• Geography
• User interface

The key is to think what will be this game's innovation. Tried and tested details probably won't be a problem, it's the things that are going for something new that are most likely to require repeated iterations.

Once a potential failure point is identified, the best way to find actual problems is prototyping. Make a small example that shows the thing in action; implement the game's core mechanism, at least partly; start writing from the climax of the story instead of from the beginning; write the key interaction between main characters first. Once you have something concrete, no matter how small, you can more easily get a sense of whether it will work or not.

Historically there have been several parser IF writing communities with partially overlapping members. The "main" community, originating from rec.arts.int-fiction newsgroups before largely migrating to the intfiction.org web forum, makes up for the bulk of the high-profile activity and covers the most diverse collection of authoring tools. Smaller communities are usually focused around individual authoring systems (ADRIFT, Quest).

The approach these communities take to providing feedback to authors varies greatly. The main community used to be on the far end of the scale: "brutally honest" would probably describe it best. The community expects and rewards quality, and things that don't work are meticulously brought out in reviews.

On the other side of the scale there are communities that reward effort. No matter how bad the game is, you get cheers and pats on the back just for releasing it. Feedback, if any, is overwhelmingly positive. The community doesn't necessarily even expect that published games would be open for criticism.

The games produced by these two extremes are also very different. Communities that only reward effort produce a lot of games that are almost without exception, to be brutally honest, utter crap. This is because of two main reasons: Firstly, there is no incentive to spend time designing, polishing and testing your game because you'll still get the same reward in positive responses no matter what the quality of the result is. Secondly there is no peer pressure: when no-one expects high-quality games, there's no outside push to aim there.

The brutally honest camp produces less games but they're generally of better quality. There's a sieve that the authors are pushed through: all work undergoes close scrutiny. Authors who can't handle the criticism will drop out, but those who stay are less likely to repeat their mistakes and more likely learn from the feedback and keep improving. The peer expectation of game quality is generally high and the authors aim higher in the first place.

The downside of unchecked criticism is that, from the point of view of an individual author, the feedback can feel unnecessarily harsh. A novice author can easily give up if the feedback is crushing, which is understandable; when you do things as a hobby, you want to have a positive experience or you go do something else.

The challenge is to combine the better parts of the two extremes. How to not punish anyone for producing creative work but at the same time encourage high quality?

The trend is already moving in this direction: some reviewers (including me) post only reviews that are net positive and events like Spring Thing have non-judged categories. This is only a partial solution. Lack of feedback shields authors from negative feedback but also leaves them without means to improve.

It would be great to have some kind of mentoring system where experienced authors could help out newcomers to design and polish their games. The downside is that it's not mass-reproducible: it would require a lot of effort from the mentors and the ratio of newcomers to experts is too high for everyone to get a mentor.

Here are some tips for competition participants on how to make the best of their entry.

Plan further than the intro

This is perhaps the most common sin of IntroComp entries: the author has not designed the game beyond the entry itself, which makes it hard to continue building the full version.

It would be wise to have the story and gameplay thought out at least twice as far as the actual intro, preferably all the way to the end, at least conceptually. This includes visioning what happens immediately after the intro ends and what is the overall story structure: the intro is the beginning but what happens in the middle and how the full story is resolved in the end. Otherwise there's a good change that the intro ends in a creative dead end with no easy way forward.

It's not hard to tell if an author has planned the story beyond the intro. Intros with short term design are often tightly self-contained and convey no feeling of there being something else beyond what you see. When the world and the general plot is well thought out, it's almost automatically visible in the resulting work. (See also a previous article discussing the subject.)

Start with the relevant story

Sometimes the word "intro" is taken too literally and the entry ends before the actual story even gets to start.

A fictitious example: Your story is a retelling of the 12 labors of Hercules. A good intro would contain the first labor to its completion; it would give a good indication of how the gameplay works and judges could easily imagine what the rest of the story would look like in its full version.

A bad intro would be about Hercules packing his backpack and a puzzle about finding a map for the location of the Nemean lion, and it would end just after reaching the entrance to the lion's cave. It would tell very little about what the game is actually like.

So cut off everything that's inconsequential to the big picture and start right from the action.

Make a proper ending...

Even though we're talking about introductions, it's still important that the entry reaches some kind of conclusion of its own. Sometimes that's easy to do when the story can be neatly divided into independent scenes (like in the 12 labors of Hercules example), but sometimes you'll have to work harder to find a good place to end the intro.

As a rough generalization you'd have one or two short term goals that are resolved during the intro while the overall goal is both left unresolved and made clear to the player.

...but leave some loose ends untied

This comes back to the "plan ahead" advice. Even though it's good to resolve a short term goal or two, there should be some kind of hook that makes the player want to continue playing the finished work.

A cliffhanger is a traditional way to end the intro, but it shouldn't be the only hook. As said before, the intro's purpose is to build expectations for the full version. It shouldn't be self-contained: leave room for future expansion. A couple of locked doors, interesting inventory items with reuse potential, references to NPCs not yet encountered. Anything that makes the player's imagination run wild.

Remember though that it's important that you as the author know where the loose ends are going – you can't just drop a locked door somewhere without knowing where it leads. Anything that serves a purpose usually comes across as such in the writing, whereas pointless scenery is often easy to spot.

Have the entry betatested

While technical issues are not explicitly in the judging criteria, bugs and spelling mistakes will reflect poorly on the entry. After all nobody wants to play a buggy game and the intro is taken as an indication of the finished entry's quality.

You don't need a whole army of testers, one or two should be sufficient for a short intro (although more is always better.) It's easier to find testers for IntroComp entries than for many other games because potential testers know that the game should be short and therefore doesn't require a huge time commitment. Testers can be recruited from the beta testing site or from the intfiction.org forum, among other places.

Remember that choice-based entries need testing too for things such as spelling, tone, and pacing.

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