GAME DESIGN AT THE DRAWING BOARD - part 1 By 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: Maps ---- If 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 indispensable, 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... _______ _______ | Dining| | | | Room | | Attic | |_______| |_______| | \ /D ___|___ \ _______U/ _______ | | | | | | |Kitchen| |Hallway|---|Bedroom| |_______| |_______| |_______| | / N ___|___ / | To | Living| W---|---E 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 labeled 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). ------- ------- ------- To | X X X | | X X 2 | | 1 5 6 | Maze <-----| 1 5 | | 7 2 6 | | X 3 X | Entrance | X 3 X | | 1 X X | | 6 2 4 | ------- ------- ------- ------- ------- ------- | 6 X 1 | | 6 X 4 | | 2 1 3 | | 2 4 5 | | 1 5 2 | | 5 6 X | | X 1 4 | | 3 7 1 | | 3 4 X | ------- ------- ------- N | ------- ------- ------- W---|---E | X 1 4 | | 2 7 9 | | 1 2 4 | To | | 7 7 X | | 3 8 5 | | 8 9 |---->Treasure S | 2 8 6 | | 1 6 4 | | 3 1 2 | Vault ------- ------- ------- Game Walkthrough ---------------- A 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 of the game in as few... steps as you want. GET LEAFLET FROM MAILBOX OPEN MAILBOX ENTER HOUSE THROUGH WINDOW GET LEAFLET GET LANTERN AND SWORD SOUTHEAST GET ROPE AND KNIFE NORTHEAST MOVE RUG OPEN WINDOW OPEN TRAPDOOR AND ENTER CELLAR ENTER HOUSE WEST GET LANTERN GET SWORD EAST TURN ON LANTERN UP GET ROPE GET KNIFE DOWN WEST MOVE RUG OPEN TRAPDOOR DOWN Scoring List ------------ You 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 points in order from individual steps leading up to beginning to end... the actual scoring itself. OBTAIN KULCAD SCROLL -- 25 OBTAIN KULCAD SCROLL -- 25 FIND OZMOO SCROLL -- 25 * CAST NITFOL ON TURTLE SURVIVE SACRIFICE -- 35 * LEAD TURTLE TO ENGINE ROOM OPEN JEWELLED BOX -- 25 * CAST EXEX ON TURTLE * COMMAND TURTLE TO GET SCROLL FIND OZMOO SCROLL -- 25 * ENTER GALLERY WITHOUT LIGHT * REMOVE LIGHTED PORTRAIT SURVIVE SACRIFICE -- 35 * MEMORIZE OZMOO SPELL * ENTER TEMPLE & GET CAPTURED * CAST OZMOO ON YOURSELF OPEN JEWELLED BOX -- 25 * CUT ROPE WITH DAGGER _OR_ * CAST KULCAD ON ROPE 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 Specifications ------------------------------ These 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." (In this context, I use "object" when referring to something in the room that cannot be taken by the player. "Item" refers to something that can.) REGION: Above Ground ROOM: West of House "You are standing in an open field west of a white house, with a boarded front door." EXITS: North, Northeast to "North of House" South, Southeast to "South of House" West to "Forest" East -- "The door is boarded and you can't remove the boards." OBJECTS: House -- No initial description. Examine -- "The house is a beautiful colonial house which is painted white. It is clear that the owners must have been extremely wealthy." Enter -- "I can't see how to get in from here." Front Door -- No initial description. Open -- "The door cannot be opened." Small Mailbox -- "There is a small mailbox here." Can be opened and closed, acts as a container. ITEMS: Leaflet -- Inside small mailbox. Read/ -- "WELCOME TO ZORK! Examine ZORK is a game of adventure, danger, and low cunning. In it you will explore some of the most amazing territory ever seen by mortals. No computer should be without one!" Can be burned and cut. ROOM: North of House ...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. More next issue - o -