% $Header: c:/tads/doc/RCS/tadsstyl.tex 1.2 92/11/13 16:44:41 mroberts Exp $
% TADS Documentation, Appendix B:  Musings on Style
%
% Copyright (c) 1989 by Michael J. Roberts

\chapterheader{Appendix B}{Better Adventures}{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.\bull

\chapterbody

\majorsection{Style in Adventure Writing}

^^{game design}
^^{designing a game}
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.

\minorsection{Problems with Adventures}

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

\minorsection{Writing a Game}

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 {\it 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 {\it 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.

\endchapter

In this final chapter, we approach style in its broader meaning:
style in the sense of what is dinstinguished and distinguishing.
Here we leave solid ground.  Who can confidently say what ignites
a certain combination of words, causing them to explode in the mind?
\author E. B. White, {\sl The Elements of Style\/} (Third Edition, 1979)

\eject
