Previous Top Next

So before jumping right in to describing how these adventure games work, let me start by saying a little bit about what they do. These games follow a simple kind of play, in which the computer prints out something, typically a description of where the player is, what objects are lying around, and what directions the player may travel in from this point. Then the player types in some instructions in English, telling the computer what to do next.

Here is some sample output (the player's input is in bold):

Room One

This is Room One.  This is where it all begins. 
It's decorated entirely by your imagination.
There is a dark opening in the stone wall to 
the East, and a doorway in the southern wall
leads out into the forest. 

You see:
  a small rock hammer
  a gold ring

Obvious exits:
  east, south,  

> take hammer
a small rock hammer: Taken.

> go south


You are in a dark forest.  A river flows by
blocking travel to the Wast and South.  North,  
there is a doorway set in a stone wall.  To
the West lies a warp in the space-time continuum.

You see:
  a kerosene lantern 

Obvious exits:
  north, east, 

> take lantern
a kerosene lantern: Taken.

> drop hammer
a small rock hammer: dropped.

> inventory

You are carrying:
  a kerosene lantern 

So, for the computer to respond in this way to these commands, it must:

  • Keep track of a list of all the locations in the game that the player might visit (and a few he will never visit).
  • Keep track of the current location of the player.
  • Keep track of all the interconnections between all the locations, (or henceforth "rooms") so that it is known where the player would wind up if he were to go, say "east", from wherever he might currently be.
  • Keep track of all the objects in the game and their current locations.
  • Read in the user's input, and make some kind of sense of it, and modify the attributes of the player or objects, or room descriptions as appropriate.

For the output shown above, this list is sufficient. More complex interactions might require keeping track of more things, such as whether a door between two rooms is opened, closed, or closed and locked.

So starting with the first item on the list, keeping track of all the rooms in the game. This calls for an array, an array of rooms. So what's a room, what information about each room must we keep?

  • A short name for the room.
  • A longer description of the room.
  • interconnections to other rooms.

The first two are easy. A simple string will handle each of those. But what about the interconnections to other rooms? What's a good way to represent that?

Well, there are a limited number of directions the player is allowed to move. Typically, these are the points of the compass, N,NE,E,SE,S,SW,W,NW, plus "up" and "down", making a total of ten different directions which the player might conceivably be allowed to move from any given location. So, for each room, just store 10 pieces of information, namely which room the player gets to if he moves in each of the ten directions. So what's a good way to represent "which room?" Normally, the room's "number", that is, it's offset into the array of rooms is used. If travel is impossible in a given direction, the value -1 may be used to signify this.

So, we can use the following C structure to represent a room in our adventure game:

#define NDIRS 10

struct room_t {         /* one  for each room in the game */
        char *short_name;      
        char *description;     
        int tt[NDIRS];  /* n,ne,e,se,s,sw,w,nw,up,down */

"tt" is short for "travel table". The entries in the travel table tell where you get to if you travel in each of the 10 directions from here.

Just as the notion of "which room" may be represented by an integer in the travel table entries, an integer may also be used to represent the location of the player. The player is always in some room or other, and a simple integer is used to remember which room he's in.

A word about the room descriptions. You should take care that the descriptions should not contain anything which will not be true throughout the entire game. That is, you should not describe objects which may be moved or change state in some way, or make some assumption about how the player arrived here. For example, A description such as this would be not be good:

You have just narrowly escaped death as your plane crashed into
the jungle.  A path leads to the south and coninues to the north.

This would be fine the first time the player encounters it, but he may be here for the hundredth time, having just come back here by way of the trail, that escaping death bit was days ago. You can use room descriptions such as these if you're prepared to have your program dynamically modify them, but it's usually easier just to sidestep that particular problem than it is to try to plow through it.

Ok, so that covers the first two items on the list. The next node describes how the objects in the game are dealt with.

Previous Top Next

Log in or register to write something here or to contact authors.