1 <!DOCTYPE HTML PUBLIC
"-//W3O//DTD W3 HTML 2.0//EN">
6 <B>An Introduction to ``The Game''
10 during this entire class
11 will be a relatively simple but fully functional
12 text-based adventure game,
13 patterned roughly after the classic games ADVENT and Zork.
14 If you haven't played one of these games before,
15 the basic idea is that you are an ``actor''
17 (often referred to as a ``dungeon'')
18 consisting of a number of interconnected rooms.
19 You can move from room to room,
20 pick up objects you find lying around
21 (such as keys or swords or C compilers),
22 and use these objects to perform various tasks,
23 such as unlocking doors
26 </p><p>You interact with the game
28 which are simple English sentences.
29 (In our first attempts,
30 the sentences will be very simple indeed,
31 but in sophisticated games of this sort
32 the parsers are quite elaborate
33 and can ``understand'' rather complicated sentences.)
34 The game responds to each command
35 by telling you what you see--a
36 new room you've entered,
37 or the result of some task you've managed to perform.
38 </p><p>Part of the ``fun''
39 (or, at least, the challenge)
41 is just figuring out what commands are acceptable.
43 you move from room to room
44 with the commands ``north'', ``east'',
45 ``west'', and ``south''
46 (which can be abbreviated to ``n'', ``e'',
48 You can pick up objects with the ``take'' command
49 and put them down by saying ``drop''.
50 You can request a description of the room you're in
52 and request a list of your possessions
53 by typing ``inventory''
55 </p><p>(Of course, since you have the source code of this particular game,
56 there's an easy way out of the challenge of discovering
57 which commands it accepts,
58 once you discover the C function which is in charge of
59 matching the commands you type
60 against the list of verbs which the game understands.)
61 </p><p>It might seem as if such a game would be
64 it can actually be quite easy.
66 starting with
<TT>main.c
</TT>,
67 followed by
<TT>commands.c
</TT>,
68 followed by
<TT>object.c
</TT> and
<TT>room.c
</TT>.
69 (All along you'll want to refer to
<TT>game.h
</TT>.)
70 At first it will seem that the the high-level functions
71 are all shirking their responsibilities--it
72 will seem as if they're doing no real work,
73 but rather doing only the easy part
74 and then calling some other function to do the rest.
75 At first, it will seem as if these sub-functions
76 are going to get stuck with all the hard work,
77 but when we get to them,
78 we'll find that they're nicely simple, too.
80 the complexity which we might have imagined the program would contain
81 may seem to melt away before our eyes,
82 as we discover that the program is composed of many functions
83 each of which is quite easy to understand.
90 because attacking a problem in this way--making
91 a hard problem tractable by breaking it up into pieces
92 each of which seems simple
93 but which in concert perform a task
94 which seems harder than the sum of the parts--this
95 process is the essence of good programming.
98 </p><p>The game revolves around three data structures,
99 one describing the player (or ``actor''),
100 one describing a room,
101 and one describing an object.
102 Since the dungeon will typically consist of many rooms,
103 and since there will typically be many objects
104 scattered among the rooms,
105 we'll typically have many instances of the room and object structures.
106 The object structure will contain a ``next'' field,
107 capable of pointing at another object,
108 so that several objects can be strung together
109 as a singly-linked list.
110 We'll use these lists of objects to represent
111 the set of objects sitting in a room,
112 or in an actor's possession.
113 </p><p>Rooms will be linked together, too,
114 but in a more complex way:
115 each room will have up to four pointers
117 These pointers can be thought of as doorways or corridors:
118 the pointed-to room is the room that will be gone to
119 if an actor travels in one of the four compass directions
120 out of the original room.
121 (A room's exits will be stored in an array of four pointers,
122 where element
<TT>[
0]
</TT> is the north exit,
123 <TT>[
1]
</TT> is south,
124 <TT>[
2]
</TT> is east,
125 and
<TT>[
3]
</TT> is west.
126 Also, since pointers are inherently directional,
127 it will be necessary for the linked-to room
128 to have its own pointer back to the original room
129 if the actor is to be able to return.
130 This means that we can create
131 deliberately confusing situations if we wish,
132 such as one-way corridors,
133 or rooms with exits that don't take you back to where you just came from.)
134 </p><p>When linking objects and rooms together,
135 we'll make heavy use of null pointers.
136 The end of a linked list is indicated by a null pointer--that is,
137 the last object in the list
138 has a
<TT>next
</TT> pointer of null.
139 A room with no objects,
140 or an actor with no possessions,
141 will have a null pointer in its
<TT>contents
</TT> field.
142 When a room has a wall instead of a door
143 in one of the four compass directions
144 (that is, when it's impossible to leave a room in a particular direction)
145 that will be indicated by a null pointer
146 in the corresponding cell of the
<TT>exits
</TT> array.