10 HINTS TO GREAT GAME DESIGN - part 1

                   by C.E. Forman (1995)

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 non-linear 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.

@~To be concluded next issue













                              - o -