-
Notifications
You must be signed in to change notification settings - Fork 0
/
s15.html
221 lines (195 loc) · 10 KB
/
s15.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>DM4 §15: Things to enter, travel in and push around</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="stylesheet" type="text/css" href="dm4.css">
</head>
<body>
<p class="navbar">
<a href="index.html">home</a> /
<a href="contents.html">contents</a> /
<a href="ch3.html" title="Chapter III: The Model World">chapter III</a> /
<a href="s14.html" title="§14: Switchable objects">prev</a> /
<a href="s16.html" title="§16: Reading matter and consultation">next</a> /
<a href="dm4index.html">index</a>
</p>
<div class="page">
<a id="p137" name="p137"></a>
<h2>§15 Things to enter, travel in and push around</h2>
<blockquote>Vehicles were objects that became, in effect, mobile rooms…
The code for the boat itself was not designed to function outside the
river section, but nothing kept the player from carrying the deflated
boat to the reservoir and trying to sail across…<br>
— Tim Anderson, <i>The History of Zork</i></blockquote>
<p class="normal"><span class="atleft"><img src="dm4-137_1.jpg" alt=""></span>
Quite so. Even the case of an entirely static object which can be
climbed into or onto poses problems of realism. Sitting on a garden
roller, is one in the gardens, or not? Can one reasonably reach to
pick up a leaf on the ground? The Inform library leaves most of these
subtleties to the designer but has at least a general concept of
“enterable object”. These have <code>enterable</code> and
the <code>Enter</code> and <code>Exit</code> actions allow the
player to get in (or on) and out (or off) of them.</p>
<p class="indent">Enterable items might include, say, an open-topped car, a
psychiatrist's couch or even a set of manacles attached to a dungeon
wall. In practice, though, manacles are an exceptional case, and
one usually wants to make an <code>enterable</code> thing also a <code>container</code>,
or – as in the case of the altar from ‘Ruins’
which appeared in the previous section – a <code>supporter</code>:</p>
<p class="lynxonly"></p>
<pre class="code">
Object -> stone_table "slab altar"
with name 'stone' 'table' 'slab' 'altar' 'great',
initial "A great stone slab of a table, or altar, dominates the
Shrine.",
has enterable supporter static;
</pre>
<p class="normal">A chair to sit on, or a bed to lie down on, should
also be a <code>supporter</code>.</p>
<p class="indent">Sitting on furniture, one is hardly in a different location altogether.
But suppose the player climbs into a <code>container</code> which is not <code>transparent</code>
and then closes it from the inside? To all intents and purposes this
has become another room. The interior may be dark, but if there's
light to see by, the player will want to see some kind of room description.
In any case, many enterable objects ought to look different from inside
or on top. Inside a vehicle, a player might be able to see a steering
wheel and a dashboard, for instance. On top of a cupboard, it might
be possible to see through a skylight window.</p>
<p class="indent">For this purpose, any <code>enterable</code> object can provide a property called
<code>inside_description</code>, which can hold a string of text or
else a routine to print some text, as usual.
If the exterior location is still visible, then the “inside
description” is appended to the normal room description; if
not, it replaces the
<a id="p138" name="p138"></a>
room description altogether. As an extreme example,
suppose that the player gets into a huge cupboard, closes the door
and then gets into a plastic cabinet inside that. The resulting room
description might read like so:</p>
<p class="output"><em>The huge cupboard (in the plastic cabinet)</em><br>
It's a snug little cupboard in here, almost a room in itself.<br>
In the huge cupboard you can see a pile of clothes.<br>
The plastic walls of the cabinet distort the view.</p>
<p class="normal">The second line is the <code>inside_description</code>
for the huge cupboard, and the fourth is that for the plastic cabinet.</p>
<a id="ex22" name="ex22"></a>
<p class="aside"><span class="warning"><b>•</b>
<b><a href="sa6.html#ans22">EXERCISE 22</a></b></span><br>
(Also from ‘Ruins’.) Implement a cage which can be opened,
closed and entered.</p>
<hr class="section-break" />
<p class="normal">All the classic games have vehicles (like boats,
or fork lift trucks, or hot air balloons) which the player can journey
in, and Inform makes this easy. Here is a simple case:</p>
<p class="lynxonly"></p>
<pre class="code">
Object car "little red car" cave
with name 'little' 'red' 'car',
description "Large enough to sit inside. Among the controls is a
prominent on/off switch. The numberplate is KAR 1.",
when_on
"The red car sits here, its engine still running.",
when_off "A little red car is parked here.",
before [;
Go: if (car has on) "Brmm! Brmm!";
print "(The ignition is off at the moment.)^";
],
has switchable enterable static container open;
</pre>
<p class="normal">Actually, this demonstrates a special rule. If
a player is inside an <code>enterable</code> object and tries to
move, say “north”, the before routine for the object
is called with the action <code>Go n_obj</code>. It may then return:</p>
<p class="output">0 to disallow the movement, printing a refusal;<br>
1 to allow the movement, moving vehicle and player;<br>
2 to disallow but print and do nothing; or<br>
3 to allow but print and do nothing.</p>
<p class="normal">If you want to move the vehicle in your own code,
return 3, not 2: otherwise the old location may be restored by subsequent
workings. Notice that if you write no code, the default value <code>false</code>
will always be returned, so enterable objects won't become
vehicular unless you write them that way.</p>
<a id="p139" name="p139"></a>
<p class="aside"><span class="warning">▲</span>
Because you might want to drive the car “out” of a
garage, the “out” verb does not make the player get out
of the car. Instead the player generally has to type something
like “get out” or “exit” to make this happen.</p>
<a id="ex23" name="ex23"></a>
<p class="aside"><span class="warning"><b>•</b>
<b><a href="sa6.html#ans23">EXERCISE 23</a></b></span><br>
Alter the car so that it will only drive along roads, and not through
all map connections.</p>
<hr class="section-break" />
<p class="normal">Objects like the car or, say, an antiquated wireless
on casters, are too heavy to pick up but the player should at least
be able to push them from place to place. When the player tries to
do this, an action like <code>PushDir wireless</code> is generated.</p>
<p class="indent">Now, if the <code>before</code> routine for the
wireless returns <code>false</code>, the game will just say that
the player can't move the wireless; and if it returns <code>true</code>,
the game will do nothing at all, assuming that the <code>before</code>
routine has already printed something more interesting. So how does
one actually tell Inform that the push should be allowed? The answer
is: first call the <code>AllowPushDir</code> routine (a library
routine), and then return true. For example (‘Ruins’
again), here is a ball on a north-south corridor which slopes upward
at the northern end:</p>
<p class="lynxonly"></p>
<pre class="code">
Object -> huge_ball "huge pumice-stone ball"
with name 'huge' 'pumice' 'pumice-stone' 'stone' 'ball',
description
"A good eight feet across, though fairly lightweight.",
initial
"A huge pumice-stone ball rests here, eight feet wide.",
before [;
PushDir:
if (location == Junction && second == ne_obj)
"The Shrine entrance is far less than eight feet
wide.";
AllowPushDir();
rtrue;
Pull, Push, Turn:
"It wouldn't be so very hard to get rolling.";
Take, Remove:
"There's a lot of stone in an eight-foot sphere.";
],
after [;
PushDir:
if (second == s_obj)
"The ball is hard to stop once underway.";
if (second == n_obj)
"You strain to push the ball uphill.";<a id="p140" name="p140"></a>
],
has static;
</pre>
<a id="ex24" name="ex24"></a>
<p class="aside"><span class="warning"><b>•</b>
<b><a href="sa6.html#ans24">EXERCISE 24</a></b></span><br>
The library does not normally allow pushing objects up or down. How
can the pumice ball allow this?</p>
<p class="aside"><span class="warning"><b>•</b>
<b>REFERENCES</b></span><br>
For an <code>enterable supporter</code> puzzle, see the magic carpet in
‘Balances’ (and several items in ‘Alice Through
the Looking-Glass’).
<span class="warning">•</span>When a vehicle has a sealed
interior large enough to be a location, it is probably best handled
as a location with changing map connections and not as a <code>vehicle</code>
object moved from room to room. See for instance Martin Braun's
<tt>"elevator.inf"</tt> example game, providing an elevator
which serves eight floors of a building.</p>
</div>
<p class="navbar">
<a href="index.html">home</a> /
<a href="contents.html">contents</a> /
<a href="ch3.html" title="Chapter III: The Model World">chapter III</a> /
<a href="s14.html" title="§14: Switchable objects">prev</a> /
<a href="s16.html" title="§16: Reading matter and consultation">next</a> /
<a href="dm4index.html">index</a>
</p>
</body>
</html>