Welcome To Tutorial Info

You've solved every Infocom game ever released. You've FTP'd countless text adventure games from Internet sites in a desperate attempt to quench your insatiable thirst for interactive fiction, but still it's not enough. So you decide to take the final step, to write your own parser adventure. But--how do you know for sure that people will like it? How can you avoid making the same mistakes you've seen in many of the quests you've been playing for years? What exactly constitutes a "good" text adventure game?

That's what I'm here to help you with. I've taken it upon myself to analyze my favorite works of interactive fiction, determine why they're my faves, and compile a list of their common characteristics that first-time adventure writers can use for reference.

Keep in mind that this is not an article on programming a game. These ten tips deal exclusively with game design and the authoring of the game's storyline. My intent here is to point out the most common mistakes beginners make, and identify methods of avoiding falling into these traps.

You may be asking yourself, "Who is this guy anyway? I've never heard of him in my entire life!" True, true. I have been a fan of interactive fiction since I was seven years old, and I have even written a couple of my own adventures. That you've never seen my name anywhere should tell you that my games have fallen prey to most if not all of the problems I'm pointing out in this article. (Of course, I was confined to using BASIC as my sole programming language. Plus I was only twelve at the time.) Right now, I'm working on a couple of new games, and perhaps this time they'll turn out to be quite a bit better. Hopefully you'll be able to learn from my mistakes, too.

1. Develop a good parser.

This is the single most important element of any work of interactive fiction. Unfortunately, it's also the one most frequently neglected by beginners. Even the most cleverly designed adventure isn't going to hold players' interest for very long if they have trouble communicating what they want to do. The earliest adventure games, such as the original "Adventure in Colossal Cave" and the Scott Adams series, used crude, verb-and-noun parsers that accepted only two words in each command. Due to the limitations of computers in those days, a standard parser's vocabulary was often very limited, leaving gamers dissatisfied.

The Zork Implementation Parser introduced by Infocom in the late 1970s is really the accepted standard for parsers today. If you're using an IF design tool such as Inform or TADS, developing a good parser isn't as much of a problem. If, on the other hand, you've decided to write your own parser, pick yourself up a good thesaurus and use several common synonyms for each noun and verb. Make your puzzles the challenge of your adventure; don't force players to "guess the verb."

In addition, the more options you can supply your parser with, the better. An "undo" command, built-in hints, the ability to allow players to configure the function keys as typing shortcuts, and automatic mapping will all contribute to the reduction of frustration on the part of the player.

2. Use good puzzle structuring.

Don't just force players to wander aimlessly from one puzzle to the next, halting their progress completely until they solve the only available puzzle. Branch out your puzzle structure and make it as nonlinear as possible. Interweave your puzzles with one another and allow players multiple paths through the adventure. That is, don't make players solve the puzzles in the same order every time; give them some flexibility. The only point in the game where there should be only one path for the player to follow is at the conclusion, where all the branches of puzzles come together to form a final challenge.

Puzzle connectivity is also important. Make sure each puzzle "fits in" with all the others. If you have an extremely challenging puzzle, but you can't make it fit logically into your adventure, don't just throw it in for the sake of using it. Save it and use it in another game, where it is appropriate. One of the biggest abuses of this that I've seen comes in the form of mazes. Often adventure writers will simply throw in a maze to make the game more difficult, when in reality it is totally inappropriate and has nothing to do with the game at all. Making maps of games is tedious, and mazes are generally frowned upon in adventure games today, unless they have a truly unique twist (such as the catacombs in "Leather Goddesses of Phobos"), or can be solved without mapping (such as the wet tunnels in "The Lurking Horror"). In summary, designers should ask themselves this: "Is this puzzle connected to the game in some way, or is it in the game merely for the sake of its own existence?" If it's the latter, you should probably consider scrapping it.

3. Balance the difficulty of your puzzles.

What's the fun of getting all the way to the end of an adventure only to discover that the final challenge is the easiest puzzle in the history of the universe? In most cases, the best adventure games are the ones that curve the difficulty of their puzzles. Keep 'em fairly simple at first, to allow the player to get into the game, then gradually raise the challenge as players go deeper into it. Don't get me wrong. It's perfectly okay to throw in a difficult or obscure puzzle or two in the early stages of the game, but the key is not to overwhelm the player at the outset.

Of course, the primary deciding factor as to the difficulty of the puzzles should be how difficult you've chosen to make the game as a whole. If you're writing for expert players, design your puzzles accordingly. If beginners are your target audience, include a lot of simple, one- or two- step puzzles. In all cases, after a particularly arduous puzzle, reward the player with a few simpler ones. You'd be surprised at how many players lose interest when a game's puzzles aren't balanced.

4. Make your world and puzzles logical

This one is basically just common sense, but it's still sometimes overlooked. If you're writing a sci-fi adventure, pay attention to the laws of physics. Don't let players enter the vacuum of space and survive without spacesuits. Realism is less of a problem in fantasy games, as much can be justified by the use of magic. The point, though, is to make sure everything makes sense in some way. This is especially important in the area of puzzles. Avoid making players do things that have no logic or purpose behind them. The more realistic your adventure, the more it will draw players in.

5. Be descriptive.

You've created a whole other world, so why not let the player enjoy the beauty of it? How many times have you played a game with such lame location descriptions as "You are in a forest," "You are at the bottom of a tall cliff," "You are outside a cave," etc.? The term "interactive fiction" is not an arbitrary one--players are essentially exploring a form of writing, much like a good novel, and adding their own input to it. So let the player see the world you've created, much like your favorite fiction authors let you see theirs.

Take care, though, not to overwhelm your players with prose. If you give them little opportunity to interact, they just might decide that they may as well be reading a book. Don't get too bogged down in descriptions. Usually half the screen is the absolute maximum for a room or object description, and this limit should only be reached on rare occasions. However, if a particular puzzle requires a lot of text in order for the player to see it, one or two full screens are acceptable. (A good example of this case is the mirror box in "Zork III".) Don't make players read the text over and over unless they want to, though. Make sure your parser has the option of changing the length of room descriptions. Using phrases such as "You are in the forest" the second time a player goes there is perfectly acceptable. (Just make sure that players can still get a better description if they want it.)

While we're at it, I'd like to mention one variation on this subject. Most players, when writing good room descriptions, like to include several objects or features in each location (for example, a tavern might have a fireplace, a bar, and several tables and stools). Nothing is more aggravating than typing "EXAMINE THE STOOLS" only to be told, "I don't know the word 'stools.'" This is guaranteed to instantaneously shatter the fantasy and destroy any hope of players ever really getting into the game. Do this enough, and you'll alienate them forever. If you're going to put an object in the location's description, you'd better let the player interact with it, even if it's only in a limited way. Just a message saying, "There's nothing special about the stools." will suffice.

Incidentally, I feel that this is one of the biggest problems with the Zork-based MUDs I've played. Players see that term, "Zork-based," and they telnet in expecting the same level of realism that Infocom gave us, and unfortunately, they rarely, if ever, get it. I myself have on occasion experienced difficulty in simply trying to interact with what the game claims is in the scene with me, and I'm afraid this is the rule rather than the exception.

6. Be fair to the player.

I know, I know. Life isn't fair. Never has been, never will be. But adventure games aren't real life; they're a form of entertainment. And the only way players will be entertained is if they're treated fairly. Here are some general guidelines you should follow to ensure that this is the case:

* Don't let the game get into an unsolvable state too much, without giving the player some indication of it. There's no definite line here, so you'll have to use your own judgment. As an example, consider the KULCAD scroll in Infocom's "Enchanter". (Warning! Spoiler to follow...) You are supposed to use this spell to dispel the illusion of the infinite winding staircase, as this is the only way to overcome this particular obstacle. However, you can also use KULCAD to get rid of the guarded doorway and the Gordian Knot around the jeweled box. If you do one of these, though, the scroll is gone and you can't win the game. Despite the frustration that could be caused by this, I still don't consider it unfair, because if you use the spell on anything other than the stairs, your master Belboz will appear before you and warn you that the evil Krill has been alerted to your presence. You receive a definite hint that maybe there was a better way. On the other hand, I've heard numerous complaints about the game "Curses" because you can inadvertently do something out of sequence and blow any chance of being able to win, and no indication whatsoever is given. So save yourself and your players a lot of trouble, and give some kind of message if they unintentionally do something to get themselves stuck. (On the other hand, throwing all your possessions off a cliff is not a very smart move to begin with, and players should be able to figure this out without a hint. Only tell them they've screwed up big-time if there's a chance they can't determine that for themselves.) Incidentally, a good way to allow players to keep going after they've lost an item is to allow them to re-obtain the item in the place they originally got it. For instance, allow them to pick another apple off the tree if they eat or lose the one they originally got. However, when you're dealing with a unique item, such as the KULCAD scroll, this isn't a feasible option. Again, you'll have to use your own judgment here.
* Don't force the player to have too much foresight. Inventory management is a crucial part of an adventure game in which the number of things a player can carry is limited. Often players will wander into a new location and only be able to take so much along with him. Obviously, if they're going into a dungeon they'll need a light source, a weapon, and probably some food and water, but if they're going to need something less obvious, you'd be wise to provide a hint beforehand. Of course, players can always restore, but going through a lot of moves to get back to where they was before can be frustrating, and too many save files can become difficult to keep track of. It's best to give players a general idea of which items they won't need and thus can leave behind. Don't make them pick and choose too much. A few very good games I've seen are designed so that the player's inventory is pretty much managed as the game progresses. That is, the player uses two items to solve a puzzle, thus removing them from his inventory. Then she finds another object and adds it, and later gets rid of it in another puzzle, and so on. If you have items that don't have multiple uses, this is a good technique to use.
* Don't overwhelm players at the start. If you have a large area they can explore in the beginning, you'd be wise to point them in the right direction to start with. Legend Entertainment's "TimeQuest" is a perfect example of this. With 80 different time-places to visit, any of which can be reached from the beginning, it's vast enough to make the player feel burdened. But this game directs you to Rome in 44 B.C. from the start, which gives them a sense of direction and helps you establish a path through the game. In addition, the most crucial time-places are all listed in the game's documentation, so the player knows where the important places are. This makes it easier to get started.
* Don't put off the entire reward until the end. Congratulate players when they solve a difficult puzzle, possibly by giving them a special item or power. According to Joseph Campbell's monomyth, the challenges a hero faces become more and more difficult as his quest continues, but the rewards become greater. This should apply to adventure games as well.
* Don't create puzzles that absolutely have to be solved within a specific time frame, unless you give the player a reasonable hint.
* Include good error messages in your program to tell players if they're doing something wrong, but don't insult players in the process. Be clever, but not verbally abusive.
* Random events are good for spicing up adventure games, but never, EVER base the decision of whether a player lives or dies upon the outcome of a random-number generator. I mention this because I did it once. The player had to cross a pit by placing a wooden plank over it and then walking across. But you fell in 1f the time anyway. Talk about frustrating! The only instance where this is at all acceptable is when there is an alternative solution that is not random. For example, in Sorcerer, players have a 10% chance of successfully jumping a gorge, but if they use a flying spell, they'll get across every time.

You might be saying, "Well, this is my game, so I'll do whatever the hell I want, and I don't care whether the player thinks it's fair or not!" Keep sending this attitude, and pretty soon you won't have any players who care about finishing your adventure. Book authors who don't show respect for their readers don't stay book authors for very long. The same holds true for interactive fiction writers. Players are your lifeblood; they keep your game alive. If you want to write games solely for your own pleasure, that's fine, but you won't gain any recognition from doing it. Treat your players as you would treat a paying customer, because after all, that's essentially what they are.

7. Don't be afraid to kill a player off.

At the same time, don't hold the player's hand all the way through the game. Let them experience a game death if their actions aren't clever enough. Dying is a natural part of adventure games. Can you picture what the Zork Trilogy would be like without the constant threat of being eaten by a grue in a dark place? And just try to imagine "The Lurking Horror" without death! Which would you rather see after doing something intentionally stupid in an adventure--a detailed, possibly amusing, account of your alter-ego's untimely demise? Or a lame message saying, "That would kill you, so I'm not even going to let you try it"? Believe it or not, it's FUN to try to find new and inventive ways to kill off your character (especially after you've already finished the game). Pampering players with feelings of invincibility is only going to make them severely disappointed. And besides, this is one of the few ways you can get away with murder nowadays. If you've put an UNDO command into your game, don't be afraid to let players use it.

8. Concentrate equally on creating challenges and building the story.

Puzzles are fun, but the story itself should be the main point of an adventure game. Rather than having the player wander aimlessly around solving puzzles, develop the story as the player moves along. An unexpected plot twist or the introduction of a new NPC can really liven things up, especially when it occurs in the midst of a good puzzle. Puzzles alone can only carry a game so far.

Another thing to keep in mind is that a game should have a good introduction and ending. Actually, an introduction is optional. Some writers may prefer to simply have the game begin as soon as it loads, much like "Zork I", while others may choose to follow the route of "Beyond Zork" and have introductory text spanning several screens. A few games, such as "Zork Zero" and "Demon's Tomb", even have short prologues--opening sequences which play much like the game itself, but which exist for only a limited number of terms. Any of these methods will suffice.

A good ending, though, is indispensable. Is it worth struggling through a game just to be rewarded with the words, "Congratulations, you win"? A good game ending should tie up any and all loose ends the story may still have, pave the way for the sequel if you're writing a series of games, and leave players feeling as though they have truly accomplished something. Good endings will be read again and again by players, but I can guarantee that a lame ending will only be seen once.

9. Include good information sources in your game.

Most of the time, when writing the game's introduction, you'll want to tell the players only so much about your world. Let them learn the various intricacies and details of it themselves. If your world is vast and complex, build several sources of information into your game to help the player accomplish this. You could implement an encyclopedia (Infocom uses these in several games), newspapers, a computer database, or some other form of information storage (the tape spools in Stationfall come to mind). In addition, you might want to make one or more characters act as primary information sources. The player could then ask those characters about various people, places, or things in the game. The more you tell the player about your world, the more complex and realistic it will appear.

10. Keep the game's longevity intact.

A lot of good adventure games become dust collectors after players have solved them. Often this can be prevented, or at least delayed, by a little extra effort on the part of the author. Give some of your puzzles multiple solutions. Think up imaginative ways of dying and humorous tricks for the player to try. Some adventures even have multiple endings depending on various things the player has done (or not done) during the course of the game. All of these things can keep players interested for quite some time after they've been through the entire game. The "Zork" and "Enchanter" series are particularly good examples of this tip. I'm still finding things buried in them that I never knew existed. A little extra programming can go a long way.

If you see yourself making any of these mistakes, you might consider rethinking at least part of your original design. Designing a good text adventure is a long, complicated, involving, and extremely frustrating task, but in the end it can be very rewarding. Good interactive fiction is always in demand, and I sincerely hope I have enlightened you and guided you toward successfully creating your own.