Game Design at the Drawing Boardby C.E. Forman
What types of planning tools and techniques might prove useful to budding IF designers, especially those who have little or no programming experience? I recently posed the question to the inhabitants of a small yet extremely loyal and all-knowing sect, namely the rec.arts.int-fiction Usenet newsgroup. From them I received a small number of suggestions, enough to convince me that there was indeed an interest in such a subject, yet small enough to indicate that most authors either take design for granted, not giving it a great deal of conscious thought, or simply don't make much use of organized design methods, resorting to standard note-taking procedures for the entire design phase.
Please keep in mind that it's not necessary to use all these techniques for a single game layout. In fact, you may not even want to use any of them. Everything herein is offered to IF writers solely as a suggestion. There are no absolutely "right" or "wrong" ways to go about creating an adventure game, but the concepts I've listed here have the potential to greatly simplify the task. Or if nothing else, they can provide a good hearty laugh at my expense, since I'm currently making extensive use of several of them during my own design phase.
To help illustrate these ideas, I've included examples from existing games in the appropriate places. This article makes use of Infocom's "Zork I" and "Enchanter," two games that most players should be quite familiar with. Just in case you're not, I'll mention now that there are minor spoilers for "Zork I" and major spoilers for "Enchanter" in this article. You have been warned. Now, let's look at some of the more common design tools used:
MapsIf you use only one sheet of paper to plan your entire game, you should use it to sketch out the game's maps. This may sound obvious, but I have in fact heard of authors who have kept their games' layouts entirely in their head, usually because the game is based on a place the author knows extremely well. A good, accurate game map is virtually indispensible, as it keeps an author from forgetting the layout of the game and deciding to place one puzzle in the same location as another. Further, it's far easier to alter or expand a map on paper should you discover that some aspect of the game just isn't going to work out with the existing layout.
Virtually all I-F designers (and players too, for that matter) seem to prefer drawing their maps in the style made famous by Infocom -- that is, using boxes for each room, with lines connecting rooms in the appropriate directions. For more complex locations, such as mazes or puzzle areas with complicated layouts, using a special technique will probably help make the map easier to read.
=========== Here's a simple map made by imitating Infocom's game maps... = EXAMPLE = _______ _______ = EXAMPLE = | Dining| | | = EXAMPLE = | Room | | Attic | = EXAMPLE = |_______| |_______| = EXAMPLE = | \ /D = EXAMPLE = ___|___ \ _______U/ _______ = EXAMPLE = | | | | | | = EXAMPLE = |Kitchen| |Hallway|---|Bedroom| = EXAMPLE = |_______| |_______| |_______| = EXAMPLE = | / N = EXAMPLE = ___|___ / | = EXAMPLE = To | Living| W---|---E = EXAMPLE = Back <-----| Room | | =========== Yard |_______| S...and this is my own personal technique for creating mazes. Each maze location is given a number, and the valid exits are labelled to correspond with the numbers of the rooms to which they lead. In the diagram below, the center number is the number of the room, and the numbers surrounding it represent the various exits. (An "X" represents a direction in which movement is blocked.) For example, room #1 has doors leading south to room #3 and east to room #5, while the western exit leaves the maze entirely. Notice also that some rooms have multiple exits going to the same room (room #4 has two exits to room #1), and that a few rooms have exits that lead back to themselves (rooms #2, #4, and #7).
= EXAMPLE = ------- ------- ------- = EXAMPLE = To | X X X | | X X 2 | | 1 5 6 | = EXAMPLE = Maze <-----| 1 5 | | 7 2 6 | | X 3 X | = EXAMPLE = Entrance | X 3 X | | 1 X X | | 6 2 4 | = EXAMPLE = ------- ------- ------- = EXAMPLE = = EXAMPLE = ------- ------- ------- = EXAMPLE = | 6 X 1 | | 6 X 4 | | 2 1 3 | = EXAMPLE = | 2 4 5 | | 1 5 2 | | 5 6 X | = EXAMPLE = | X 1 4 | | 3 7 1 | | 3 4 X | = EXAMPLE = ------- ------- ------- = EXAMPLE = N = EXAMPLE = | ------- ------- ------- = EXAMPLE = W---|---E | X 1 4 | | 2 7 9 | | 1 2 4 | To = EXAMPLE = | | 7 7 X | | 3 8 5 | | 8 9 |----->Treasure = EXAMPLE = S | 2 8 6 | | 1 6 4 | | 3 1 2 | Vault =========== ------- ------- -------
Game WalkthroughA game walkthrough is a list of all the steps necessary to solve the game. This can be as detailed or as brief as you want, as shown in the example from "Zork I" below. Often the game may not have fully taken shape, but the gaps in a simple walkthrough can easily be filled in as you go along. Although they're impractical in most cases, extremely detailed walkthroughs, which even go so far as to include the necessary directional moves (N, S, E, W, etc.), can save a lot of headaches when you're dealing with puzzles that need to be solved within a specified number of turns.
=========== You can write out a walkthrough ...or as many individual = EXAMPLE = of the game in as few... steps as you want. = EXAMPLE = = EXAMPLE = GET LEAFLET FROM MAILBOX OPEN MAILBOX = EXAMPLE = ENTER HOUSE THROUGH WINDOW GET LEAFLET = EXAMPLE = GET LANTERN AND SWORD SOUTHEAST = EXAMPLE = GET ROPE AND KNIFE NORTHEAST = EXAMPLE = MOVE RUG OPEN WINDOW = EXAMPLE = OPEN TRAPDOOR AND ENTER CELLAR ENTER HOUSE = EXAMPLE = WEST = EXAMPLE = GET LANTERN = EXAMPLE = GET SWORD = EXAMPLE = EAST = EXAMPLE = TURN ON LANTERN = EXAMPLE = UP = EXAMPLE = GET ROPE = EXAMPLE = GET KNIFE = EXAMPLE = DOWN = EXAMPLE = WEST = EXAMPLE = MOVE RUG = EXAMPLE = OPEN TRAPDOOR =========== DOWN
Scoring ListYou may find it helpful to keep a record of all points awarded in the game, as well as how to obtain them. This sheet may be little more than a simplified walkthrough, listing only the actions which earn the player points, or it may show how each point-giving action is broken down into its individual steps. The example below, a small portion of the scoring from Infocom's "Enchanter," illustrates both methods:
=========== You can simply list the ...or you can also include the = EXAMPLE = points in order from individual steps leading up to = EXAMPLE = beginning to end... the actual scoring itself. = EXAMPLE = = EXAMPLE = OBTAIN KULCAD SCROLL -- 25 OBTAIN KULCAD SCROLL -- 25 = EXAMPLE = FIND OZMOO SCROLL -- 25 * CAST NITFOL ON TURTLE = EXAMPLE = SURVIVE SACRIFICE -- 35 * LEAD TURTLE TO ENGINE ROOM = EXAMPLE = OPEN JEWELLED BOX -- 25 * CAST EXEX ON TURTLE = EXAMPLE = * COMMAND TURTLE TO GET SCROLL = EXAMPLE = FIND OZMOO SCROLL -- 25 = EXAMPLE = * ENTER GALLERY WITHOUT LIGHT = EXAMPLE = * REMOVE LIGHTED PORTRAIT = EXAMPLE = SURVIVE SACRIFICE -- 35 = EXAMPLE = * MEMORIZE OZMOO SPELL = EXAMPLE = * ENTER TEMPLE & GET CAPTURED = EXAMPLE = * CAST OZMOO ON YOURSELF = EXAMPLE = OPEN JEWELLED BOX -- 25 = EXAMPLE = * CUT ROPE WITH DAGGER = EXAMPLE = _OR_ = EXAMPLE = * CAST KULCAD ON ROPE = EXAMPLE = = EXAMPLE = Notice also that, with the jewelled box, both possible =========== solutions to the problems are noted.
After any changes have been made to the scoring system, it's easy to update the maximum score. Eliminating scoring problems, such as allowing players to earn more than the maximum, or making it impossible for the maximum to be achieved, is the primary goal of a scoring list. It also helps the designer to recognize situations where he or she is faced with optional puzzles (that is, puzzles that don't really have to be solved to win), puzzles with multiple valid solutions, and puzzles that can be solved repeatedly in the same game session.
Object and Item SpecificationsThese are the details and descriptions that hold the game together. The goals here are to keep track of how things in the game change with the passage of time and completion of certain events in the game, and how the objects, characters, and items react when used in conjunction with one another. Most items won't behave in any special way, but the ones that do should be noted. Trying to think of strange ways to use things together will help flesh out the game, and should give you plenty of ideas for burying amusing text for players to discover.
=========== Here are the specifications for the first room in "Zork I." = EXAMPLE = (In this context, I use "object" when referring to something in = EXAMPLE = the room that cannot be taken by the player. "Item" refers to = EXAMPLE = something that can.) = EXAMPLE = = EXAMPLE = REGION: Above Ground = EXAMPLE = = EXAMPLE = ROOM: West of House = EXAMPLE = "You are standing in an open field west of a white = EXAMPLE = house, with a boarded front door." = EXAMPLE = = EXAMPLE = EXITS: = EXAMPLE = = EXAMPLE = North, Northeast to "North of House" = EXAMPLE = South, Southeast to "South of House" = EXAMPLE = West to "Forest" = EXAMPLE = East -- "The door is boarded and you can't remove the = EXAMPLE = boards." = EXAMPLE = = EXAMPLE = OBJECTS: = EXAMPLE = = EXAMPLE = House -- No initial description. = EXAMPLE = Examine -- "The house is a beautiful colonial = EXAMPLE = house which is painted white. It is = EXAMPLE = clear that the owners must have been = EXAMPLE = extremely wealthy." = EXAMPLE = Enter -- "I can't see how to get in from here." = EXAMPLE = = EXAMPLE = Front Door -- No initial description. = EXAMPLE = Open -- "The door cannot be opened." = EXAMPLE = = EXAMPLE = Small Mailbox -- "There is a small mailbox here." = EXAMPLE = Can be opened and closed, acts as a container. = EXAMPLE = = EXAMPLE = ITEMS: = EXAMPLE = = EXAMPLE = Leaflet -- Inside small mailbox. = EXAMPLE = Read/ -- "WELCOME TO ZORK! = EXAMPLE = Examine ZORK is a game of adventure, danger, = EXAMPLE = and low cunning. In it you will = EXAMPLE = explore some of the most amazing = EXAMPLE = territory ever seen by mortals. No = EXAMPLE = computer should be without one!" = EXAMPLE = Can be burned and cut. = EXAMPLE = = EXAMPLE = = EXAMPLE = ROOM: North of House = EXAMPLE = =========== ...and so on.You might also find it helpful to note down any common synonyms for the people, places, and things in your game.
Your specs shouldn't have to be anywhere near as detailed as the example I've given above, since the more user-friendly IF languages automatically take care of the tiny details for you. But forcing yourself to look at these details can go a long way toward learning good design.
Further, if you're using a pre-written parser system, such as TADS, AGT, or Inform, you'll pretty much have the entire code written out for you when you're done. I personally prefer to scribble out a crude list on paper and then type the specifications into an ASCII (text) file. The time saved by being able to append the file to your existing game code (which at this point would probably contain only the room descriptions and possibly some grammar extensions) is a tremendous advantage. Translating the example above into Inform or TADS could be accomplished in a matter of seconds.
Some authors may prefer to simply type the details of their objects and items directly into the game code. That's fine too, but I personally like the other approach, since it allows me to concentrate on the writing, which is what interactive fiction is really all about. By appending the text to your source code, you don't have to worry about programming at all until the story is completely finished. In my humble opinion, that's a good thing.
TranscriptAnyone familiar with Infocom will likely understand what I mean by a transcript. Basically, it's an example of what the game will look like when it's being played. Transcripts include not only what the game will print on the screen, but also the player's commands that cause the various responses. I only write a transcript when I'm having trouble getting the story started, or if I need to visualize how a complex puzzle should work. Like object and item specs, anything you write into a transcript will mean less time spent coding later.
Puzzle Structure ChartThis is my own personal favorite design tool, but unfortunately it's also the most difficult for me to describe in words. A puzzle structure chart is much like a hierarchy diagram which lists the necessary puzzles in an adventure game, from beginning to end, and indicates what must be done before each puzzle can be solved. Confused? Maybe it'll become clearer if you look at the example below. This is the complete puzzle structure chart for Infocom's "Enchanter" (and just in case you overlooked the first warning, the following diagram contains some really big-time spoilers):
START | ___________________________________|__________________________________ | | | Open Fill Get oven jug REZROV | | | | | | Eat Drink REZROV bread water gate | | | | | | | / FROTZ | / an item | / _______________________________________________________________| |/ | | | | | | | | Open REZROV Sleep Open NITFOL Enter Reach | egg n. gate in bed cell turtle Gallery in | | | | | | w/o light rathole | | | | | | | | | \ Get Open Move Lead | | | \ KREBF bedpost block turtle Move Get | \ | | | into portrait GONDAR | \ | | | Engine | | | \| Get Get Room | | | | VAXUM EXEX | Get | | | | | | OZMOO | | Fix | | | | | | ZIFMIA | EXEX | | | | | | turtle | Cast | | | | | | OZMOO | | Summon | | / on | | adventurer | | / yourself | | | / | / | | | | / |/ | | | | / | Survive | | | / | sacrifice | | |/ "TURTLE, in temple | | | BRING ME THE | | | | SCROLL" | | | VAXUM | Open | | adventurer | jewelled | | | | box | | | | | | | Lead | | | | adventurer | Get | | to guarded | MELBOR | | doorway | | | | | | | | | | | Cast | | "ADVENTURER, | MELBOR | | OPEN DOOR" | on | | | | yourself | | | | | | | Get map | | | | and pencil | Enter | | | | area | | | | beyond | | Release | junction | | Unseen Terror | | | | | | | | | | | / | | Recapture | / | | Unseen Terror | / | | | | / | | | | / | | Get | / | | GUNCHO | / | | | | / | | | | / | | | |/ | | | | | | | | | | | KULCAD | | | stairs | | | | | | | | | | | Cast / | | IZYUK / | | on / | | yourself / | | | / | | | / | | / / | | / / \ | / / \ | / / \ | / / \ | / / \ | / / \ | / / \ | / / \|/ / | / | / Enter / Krill's / tower / | / | / | / | / |/ | | GONDAR dragon | | VAXUM (or CLEESH) shape | | GUNCHO Krill | | END
Okay, let's start at the top of the chart and work downwards. At the start of "Enchanter," there are really only three significant tasks for the player to accomplish--opening the oven to find the bread, filling the jug with water, and getting the REZROV spell. The three separate paths leading off from "START" reflect this.
Note also that only one of these paths, finding the REZROV spell, really opens the doorway to further adventure. Eating and drinking are merely necessary to keep the player alive long enough to reach the end. So the game starts out almost purely linear, requiring players to find the spell, use it to enter the castle, and use the FROTZ spell to create a light, before anything else can be accomplished. Once the player gets past these first few minor obstacles, however, the scope of the puzzles reaches its widest point. The game is now quite non-linear, with seven distinct paths that players are able to follow.
As an example, let's assume that the player's first task is to open the jewelled egg and obtain the shredded ZIFMIA scroll inside. Let us assume that the player then proceeds to cast the REZROV spell on the castle's rusted north gate in order to gain access to the forest beyond, where the scroll inscribed with the KREBF spell is located. The player now has the KREBF spell and the shredded ZIFMIA scroll itself, both of which are necessary in order for the shredded scroll to be fixed. So the two initially separate paths merge into one, and the KREBF spell can now be used to obtain the ZIFMIA spell, which in turn can be used to summon the wandering adventurer.
In a puzzle structure chart of this nature, when a path splits into two or more separate pathways, this indicates that there is more than one puzzle for the player to solve at that particular point in the game. When two (or more) paths merge into one, however, it indicates that both paths must be completely traversed before the player can continue. You couldn't obtain the ZIFMIA spell without the KREBF spell, nor could you get ZIFMIA if you didn't have the shredded scroll on which it is written in the first place. The puzzles leading up to the acquisition of both items must be solved before the two items can be used together to solve a third puzzle.
And what about optional puzzles, and puzzles with more than one solution? Well, to keep the above example less cluttered, I didn't include the CLEESH spell, since it isn't essential to victory. I did make a note that it could be used in place of VAXUM when confronting the shape in the endgame. The discovery of the CLEESH spell could have been inserted on a separate path branching off of the path in which the player enters the forest and finds the KREBF scroll, and later tied into the endgame.
With a puzzle structure chart, however, neither of these are absolutely necessary. A puzzle structure chart allows the designer to explore a game's linearity, to determine if it's too rigid or too vast and overwhelming. It lets a designer see if changes in the arrangement of the game's puzzles need to be made, and if so, where. Puzzle structure charts also eliminate circular logic in puzzles, that is, puzzle A needing an item that can only be obtained by solving puzzle B, which in turn can only be solved with an item from puzzle A. If such a situation exists, it will reveal itself in a puzzle structure chart.
The last important step involves deciding which techniques to use in combination with each other. It's really up to your own personal preference. I prefer puzzle structure charts, combined with a concise scoring list, when I'm designing on paper. As the game begins to take shape, I like to sit down and type out specifications for objects, items, and characters. And, of course, a good map is always put to use.
Go to the next page in this issue
Return to Eileen's home page
This site is maintained by Eileen Mullin