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
Forest
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