TUTORIAL

Designing an adventure game

Tips from the author of Gateway.

by Michael A. Banks

Michael A. Banks is the author/designer of Gateway, a text and graphics adventure for the ST, published by Pryority Software and Action Software.

Banks also writes science fiction novels (among which is The Odysseus Solution, from Baen Books), and non-fiction books (The Official Guide to Delphi, Brady Books, and Second Stage: Advanced Model Rocketry, Kalmbach Books).

He currently has three novels, one juvenile book, and eight nonfiction books in print. A full-time writer for four years and a computer user for six, Banks resides in Ohio, with his wife, daughter, son, and no cats.

As a game programmer, you've probably considered developing a text or graphic adventure. Adventure games are the most sophisticated type of computer entertainment and, not incidentally, the game category with the longest sales life. While arcade games come and go quickly (one Broderbund executive pegged the average sales life of an arcade game at nine months), adventures sell and sell and sell, year after year. Adventures such as Zork, Mystery House and Adventureland have been around for over five years—not even Pac-Man lasted that long!

If you have any doubts about the commercial viability of adventures, consider the many software publishers, small and large, that have based lucrative businesses solely on adventure games—among them Sierra On-Line and Infocom. Further, look around at the software publishers who, three years ago, were publishing no adventure games, but who now are jumping on the adventure bandwagon.

Maybe you're aware of all this, and feel capable of creating an adventure system, but have some doubts about your creative ability. The market is, after all, a very demanding one. Adventurers today are too sophisticated to accept freewheeling worlds offering only vague treasures, magic and dragons, and software publishers are aware of this. Gamers want interesting worlds and intriguing puzzles, to be sure, but contemporary adventures must have story value—which means plot, character development and interaction, and more.

As Dallas Snell, author of Penguin Software's The Quest and Ringquest, puts it, "The story, characters, and other ‘soft’ elements of an adventure are more important than the programming. But this doesn't mean that you can get away with sloppy programming. That is what killed a number of early good stories."

Thus, the reason for this article—I would like to share my viewpoints on adventure game design and construction, as a fiction writer and software designer. I hope to provide information you can use to give your adventures an edge in the marketplace.

Programming.

As a programmer, you should already be aware of the requirements of creating a parsing and database system for adventures, so I won't go into the subject of programming techniques here. However, we can take a general look at how an adventure system is structured.

An adventure program is nothing more than a specialized system for handling words, and changing text displays and the values of variables in response to player input and the passing of time. The system is complex, however. A special kind of database, which contains text descriptions and responses, instructions on how to handle the commands and variables it is given, and how to track moves, time and scoring, is the "heart" of an adventure. The adventure program obeys the instructions in the database regarding changing variables and text descriptions. The program's parser, which is the "front end" of the system and the most visible part of the program, takes player input and processes it into information that the program and database can use. (The parser is the most visible part of the program to the player, and it should understand all parts of speech—including objects, indirect objects, prepositions and modifiers.)

Languages and Computer Systems.

Although a number of software publishers use their own proprietary systems (such as Infocom's ZIL—Zork Implementation Language—and Adventure Interna tional's AIL—Adventure Implementation Language), machine language has been the most popular language for adventure developers, due mainly to its speed. Recently, however, quite a bit of adventure development has been done with Pascal and C.

Which machine(s) you will implement an adventure on is something that you'll have to decide for yourself, unless you've developed a machine-independent code such as ZIL or AIL. The machine(s) and language(s) that you work with will be determined in large part by your own skills, but it is worth noting that the Apple II family of computers seem to offer the biggest markets for the adventures, followed closely by the Atari ST, IBM PC, Macintosh and Commodore. A well-designed and -written adventure for any system will find a market, however.

Designing an adventure.

In developing an adventure, you will go through the same creative processes as a scriptwriter or novelist—you are, after all, creating a work of fiction. When I wrote my text adventure, Gateway, for Pryority Software, I found that the entire process, from beginning to end, was remarkably similar to that of writing a novel.

As you put an adventure together, you will find that the process is evolutionary—that is, your adventure will grow of its own accord and, in some instances, even write parts of itself as you develop it.

The Story.

The first step in creating your adventure is to decide upon the type of adventure you are going to write—fantasy, mystery, science fiction, adventure, romance, or whatever. This is important—no matter what the source of your original idea, you should establish some ground rules for the adventure. You cannot allow events to take place in a random and inconsistent manner, as was the case with early adventures; logic and consistency are the major requirements for believability, no matter how strange the settings and situations in your story.

Think of yourself as creating a universe, one in which you make the rules. You can make your setting as weird—or as normal—as you wish. You can have magic, or dragons, or anti-gravity devices, whatever it takes to tell your story. No matter what your story elements are, make sure that they are consistent—don't break your own rules. The genre that you choose will, in part, dictate what can or cannot exist in your story universe (magic has no place in a high-tech science fiction story, for instance), but only to the extent of providing general guidelines. You make the rules, and you must abide by them.

This established, your next move will be to create the storyline, which is basically a chronicling of the major events in the story, in much the same way a writer plans a novel. (It may help you to visualize a storyline as a running account of the story; like telling a friend about a movie you saw or a book that you read.) Or you may wish to create a storyboard, showing scene-by-scene what can happen in your story, as well as what the major goal will be. Once you have the storyline firmly in mind, you can plan actions and their consequences for each scene. (Try to maintain control by allowing the player to take only those actions which might logically be tried, in a real situation. You can waste a lot of memory trying to anticipate every humorous or outré command that a player might input.)

Don't make things too easy for your main character (the player). In well-plotted films, novels and short stories, the story is often made by the limits that are placed on characters. Thus, avoid giving the player overly-simple "outs" for problems, such as magic words. Seasoned adventurers recognize this ploy as a plot device, for the convenience of the author.

Rooms.

Planning your story will allow you to plan your locations, or rooms, intelligently. The genre and the story itself will suggest most of the locations. If you are writing a science fiction adventure, you will probably have an alien world or two, and a spacecraft. For a romance, your setting might be a small town.

Write the descriptions for the opening scene and the final scene first. After this, determine just what locations are required by story events. A romance story, for example, might begin at the home of the heroine, and end at a wedding chapel. In between, you could have such events as the initial meeting between the hero and heroine, a date or two, and an emotional encounter at a train station. These events imply a meeting place location (perhaps a department store), date locations (a theater and a restaurant), and the train station. Other activities imply other locations.

Mapping.

Needless to say, you should map your adventure. As your adventure grows, new locations will suggest themselves (a spaceship control room may imply an engine room, for instance), and you'll be hard-pressed to keep track of all locations without a map, even though you are the creator!

Objects.

Objects are very important—they allow the player to actually do things in your adventure world, to take control of his circumstances. But you should have your locations established before creating many objects—after all, you have to have someplace to put the objects! The objects required will be determined in part by the genre and setting. If you are writing a fantasy quest adventure, it is almost axiomatic that there will be certain valuable treasures such as jewels or rings to find. A jungle adventure will most likely require that your hero have a rifle and perhaps a bush knife.

Major story events will also have a bearing on the objects required. The romance story described earlier could, for example, require an engagement ring and wedding dress.

Depending upon how detailed and realistic you want to make your adventure, you could include all manner of objects. For instance, a department store location could be filled with items—most of them useless to the plot—that the player can pick up or buy. The armory of a medieval castle might offer swords, knives and more exotic weaponry. The number and kinds of objects present depend upon the level of detail you wish to include.

You might also include some objects in descriptions, for the sake of realism, that are not "getable."

Then there are the "red herrings"—objects that seem valuable, but offer no real aid to the adventurer. For example, you might include an empty chest, which the adventurer will assume will be required to haul some object, but which, in reality, will be used for nothing. This type of element makes for a feeling of uncertainty in your adventure, just as in real life!

Problems and Plotting.

By the time you work out the storyline, locations and objects, you will be ready to start setting up obstacles—the complications that make up the plot. These are the logic problems and puzzles that adventures are famous for. Some problems will be direct, simple obstacles, like the need to find a key to open a door. Others will be tricky challenges, involving not only the player's knowledge of your adventure "universe," but also his knowledge of general or special topics.

Complicate problems whenever possible—adventurers love complex problems. If the player must get a key to open a door, put some obstacles between the player and the key—perhaps the player will have to defeat a ghost to get at the key, and this will require that he get some water from a well to throw on the ghost, but first he must find a bucket...or add a double-whammy by putting in two keys—one that is easy to find (the wrong one), and one that is dangerous to acquire. And don't pass up the opportunity to spice up problems by making the wrong solution a fatal one.

You may be surprised to find just how much these story elements will interact. Your storyline, and the objects, locations and problems in the story will begin to affect one another very early on, and changes in one element will almost always "feed back" to other elements. As a result, new locations, objects, problems and solutions will suggest themselves. Like most works of art, an adventure is flexible and self-perpetuating.

Descriptions.

While you are going through the processes just described, you should be making notes about what is in each room, as well as the room's general appearance. You will also want to develop one-line descriptions for getable and non-getable objects that you will allow the player to examine.

Room descriptions should give the player an immediate feel for the location—that is, let the player know right away if he is outside or inside, and the general type of location (kitchen, meadow, etc.) he is in. Next, list any "static" (non-getable) objects present, along with any important details such as exits, unusual features (great for giving clues), and the like. The final items in a room description should be anything that has changed since the player last visited the room, and responses to actions that result from the player's actions.

An object name should give the player a good mental image of the object (usually, just a single noun, such as Flashlight or Rifle, is enough). Use detail in "look" or "examine" descriptions to provide clues: The end of the rod has a socket in it, or to explain unusual detail: This is an antique jewelry case, with a secret compartment in the bottom.

Text descriptions of any type should be as brief as possible (remember that you are limited by disk space, and the player is not planning on reading an entire novel), but should use effective prose. When writing descriptions, strive to use the most specific, image-producing nouns and verbs possible. For instance, use German Shepherd instead of just Dog, and Sauntered or Strolled, rather than Walked slowly. Avoid verbosity by cutting out adverbs, long clauses in sentences, and the like. Always write in the active voice, which means that your sentences should be direct in structure—Subject/Verb/Object.

Characters.

Adventures are more interesting (and far more realistic!) when active characters are present. These are known as nonplayer characters, or NPCs. There are four types of NPCs in adventures—for convenience, we'll call them the Companion, the Room Inhabitant, the Random Event, and the Occasionally Present. The Companion is a character who is always with you (unless you are able to do something to drive him away, or kill him). The Companion may respond to your actions or words, but usually with a fixed set of responses. Normally, a Companion is used to give you a source of information, and perhaps to perform one action in a particular location.

The Room Inhabitant is a character whose existence is limited to one room. Characters of this type are usually guardians of a treasure who must be banished or killed. An example might be a suit of armor that attacks the player whenever he enters a certain room.

The Random Event character is one who shows up at random to do something to the player or steal an object—or, perhaps, to do nothing but enhance the story's realism. (Usually, these characters are not as random as they seem, since they show up only when the player is carrying certain objects or in certain rooms.) A troll who pops out of nowhere and steals a sack of gold is a Random Event character, as is a ghost who is sometimes present to block the player's way when he tries to enter a particular room.

An Occasionally Present character is one who may show up in a particular room at any time. This type of character is usually harmless, and may be a source of help or clues.

Character Interaction.

Allowing the player to interact with NPCs is an excellent way to add interest and heighten realism. Interaction may be as simple as a character responding favorably when the player bows to him, or as complex as the character asking questions. It is also possible to establish variable states in which a character will refuse to help the player if the player was not courteous to that character early in the game. The player may also be able to trade objects for information, other useful objects, or safe passage.

When other characters are not obviously evil, the player will probably want to talk with them. Depending on your system, you may have the command TALK (Name of Character) elicit a response, or you might give the player the ability to ASK a specific question.

Extras.

Mazes.

A maze is a set of rooms which lead nowhere, or from which one can only escape through a certain combination of directions.

To create an inescapable maze, connect the maze room to itself in all directions. (The net result will be that the same room description comes up no matter which way the player moves.)

Making an escapable maze is as simple as creating a variable which, when present, will alter the player's location. The variable, of course, is brought in only by the player having fulfilled the requirements you've stipulated. This is far easier—and less memory intensive—than actually creating a series of rooms with the same description.

Suspense.

If you wish to add polish to your adventure, don't leave out time limits. You can establish suspense by placing a time limit on how long a player has to solve a puzzle or reach a goal. Time limits should be touched off by a player action—the player might pick up a bomb for disposal, and have only so much time or so many moves before it explodes. The actual limit can be keyed to number of moves, or to real time, if your system lends itself to that.

Final words.

Like any artistic endeavor, the process of writing an adventure does not readily lend itself to a step-by-step approach. You will find that what I've had to say here can vary from one project to another, but I hope that I've given you some guidelines to developing your own adventure methodology.

I'll leave you with one last bit of advice—perhaps the most important of all. Do not attempt to write an adventure without knowing the field. Look at the current best-sellers as well as the "classics," and listen to what adventurers are saying about the games. Then, armed with knowledge of what the gamer wants, create a story that meets the needs of the market.