1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
4
<title>DM4 §5: Introducing messages and classes</title>
5
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
6
<link rel="stylesheet" type="text/css" href="dm4.css">
10
<a href="index.html">home</a> /
11
<a href="contents.html">contents</a> /
12
<a href="ch2.html" title="Chapter II: Introduction to Designing">chapter II</a> /
13
<a href="s4.html" title="§4: ‘Ruins’ begun">prev</a> /
14
<a href="s6.html" title="§6: Actions and reactions">next</a> /
15
<a href="dm4index.html">index</a>
18
<a id="p92" name="p92"></a>
19
<h2>§5 Introducing messages and classes</h2>
23
A workman that hath copies by, can lay<br>
24
An Europe, Afrique and an Asia,<br>
25
And quickly make that, which was nothing, All.<br>
26
— John Donne (1571?–1631), <i>Valediction: Of Weeping</i>
29
<p class="normal"><span class="atleft"><img src="dm4-092_1.jpg" alt=""></span>
30
Though <a href="s4.html">§4</a> was a little vague
31
in saying “the library asks the mushroom if it would like to react”,
32
something basic was happening in Inform terms: the object
33
<code>InformLibrary</code> was sending the message <code>before</code> to the
34
object <code>mushroom</code>. Much more on how actions take place in
35
<a href="s6.html">§6</a>, but here is roughly what the library does
36
if the player types “eat mushroom”:</p>
38
<p class="lynxonly"></p>
40
if (mushroom.before() == false) {
42
if (mushroom.after() == false)
43
print "You eat the mushroom. Not bad.^";
47
<p class="normal">The library sends the message <code>before</code> to ask the
48
<code>mushroom</code> if it minds being eaten; then, if not, it consumes
49
the mushroom; then it sends the message <code>after</code> to ask if
50
the mushroom wishes to react in some way; then, if not, it prints
51
the usual eating-something text. In response to the messages <code>before</code>
52
and <code>after</code>, the mushroom is expected to reply either <code>true</code>,
53
meaning “I'll take over from here”, or <code>false</code>,
54
meaning “carry on”.</p>
56
<p class="indent">Most of the other properties in
57
<a href="s4.html">§4</a> are also receiving messages.
58
For example, the message</p>
60
<p class="lynxonly"></p>
61
<pre class="code">mushroom.description();</pre>
63
<p class="normal">is sent when the player tries to examine the
64
mushroom: if the reply is <code>false</code> then the library prints
65
“You see nothing special about the speckled mushroom.”
66
Now the mushroom was set up with</p>
68
<p class="lynxonly"></p>
71
"The mushroom is capped with blotches, and you aren't at all
72
sure it's not a toadstool.",
75
<a id="p93" name="p93"></a>
76
<p class="normal">which doesn't look like a rule for receiving a message,
77
but it is one all the same: it means “print this text out, print
78
a new-line and reply <code>true</code>”. A more complicated
79
rule could have been given instead, as in the following elaboration
80
of the stone-cut steps in ‘Ruins’:</p>
82
<p class="lynxonly"></p>
85
print "The cracked and worn steps descend into a dim chamber.
87
if (Square_Chamber hasnt visited)
88
print "be the first feet to tread";
89
else print "have been the first feet to have trodden";
90
" them for five hundred years. On the top step is inscribed
95
<p class="normal"><code>visited</code> is an attribute which is currently held
96
only by rooms which the player has been to. The glyphs will come into
97
the game later on.</p>
99
<p class="indent">The library can send out about 40 different kinds
100
of message, <code>before</code>and <code>description</code> being
101
two of these. The more interesting an object is, the more ingeniously
102
it will respond to these messages. An object which ignores all incoming
103
messages will be lifeless and inert in play, like a small stone.</p>
105
<p class="aside"><span class="warning">▲</span>
106
Some properties are just properties, and don't receive messages.
107
Nobody ever sends a <code>name</code> message, for instance:
108
the <code>name</code> property is just what it seems to be, a list
111
<p class="dotbreak">� � � � �</p>
113
<p class="normal">So the library is sending out messages to your
114
objects all the time during play. Your objects can also send each
115
other messages, including “new” ones that the library
116
would never send. It's sometimes convenient to use these to trigger
117
off happenings in the game. For example, one way to provide hints
118
in ‘Ruins’ might be to include a macaw which squawks
119
from time to time, for a variety of reasons:</p>
121
<p class="lynxonly"></p>
123
Object -> macaw "red-tailed macaw"
124
with name 'red' 'tailed' 'red-tailed' 'macaw' 'bird',
125
initial "A red-tailed macaw eyes you from an upper branch.",
126
description "Beautiful plumage.",
128
Take: "The macaw flutters effortlessly out of reach.";
131
if (self in location)<a id="p94" name="p94"></a>
132
print "The macaw squawks, ~", (string) utterance,
133
"! ", (string) utterance, "!~^^";
138
<p class="normal">(For the final version of ‘Ruins’ the
139
designer thought better of the macaw and removed it, but it still
140
makes a good example.) We might then, for instance, change the <code>after</code>
141
rule for dropping the mushroom to read:</p>
143
<p class="lynxonly"></p>
145
Drop: macaw.squawk("Drop the mushroom");
146
"The mushroom drops to the ground, battered slightly.";
149
<p class="normal">so that the maddening creature would squawk “Drop
150
the mushroom! Drop the mushroom!” each time this was done. At
151
present it would be an error to send a <code>squawk</code> message to any object
152
other than the macaw, since only the macaw has been given a rule
153
telling it what to do if it receives one.</p>
155
<p class="dotbreak">� � � � �</p>
157
<p class="normal">In most games there are groups of objects with
158
certain rules in common, which it would be tiresome to have to write
159
out many times. For making such a group, a class definition is
160
simpler and more elegant. These closely resemble object definitions,
161
but since they define prototypes rather than actual things, they
162
have no initial location. (An individual tree may be somewhere,
163
but the concept of being a tree has no particular place.) So the
164
‘header’ part of the definition is simpler.</p>
166
<p class="indent">For example, the scoring system in ‘Ruins’
167
works as follows: the player, an archaeologist of the old school, gets
168
a certain number of points for each ‘treasure’ (i.e.,
169
cultural artifact) he can filch and put away into his packing case.
170
Treasures clearly have rules in common, and the following class
173
<p class="lynxonly"></p>
176
with cultural_value 5, photographed_in_situ false,
179
if (self in packing_case)
180
"Unpacking such a priceless artifact had best wait
181
until the Carnegie Institution can do it.";
182
if (self.photographed_in_situ == false)
183
"This is the 1930s, not the bad old days. Taking an
184
artifact without recording its context is simply
186
Photograph:<a id="p95" name="p95"></a>
188
"What, and fake the archaeological record?";
189
if (self.photographed_in_situ)
190
"Not again.";
194
if (second == packing_case)
195
{ score = score + self.cultural_value;
196
"Safely packed away.";
198
Photograph: self.photographed_in_situ = true;
202
<p class="normal">(The packing case won't be defined until
203
<a href="s12.html">§12</a>, which is about containers.)
204
Note that <code>self</code> is a variable, which always means
205
“whatever object I am”. If we used it in the definition
206
of the mushroom it would mean the mushroom: used here, it means
207
whatever treasure happens to be being dealt with. Explanations
208
about <code>Insert</code> and <code>Remove</code> will come later
209
(in <a href="s12.html">§12</a>). The action <code>Photograph</code>
210
is not one of the standard actions built in to the library, and will
211
be added to ‘Ruins’ in the next section.</p>
213
<p class="indent">An object of the class <code>Treasure</code> automatically
214
inherits the properties and attributes given in the class definition.
215
Here for instance is an artifact which will eventually be found in
216
the Stooped Corridor of ‘Ruins’:</p>
218
<p class="lynxonly"></p>
220
Treasure -> statuette "pygmy statuette"
221
with name 'snake' 'mayan' 'pygmy' 'spirit' 'precious' 'statuette',
223
"A menacing, almost cartoon-like statuette of a pygmy spirit
224
with a snake around its neck.",
225
initial "A precious Mayan statuette rests here!";
228
<p class="normal">From <code>Treasure</code>, this statuette inherits
229
a <code>cultural_value</code> score of 5 and the rules about taking
230
and dropping treasures. If it had itself set <code>cultural_value</code>
231
to 15, say, then the value would be 15, because the object's actual
232
definition always takes priority over anything the class might have
233
specified. Another of the five ‘Ruins’ treasures, which
234
will be found in the Burial Shaft, has a subtlety in its definition:</p>
236
<p class="lynxonly"></p>
238
Treasure -> honeycomb "ancient honeycomb"
239
with article "an",
240
name 'ancient' 'old' 'honey' 'honeycomb',
241
description "Perhaps some kind of funerary votive offering.",
243
"An exquisitely preserved, ancient honeycomb rests here!",<a id="p96" name="p96"></a>
245
Eat: "Perhaps the most expensive meal of your life.
246
The honey tastes odd, perhaps because it was used to
247
store the entrails of the Lord buried here, but still
253
<p class="normal">The subtlety is that the honeycomb now has two
254
<code>after</code> rules: a new one of its own, plus the existing
255
one that all treasures have. Both apply, but the new one happens
258
<p class="aside"><span class="warning">▲▲</span>
259
So comparing <code>cultural_value</code> and <code>after</code>, there
260
seems to be an inconsistency. In the case of <code>cultural_value</code>,
261
an object's own given value wiped out the value from the class,
262
but in the case of <code>after</code>, the two values were joined
263
up into a list. Why? The reason is that some of the library's properties
264
are “additive”, so that their values accumulate into
265
a list when class inheritance takes place. Three useful examples are
266
<code>before</code>, <code>after</code> and <code>name</code>.</p>
268
<p class="aside"><span class="warning">▲▲</span>
269
Non-library properties you invent (like <code>squawk</code> or
270
<code>cultural_value</code>) will never be additive, unless you declare
271
them so with a directive like</p>
273
<p class="lynxonly"></p>
274
<pre class="code">Property additive squawk;</pre>
276
<p class="aside">before <code>squawk</code> is otherwise mentioned.
277
(Or you could imitate similar kinds of inheritance using the
278
superclass operator.)</p>
280
<p class="aside"><span class="warning"><b>•</b>
281
<b>REFERENCES</b></span><br>
282
See ‘Balances’ for an extensive use of message-sending.
283
The game defines several complicated classes, among them the white
284
cube, spell and scroll classes.
285
<span class="warning"><b>•</b></span>‘Advent’
286
has a treasure-class similar to this one, and uses class definitions
287
for the many similar maze and dead-end rooms, as well as the sides
288
of the fissure.
289
<span class="warning"><b>•</b></span>‘Toyshop’
290
contains one easy class (the wax candles) and one unusually hard one
291
(the building blocks).
292
<span class="warning"><b>•</b></span>Class definitions can be worthwhile
293
even when as few as two objects use them, as can be seen from the two
294
kittens in ‘Alice Through the Looking-Glass’.</p>
298
<a href="index.html">home</a> /
299
<a href="contents.html">contents</a> /
300
<a href="ch2.html" title="Chapter II: Introduction to Designing">chapter II</a> /
301
<a href="s4.html" title="§4: ‘Ruins’ begun">prev</a> /
302
<a href="s6.html" title="§6: Actions and reactions">next</a> /
303
<a href="dm4index.html">index</a>
added
removed
inform-6.31.1/manual/s5.html
