This file is part of the TADS 2 Author’s Manual.
Copyright © 1987 - 2002 by Michael J. Roberts. All rights reserved.
The manual was converted to HTML and edited by NK Guy, tela design.

Chapter Nine

Designing your First Game

The previous chapters have covered a lot of ground: the language, the parser interface, and even the general principles of object-oriented programming. Because TADS provides such a rich set of options, it’s often difficult when you’re first getting started with TADS to figure out the best way to do something.

This chapter is intended to help you through the process of writing a game with TADS. We’ll assume that you have a basic idea of how the TADS language works.

Designing and Implementing

Your author has been involved in the design and implementation of several text adventure games. The game development process presented here reflects the experience gained from those projects.

The first step is designing the game. Using a system like TADS, which makes it very easy to get started with a game, you may be tempted to jump right in and start programming your game, but you should instead turn off your computer and get out a pad of paper.

We did not follow this advice with Deep Space Drifter. After formulating the basic plot of the game, and mapping out the portion that takes place on the space station (roughly the first half of the game), we started implementation. We had a basic idea of the second half of the game, but it wasn’t even mapped.

Implementation went well for a while, but as we got further along, we started to run into details in the first half of the game that were dependent upon details from the undesigned second half. We improvised some details, and left others for later. As we did this, a strange thing happened: we started to realize that there were holes in the plot, and weird little inconsistencies that hadn’t occurred to us until we needed to think about details. As a result, we started to change our basic ideas about the second half, which led to even more inconsistencies and plot holes. It was like digging in sand, and before long we decided to throw out the entire original plan for the second half and start over.

However, we had so much time and effort invested in the space station that we didn’t want to throw it away. Instead, we tried to design a new second half that fit in with the existing first half. From this point on, the battle was lost. We went through a series of essentially unrelated plots for the game, trying to fit each new plot to an even larger set of existing implementation. We’d plan a little, implement it, then discover that the plan wasn’t working and would have to go - but the programming work we did would have to stay. The swamp, the cave maze, and the shuttle represented so much work that we couldn’t contemplate throwing them away, so whatever we came up with had to include them somehow; for a brief time, we were actually going to make the swamp a “Swamp Simulator” because it was the only way we could make it fit.

In the end, we were totally sick of writing Deep Space Drifter, but refused to let the project die before it was complete for psychological reasons. To me, this attitude shows through in the last half of the game; I think there’s a room on the planet whose description is something like this: “This room is very boring; you can leave to the north.” In fact, I think the entire game reflects its history: the space station is full of things to do, it has some nice running jokes, and it’s stylistically consistent. The planet, on the other hand, has an empty, barren feel; it’s spread out and there’s not much to do. The only parts that are interesting are essentially unrelated to each other and to the story in general, a reflection of having been forced into the game whether they belonged or not.

I’m not saying that Deep Space Drifter is a bad game - I like the space station a lot, and the puzzles on the planet are very elaborate and elegant. But the game has some serious flaws, most of which I attribute to the long, chaotic process of design and implementation.

Ditch Day Drifter, on the other hand, went through a much shorter and smoother design and implementation process, and I think a better game resulted. Admittedly, Ditch is a much smaller game than Deep, but it’s clear to me that the same design process could have been applied Deep, and that doing so would have resulted in a much better game.

Before any programming work started on Ditch, I had a complete map of the game and descriptions of all the objects and chracters in the game, including the key elements of their behavior. This made implementation very smooth and easy, because I could simply go through the lists of rooms and objects and implement each. I didn’t have to make any design decisions during implementation, which eliminated the desire to change design decisions that had already been made. The game took only a few weeks to implement, and came out fairly well.

If you resist the temptation to start programming before the design is complete, your game’s implementation will go much faster, the game will turn out much better, and most importantly, the chances that you complete your game will be much higher.

Designing a Game

Before you start implementing your game, you should have a list of all of the locations, objects, and characters in the game. For each location, object, and character in the game (to which we’ll refer collectively as “game elements” henceforth), you should have a description of the item and its key behavior. Basically, you should know enough about your game that you can go through the game and play it completely through, command by command. You don’t need to know all of the details of the game at this point, but you should know all of the details along the “minimal path” through the game (the series of commands that a player would type to go through the game from start to finish, if no mistakes are made and the player never needs to back up). The remaining details do not affect the plot, so you will be able to make these up as you go without creating plot holes or inconsistencies.

The complete map and object list is the result of the design process. To get there, you will probably go through many steps, adding detail as you go, until you have a complete design. The process detailed here is a good way to design a game, but you may find other ways that suit you better.


Most adventure games have a basic plot framework that controls the overall flow of the game. The plot is a good place to start your design.

An adventure game’s plot isn’t usually as elaborate as the plot of a non-interactive form of fiction, such as a book or a movie, because you have much less control over the details of the main character’s actions. This makes plot design much more difficult, but you should give the player as much control as you can, since adventure games are always more satisfying when they give players a greater sense of control. Adventure game plots, therefore, should simply be a framework that provides the general direction of action in the game, and specifies only the important events.

You should start off with a basic background and goal. Where does the game take place? When? Who is the main character? What must be accomplished by the time the game is over?

For example, in Ditch Day Drifter, the location is the Caltech campus (or perhaps Caltech in some parallel universe, since the game isn’t a strictly accurate simulation of the real Caltech), and the time is the present, generally, and Ditch Day, in particular. The main character is a Caltech underclassman. The goal is to solve the Ditch Day “stack” that the senior across the hall has created.

You can continue by identifying the major sub-goals that must be reached in order to reach the overall goal of the game. In Ditch, the major sub-goals are to find each treasure listed in the note that describes the stack.

Filling in the details of the plot can proceed by “working backwards” from the overall goal to the major sub-goals, then backwards to the smaller goals that must be reached for each sub-goal, and so on.

I would advise against designing a game with major sub-goals such as “the player must find the five rings of power.” When the sub-goals are abstract like this, they don’t suggest anything about what you might need to do to accomplish them. On the other hand, if a sub-goal is something concrete and specific like “the player must destroy the radio broadcasting tower,” the minor sub-goals come almost automatically: you need to break into the compound where the broadcasting tower is located, and you’ll need some sort of explosive, and you may need to turn off power to the tower to avoid being electrocuted. But if you can turn off the power, why do you need to blow it up? Maybe because an attendant will come and turn the power back on after a few turns. Now we have another puzzle: dealing with the attendant. Sub-goals that are abstract, such as finding five rings of power, aren’t nearly as helpful in getting to the next level of detail. Concrete sub-goals can often provide a seed that your imagination can almost automatically expand into a full set of plot elements.


The basic plot will provide an overall setting for the game, and the plot elements will usually suggest a specific set of large-scale locations. So, you’ll start off with a “low-resolution” map simply by designing the basic plot.

Next, you can start filling in the specific rooms. At this point, you’ll probably find that you start to fill in the details of the plot at the same time as you’re filling in the details of the setting. Many locations in the setting will offer natural puzzles: if you have a bank, you’ll probably have a safe, for which you’ll need to find the combination; maybe you’ll need to figure out how to defeat the alarm system, or perhaps you’ll need something to distract the teller; maybe you’ll need to find the key to the safety deposit box. If you have an airport, you’ll probably need to figure out how to get past the overly sensitive metal detectors, or you’ll need to know someone’s itinerary, or you’ll need to find some airline tickets, or you’ll need to find a badge or key or combination to get into a restricted area.

Whatever type of location you’re designing, the location will often suggest a series of puzzles to be solved. As you design the solutions to the puzzles, you’ll be adding detail to the plot, which will in turn give you new locations to develop.

As you flesh out the setting, you may be tempted to add enormous amounts of space to your locations. For example, if you’re building an airport, you may find yourself putting in dozens of gates, each pretty much the same as all the others. While the added space may make the game setting more like a real airport, it can often harm the game’s playability. Remember, you’re designing a game, not an airport - the most important thing is making the game fun to play, not “real.”

The main problem with adding lots of essentially unused space to a game is that it tends to make the level of detail throughout the game less consistent. You should make an effort to keep the level of detail as consistent as possible throughout the game, to avoid annoying and confusing the player. If you have a few rooms with a great deal of detail (such as lots of objects that can be examined and manipulated), the player will come to expect that level of detail in other rooms. The dozens of almost identical airport gates will not have anything interesting to do.

Objects and Characters

You’ll probably end up designing most of the game in the course of mapping out the setting and plot. As you develop plot elements, you should make notes of the objects and characters that are involved. You’ll probably find it easiest to note objects and characters on the map, where they’ll be placed.

For each object and character, you should make notes about its relevance to the game, and what it does. You should think carefully about what other objects might be used for the same purpose, and what other uses an object might have. For example, if you have a door that you need to break down, and you intend to provide an axe for this purpose, you should consider two things: What else might the axe reasonably be expected to destroy? And what else might reasonably be expected to be able to break down the door?

Because a player could reasonably expect an axe to have many uses, and because many objects should be able to break down a door, you should be very careful about creating puzzles that involve brute force and powerful tools of general utility. Explosives, flammable liquids, weapons, and heavy tools are all likely to frustrate the player when they don’t remove just about any physical obstacle. On the other hand, it would be very satisfying if you took the trouble to fully realize the axe and the door by allowing the axe to break down everything that’s reasonable, and allowing the door to be broken down by other reasonable objects.


Once you have the game fully designed, you’re ready to start implementing. In this section, we’ll show how to implement the basic types of objects.

Start off by drawing the map, and making annotations on the map describing the essential details of the plot. This should include placement of the major objects in the game, and descriptions of the important actions the player must perform.

As an example, we’ll implement a game that takes place in a small airport. Our airport will have a terminal area, a concourse, and a gate area. We’ll also have a plane parked at one of the gates. The terminal area will have a ticket counter, and a metal detector leading into the concourse. In the concourse, there will be a snack bar, and a locked door leading off into a security area. The gate area will have a couple of gates, plus a locked maintenance room. Here’s the basic map we’ll be implementing.

[ Map ]

This map conveniently has a couple of locked areas, which we can use for puzzles. In addition, we can probably find some use for the metal detector, since it will prevent the player from carrying any objects through it. The plane can also be a puzzle, since you’d normally need a ticket to board a plane. Plus, the cockpit should be restricted to airline personnel.

Let’s make the goal of the airport segment be getting out of the airport. The player will start off in the main terminal area, but won’t be able to go outside the terminal - we’ll make up some excuse, such as heavy traffic that always pushes the player back into the terminal, to prevent exiting that way. (If this were an actual game, we’d probably have more game outside the airport, so we wouldn’t use such an artificial boundary as having heavy traffic that pushes the player back in. For this example, though, we want to keep things fairly small.) The only other obvious way to get out of the airport is to fly out on a plane; so, let’s make the goal be to fly the plane.

To take the plane out of the airport, the player will have to get into the cockpit. (We’ll implement this example up to the point that the player makes it into the cockpit; in a full game, we’d go on to let the player fly the plane somewhere else.) Now, only the pilot can go into the cockpit - the flight attendant wouldn’t let a passenger into the cockpit. So, we’ll need some way to get past the flight attendant. One way would be to create a diversion that distracts the flight attendant long enough to slip by; for this example, though, we’ll require the player to find a pilot’s uniform.

Where would the pilot’s uniform be? The pilot’s lounge would be a logical place; we’ll put a suitcase in the pilot’s lounge that contains a uniform. Fortunately, the lounge is behind a locked door, which creates a secondary puzzle. To get into the security area that contains the pilot’s lounge, the player needs a magnetic ID card to put into a slot outside the security area.

We’ll put the ID card out in the open, on the ticket counter in the terminal area. However, we’ll make it impossible to carry the ID card past the metal detector - the card will set off the metal detector, and the security guard will confiscate it (and place it back on the counter so that the player can try again). To get the card by the metal detector, you’ll have to turn off the power to the metal detector.

The power switch will be in the maintenance room, which is locked with a key. We’ll leave the key with some other maintenance items in the plane’s bathroom - we’ll also leave a pail, sponge, and garbage bag, so that it’s clear by association that the key is probably for the maintenance room.

To get into the plane’s bathroom, you’ll need a ticket to board the plane. We’ll make the ticket fairly simple to find: we’ll leave it hidden inside a newspaper in the snack bar. As soon as you pick up the newspaper, the ticket will fall out.

So, that’s about the whole game: you go to the snack bar, pick up the newspaper, and find the ticket. You take the ticket and board the plane, then go to the plane’s bathroom and get the key. Take the key to the maintenance room, unlock the door, enter, and turn off the power to the metal detector. Go back to the ticket counter, pick up the ID card, go to the security door, put the magnetic card in the slot, and enter the security area. Go to the pilot’s lounge, get the pilot’s uniform out of the suitcase, and wear it. Go to the plane, and stroll right past the flight attendant and into the cockpit.

We should draw a new map now, which includes annotations for the main objects and actions that make up the game.

[ Detailed Map ]

Implementing the Map

The first step is to convert the skeleton of your map into the beginnings of your game program. At this point, don’t worry about entering all of the detailed behavior of your map, but just build the basic rooms and connections between rooms. This will allow you to get a prototype of the game running quickly, so you can walk around it and see how it feels.

Start off by creating a source file for your game, and including the base definition files:

#include <adv.t>
#include <std.t> 

Remember, as always, to be be absolutely certain that the #include command has no space characters in front of it. The # must be the first symbol on the line.

Now, for each room in your game, make an entry that gives the room’s name (sdesc, or short description) and long description (ldesc), and the other rooms that are connected to this room. Here’s how to implement the first few rooms from the sample map above. For the time being, we won’t worry too much about making the long descriptions complete; we can always flesh those out later.

  terminal: room
    sdesc = "Terminal"
    ldesc = "You are in the airport's main terminal. To the east,
    you see some ticket counters; to the north is the main concourse. "
    east = ticketCounter
    north = securityGate

  ticketCounter: room
    sdesc = "Ticket Counter"
    ldesc = "You are in the ticket counter area. Ticket counters
    line the north wall; so many people are waiting in line that 
    you're sure you'll never manage to get to an agent. The main
    terminal is back to the west. "
    west = terminal

  securityGate: room
    sdesc = "Security Gate"
    ldesc = "You are at the security gate leading into the main
    concourse and boarding gate areas. The concourse lies to the
    north, through a metal detector. The terminal is back to the
    south. "
    north = concourse
    south = terminal

  concourse: room
    sdesc = "Concourse"
    ldesc = "You are in a long hallway connecting the terminal
    building (which lies to the south) to the boarding gates (which are
    to the north). To the east is a snack bar, and a door leads west.
    Next to the door on the west in a small slot that looks like it accepts
    magnetic ID cards to operate the door lock. "
    north = gateArea
    south = securityGate
    east = snackBar
    west = securityArea

The other rooms are implemented in the same manner. For now, we’re not worrying about the items contained in the rooms, or the other people around, or even the locked doors. We’ll just implement all the rooms so we can walk through the map and try it out.

Implementing the items

The next step is to implement the basic objects that make up the game. As with the rooms, don’t worry about the complex behavior of some of the objects at this point; just go through and write basic object definitions for the main items in the game.

Items have different properties than rooms. The basic properties of an item are its name (sdesc), long description (ldesc), vocabulary words (noun and possibly adjective), and container (location, which may be either a room or another item). If the item can be carried by the player, the object will be of class item; if not, it will be of class fixeditem. Some items may be of different classes; for example, if you want to make an object that can contain other objects (such as the pail), make it a container. If you want to be able to put objects on top of another object, use a surface object. You can make something both a container or surface and a fixeditem if you want.

Here are some of the basic object definitions for our sample game.

  counter: fixeditem, surface
    location = ticketCounter
    noun = 'counter'
    adjective = 'ticket'
    sdesc = "ticket counter"

  IDcard: item
    location = counter
    noun = 'card'
    adjective = 'id' 'identification'
    sdesc = "ID card"
    adesc = "an ID card"

  newspaper: readable
    location = snackBar
    noun = 'newspaper' 'paper'
    adjective = 'news'
    sdesc = "newspaper"
    ldesc = "It's today's copy of USA YESTERDAY. "
    readdesc = "You read a few articles, and promptly become depressed.
    The federal deficit just went up by another twenty billion dollars, but it's
    all \"off budget,\" so it doesn't really count. There's another White
    House scandal involving illegal arms sales, money laundering through Italian
    banks, Congressional Pages; several high-ranking federal arts critics have
    already resigned in disgrace. The economy had yet another downturn, but the
    President says he's confident that the recovery is \"just around the
    corner and picking up steam.\" "

  cardslot: fixeditem
    location = concourse
    noun = 'slot'
    adjective = 'card'
    sdesc = "card slot"
    ldesc = "The slot appears to accept special ID cards with magnetic
    encoding. If you had an appropriate ID card, you could put it in the slot
    to open the door. "

  suitcase: openable
    isopen = nil
    location = pilotsLounge
    noun = 'suitcase'
    sdesc = "suitcase"

  uniform: clothingItem
    location = suitcase
    noun = 'uniform'
    adjective = 'pilot' 'pilot\'s'
    sdesc = "pilot's uniform"
    ldesc = "It's a uniform for an Untied Airlines pilot. It's
    a little large for you, but you could probably wear it. "

The rest of the objects are implemented in much the same way. In implementing the basic objects, the main properties you need to fill in are location, so the object appears somewhere in the game; noun, so the player can refer to the object; and sdesc, so the system knows what to call the object when it mentions the object in messages. It’s also important to choose the appropriate class for each item, so that you can get the correct basic behavior of the object without any additional work. At some point, you should go through adv.t and familiarize yourself with the classes defined there, so you know what you can get from adv.t classes without any work. See Appendix A for full details on adv.t.

Implementing Special Behavior

The next step is to implement all of the special behavior that really makes the game work. For example, let’s implement the simple mechanism that lets the player find the airline ticket upon picking up the newspaper. To do this, all we need to do is add a doTake method to the newspaper object (we’ll just show the new doTake method below; the rest of the object is the same as shown above):

  doTake( actor ) =
    if ( not self.foundTicket )
      "As you pick up the paper, an airline ticket
      that was inside falls to the floor. " ;
      ticket.moveInto( actor.location );
      self.foundTicket := true;
    pass doTake;

This method runs whenever the player takes the newspaper. The first thing we do is check to make sure that the airline ticket hasn’t already been found; if not, we display a message that it’s been found, move the ticket into the game, and note that it’s been found. Finally, we continue with the default doTake action that the newspaper object inherited from its superclass (in this case, readable) by using the pass statement.

Note that the airline ticket itself should be defined with no location, because it’s not anywhere at all when the game first starts:

  ticket: item
    noun = 'ticket'
    adjective = 'airline'
    sdesc = "airline ticket"
    ldesc = "It's a one-way ticket to New York, in class C
    (the \"C\" probably stands for \"Cattle\"). "

As another example, let’s implement the puzzle the keeps the player out of the security area until the ID card is used to unlock the door. First, we must prevent movement from the concourse into the security area. For this, we’ll change the concourse room definition, and add a door object.

  concourse: room
    sdesc = "Concourse"
    ldesc = "You are in a long hallway connecting the terminal
    building (which lies to the south) to the boarding gates (which are
    to the north). To the east is a snack bar, and a door leads west.
    Next to the door on the west is a small slot that looks like it
    accepts magnetic ID cards to operate the door lock. "
    north = gateArea
    south = securityGate
    east = snackBar
    west =
      if ( securityDoor.isopen )
        return( securityArea );
        "The door is closed and locked. ";
        return( nil );

  securityDoor: fixeditem
    location = concourse
    noun = 'door'
    sdesc = "door"
    isopen = nil
    ldesc =
      "The door has a label reading SECURITY AREA-AUTHORIZED
      if ( self.isopen )
        "The door is open, which isn't very secure. ";
        "The door is securely closed. ";
    verDoOpen( actor ) =
      "The door is securely locked. ";
    verDoUnlock( actor ) =
      "You should examine the slot if you want to unlock the door. ";

The door is really just a decoration item; the various methods we implement are just to inform the user that the door can’t be operated directly. The real work is done by the card slot; we’ll add some new behavior to that object now.

  cardslot: fixeditem
    location = concourse
    noun = 'slot'
    adjective = 'card'
    sdesc = "card slot"
    ldesc = "The slot appears to accept special ID cards with
    magnetic encoding. If you had an appropriate ID card, you could
    put it in the slot to open the door. "
    verIoPutIn( actor ) = {}
    ioPutIn( actor, dobj ) =
      if ( dobj = IDcard )
        if ( securityDoor.isopen ) 
          "You put the card in the slot; nothing happens,
          so you remove it. ";
          "You put the card in the slot. There's a click, and
          the security door pops open! You remove the card. ";
          securityDoor.isopen := true;
        "That doesn't seem to fit in the slot. ";

The new behavior is that the player can put the ID card in the slot. When this is done, the ioPutIn method runs, with the ID card as the direct object (the dobj parameter). This method opens the door, if it’s not already open.

Most of the remaining puzzles in this sample game are implemented in a similar fashion. You’ll need to implement a couple of actors: one for the flight attendant, and one for the guard at the metal detector. In addition, you’ll need a few more locked doors and special items.

We won’t go any further into the other puzzles, because the next chapter describes in much greater detail how to implement these and much more.

Where to go from here

Before expanding this sample game by adding more areas, you could flesh out the game by adding lots of detail to what we’ve implemented so far. Most of the added material would probably be irrelevant to the plot, but it could make the game more interesting and more fun to play. Keep in mind that you’re writing a game, not a real-world simulator; try to concentrate on things that make the game more fun to play.

Some items that would enhance the airport: Add lots of incredibly overpriced and extremely dubious snack items at the snack bar. Generate random messages over the public address system once in a while, asking various people to pick up the white courtesy telephone and warning travellers not to park in the red zone. Implement other effects for other power switches in the maintenance room: what happens when you turn off power to the snack bar, or the ticket counter, or the PA system, or the automatic doors? Add lots of strange people milling about in the airport; make some of them actively bother the player, such as various fringe religious and political groups trying to hand out literature (you’ll want to write some wacky literature for them to distribute).

Alternatively, you could expand this game by providing some place to fly to. The player could go on to crash the plane into a remote mountain or desert island, and explore that. Or, you could take the plane to several other cities and explore.

Of course, you’ll probably have the most fun if you start with your own ideas and write a whole new game. The hard part is always finding the right idea; once you have the premise for your game, you will probably be surprised at how quickly you can build a map and start implementing. Refer to the examples in this chapter to help you get started. As your game starts to take shape, and you want to add more ambitious features, the examples of advanced TADS programming techniques shown in the next chapter should be helpful.

Better Adventures

I 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. However, it’s up to you, the author, 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.

Style in Adventure Writing

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 offer some ideas about what makes a good game.

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. This claim is usually 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’s 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 needn’t 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 or she will type “push button” and “turn knob.”

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 or her 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 or she is trying to accomplish. Metaphorically, a player should always be able to find a locked door before finding the key. This way, the goals are clear. 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 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. The player solves puzzles by learning the behavior of an object or character, and turning that to his or her 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 which also forces the player simply to think to try the one special thing that it does. Something should invite him or her 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 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, they 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 moving 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.


In this final chapter, we approach style in its broader meaning: style in the sense of what is distinguished 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?
E. B. White, The Elements of Style (Third Edition, 1979)

In creating, the only hard thing’s to begin; a grass-blade’s no easier to make than an oak.
JAMES RUSSELL LOWELL, A Fable for Critics (1848)

Chapter Eight Table of Contents Chapter Ten