Appendix B

We now put aside the technical aspects of writing TADS programs, and turn to some musings on the creative side of writing adventures. TADS makes it possible to write games that are technically polished with little programming; it is up to the author, however, to provide the creativity and storytelling skill needed to make the game fun to play. This section describes some of the stylistic points of writing text adventures.

The problem most adventure authors encounter immediately is the technical difficulty of writing a parser and all the other nasty bits of code that underlie an adventure. Most authors don't get very far into writing that code; those that do more often than not get lost in the never-ending quest for new features in their parsers, and never get around to writing a fun game, and those that don't end up with simple parsers, which most players find an inconvenience that hurts playability, and imposes severe limits on the range of actions the game can carry out.

TADS frees authors of the need to become adept programmers before they can write a good adventure game. By providing a ready-made parser, a huge chunk of the technical side of writing a game is done before the game is even started. TADS not only gives you a fine parser, but it also provides facilities for saving and restoring games, creating transcripts (a log of all the text in a game), dealing with the operating system, managing memory, initializing data structures, and virtually everything else that's generic to all adventure games. TADS will satisfy both authors who are not interested in the technical details of the parser and other low-level software, and players and authors who want a sophisticated parser.

But even with all of this, writing a good text adventure is not easy; surmounting the technical difficulties is only half the battle. Now it's necessary to design a good plot, challenging puzzles, interesting characters, and a satisfying conclusion. In this section I will offer some ideas about what makes a good game.

Adventure games all have a major problem: they pretend to be what they're not. The degree to which you address this problem in your games is, in large part, the measure of how good your games are.

Adventures are simulations. Unfortunately, most adventures claim to be simulations of the real world; usually, this claim is implicit in the fact that many objects in the game act, superficially, at least, like their physical counterparts. The reason this is unfortunate is that no adventure game written so far has adequately simulated the real world. Although game objects resemble physical objects in some ways, the game objects are extremely limited in most other ways.

Adventures also pretend to be more intelligent than they are. Text adventures give the player a prompt which says, effectively, "Type anything you want, and I'll do as you ask." This is totally unrealistic. The prompt should really say, "Type one of the few commands I understand, using exactly the correct syntax that I expect, and I may just possibly be able to apply the command as a special case I've been programmed to accept." The TADS parser is about as smart as adventure game parsers come, but it will quickly disappoint anyone other than experienced text adventure players (who already know how limited these games tend to be).

Unfortunately, with the present level of computer hardware and software, it is simply not feasible to write a perfect and complete simulation of the real world, nor to design a parser that can understand every valid sentence (or, for that matter, even any reasonable subset of valid sentences) in a human language. These limitations are not immediately escapable. However, authors can work within these limitations to improve on the traditional text adventure.

The key is to choose a small universe that you can model completely. Don't try to simulate the real world; it's too complex. Instead, design a small imaginary world, which has relatively few possible operations on objects, and few relationships between objects. Make these operations and relationships clear to the player (in documentation, for example). If you choose a small enough set, you may be able to make your simulation robust and complete; the operations and relationships should be general enough that they are applicable to most if not all objects in the game.

You may think that this would make a game uninteresting, but this need not be the case. In fact, it makes adventures much harder to design, but, when done correctly, much more intuitive and satisfying to the player.

One trick that can help you do this is to avoid the use of verbs outside of a very small set. A certain number of verbs will work on pretty much any object in any adventure game; for example: take, drop, open, close, examine, put an object in (or on) another object, give an object to a character. All games have these verbs. Now, imagine writing a game with only these verbs, plus one more special verb: "use." This last verb invokes the "characteristic behavior" of an object. For example, "use button" means to push the button; "use knob" means to turn the knob; "use sandwich" means to eat the sandwich.

It may appear that limiting your verbs in this manner makes puzzles too obvious, since the player doesn't have to think of the actual thing to do with an object, but can just "use" it and have the game figure out what to do. In fact, it encourages you, the designer, to choose objects that have exactly one very obvious use; doing so means that the "use" verb detracts nothing from the puzzle, since it's obvious to everyone that you push a button and turn a knob, and that you'd do nothing else with them. Hence, this forces you to avoid obscure verbs that apply to just one object as you choose your puzzles. In particular, it prevents you from using obscure relationships between objects that occur only one place in your game; if you can't support the relationship in general, don't support it at all.

This method of puzzle design has another advantage: it usually results in your puzzles being more logical and subtle. The reason is that you must construct interesting situations totally within the context of the very simple verbs in your system and the obvious uses of objects.

Of course, you should use the verb "use" for all of these activities only in the design phase, to force you to avoid vocabulary puzzles and puzzles based on unusual relationships that don't apply to objects in general in your game. When you actually write the game, you should go ahead and use the verbs that describe the characteristic behaviors of your objects. Thus, when the player actually plays the game, he'll type "push button" and "turn knob."

Every adventure has a plot. In the Original Adventure and many games like it, the plot consisted of nothing more than exploring and gathering treasure. Most recent games, on the other hand, are more like novels whose evolution the player chooses. Most people prefer games with more plot. However, players also like freedom of choice; so, your plot should not impose a particular path through the game, but should instead serve as a backdrop, a context for the events within the game. You must try to balance the story you are telling with a player's desire to choose his own path through the story.

The basis for your plot is as unlimited as your imagination. Adventures have been written in such diverse genres as science fiction, fantasy, mystery, international intrigue, horror, and romance. Adventures cover as wide a spectrum as literature.

The main plot elements of adventures are exploration and problem-solving. While providing an interesting area to explore can stimulate the imagination, most players prefer being able to interact with their environment to simply wandering around it. This is where problem-solving comes in.

In designing puzzles, you should be careful to motivate the solutions; never withhold clues that are needed to solve a puzzle. Disguise the clues, certainly, but be sure the clues are present.

My basic principle of designing puzzles is that the player should always know what he's trying to accomplish. Metaphorically, a player should always be able to find a locked door before he finds the key. This way, he knows his goals. The most frustrating feeling while playing an adventure is that you don't know what you're supposed to do next. If you find a locked door, you know that you have to find some way to open it; you know what to do, so the trick is to figure out how to do it. Hence, I like to design games so that a set of short-term goals is clearly visible from the outset, so the player knows where work is to begin.

A well-designed adventure is a self-consistent world, not necessarily the real world, in which a player can conduct experiments to learn how objects and characters behave; he solves puzzles by learning the behavior of an object or character, and turning that to his advantage. This is probably why science fiction and fantasy adventures are so popular; these genres offer limitless possibilities for creating objects that behave in novel ways.

Since the core of problem solving should be experimentation and observation, objects that behave in special ways shouldn't be labelled as such. Instead, they should have physical characteristics which invite experimentation, and should respond to experiments with useful feedback. It is especially bad to provide an object that behaves in a novel way, but force the player simply to think to try the one special thing that it does; something should invite him to find its special characteristics, and its behavior should be consistent.

For example, you might design a machine, described as "a small metal box with a button, a short plastic hose on one side, and a large metal pipe on the other side." When the button is pushed, "a loud hissing comes from the plastic hose for a moment, then a large drop of clear liquid drops out of the pipe, which hits the floor and quickly evaporates into a white cloud of vapor." If the player puts the plastic hose in a glass of water and the button is pushed, "the water is sucked into the plastic tube, and few moments later a block of ice is dropped out of the pipe." This allows the player to learn by experimentation what the machine does, which is more fun for the player than if you had labelled the machine "a freezer" or some such.

Another type of puzzle that makes for good games is the kind that uses ordinary objects in an unusual but logical manner. For example, you could use a ladder to cross a chasm, or an incandescent bulb for its heat rather than its light. It's important that the use be logical; you don't want the player to have to guess a completely unmotivated use of an object. You want the player to think, "I need a heat source, but all I've got is this light bulb," and then realize that the light bulb is a heat source. It's also important that the properties of an object be consistent; if the player tries to take the light bulb while it's lit, he should get burned.

Another common type of puzzle involves hidden objects. When objects are hidden, the player should be able to find them without resorting to looking behind and under everything in every room. For example, if you hide a crystal statuette under a seat cushion, someone sitting on the seat may hear a sound like breaking glass coming from under the cushion; looking under the cushion reveals a smashed statuette. (Providing a clue that doesn't require starting the game over would be nice, too, though.)

A feature that is difficult for a designer to implement, but makes the game more realistic, is an object that is used for several purposes. In many adventures, the player figures out what each object is for, and, once used, feels free to discard it. You can set up subtle logical puzzles simply by using an object for more than one of its properties, since players might assume that the obvious useful property of the object is the only one and not bother looking for other uses of the object.

Most players prefer games in which they can work on several puzzles at once, since each player will be able to solve different puzzles more easily. This is why I generally structure my games overall with an introduction, then the body of the game, and finally an end-game. The introduction and end-game tend to be fairly linear; that is, each event leads to the next event in a fixed order. In the linear portions of the game, then, the player can only work on one puzzle at a time, and must solve it before he moves on to the next. The body of the game, though, consists of many parallel puzzles; though these might have some interdependencies, I generally try to make it possible to solve them in any order. I try to keep the linear portions of the game as short as possible, leaving the course of events in most of the game up to the player.

Designing games is a subtle and complex art. Just as most good authors are well-read, you will probably become a better adventure game author if you play a few good adventure games. And nothing is a substitute for experience; your games will improve with each new one you write. TADS gives you an excellent tool for creating games; the rest is up to you.