1
<HTML><HEAD><TITLE>Section 7: Getting started</TITLE></HEAD>
2
<BODY BGCOLOR="#FFFFFF">
4
<TR><TD Valign="top"><A HREF="contents.html">Contents</A><BR><A HREF="chapter3.html">Back</A><BR><A HREF="section8.html">Forward</A><TD bgcolor="#F5DEB3"><BLOCKQUOTE><H3>7. Getting started</H3></BLOCKQUOTE><TR><TD><TD>
8
<BR>Nothing so difficult as a beginning
9
<BR>In poesy, unless perhaps the end.
10
<BR><P>...Lord Byron (<B>1788</B>--<B>1824</B>), <I>Don Juan, IV iv</I></BLOCKQUOTE>
14
The examples in Chapters III and IV of this manual will put together
15
a small game called 'Ruins'. Its first state is very close to
16
the minimal 'Shell' game supplied with Inform:
18
Constant Story "RUINS";
19
Constant Headline "^An Interactive Worked Example^
20
Copyright (c) 1995 by Graham Nelson.^";
25
Object Forest "Dark Forest"
27
"In this tiny clearing, the pine-needle carpet is broken by
28
stone-cut steps leading down into darkness. Dark olive
29
trees crowd in on all sides, the air steams with warm recent
30
rain, midges hang in the air.",
35
"^^^^^Days of searching, days of thirsty hacking through the briars of
36
the forest, but at last your patience was rewarded. A discovery!^";
43
If you can compile this successfully, Inform is probably set up and working
44
properly on your computer. Compilation may take a few seconds, because the
45
game 'includes' three library files which contain a great deal more code.
46
These files are themselves written in Inform
47
and contain the core of ordinary rules common to all games:
49
<BR><TABLE Border><TR><TD> <TT>Parser</TT> <TD> a program for decoding what the player types;
50
<TR><TD> <TT>VerbLib</TT> <TD> how verbs, like "take'' or "drop'', work;
51
<TR><TD> <TT>Grammar</TT> <TD> the grammar table, or what the Parser understands.
53
(If compilation is annoyingly slow, it should be easy enough to "link the
54
library files'', which is much faster: see <A HREF="section4.html">Section 4</A>.3) Apart from the
55
inclusions, 'Ruins' contains:
57
<P>(a) -- strings (that is, quoted text) giving the game's name and a
58
copyright message, to be printed out when appropriate;
59
<P>(b) -- a routine, called <TT>Initialise</TT>, which is run when the game begins,
60
and simply sets where the player starts (not that there's much choice yet!)
61
and prints a 'welcome' message;
62
<P>(c) -- an object, so far the only room.
64
<P> 'Ruins' is at this stage an extremely dull game:
66
Days of searching, days of thirsty hacking through the briars of the forest,
67
but at last your patience was rewarded. A discovery!
70
An Interactive Worked Example
71
Copyright (c) 1995 by Graham Nelson.
72
Release 1 / Serial number 960825 / Inform v6.04 Library 6/1
75
In this tiny clearing, the pine-needle carpet is broken by stone-cut steps
76
leading down into darkness. Dark olive trees crowd in on all sides, the air
77
steams with warm recent rain, midges hang in the air.
80
You are carrying nothing.
83
You can't go that way.
89
Are you sure you want to quit? yes
92
<P> (The "Release'' number is 1 unless you set it otherwise,
93
putting a directive like <TT>Release 2;</TT> into the source code. The
94
"Serial number'' is set by Inform to the date of compilation.)
98
In an Inform game, objects are used to simulate everything: rooms and
99
items to be picked up, scenery, intangible things like mist and even
100
some abstract ideas (like the direction 'north'). The library is
101
also present in every game, and can be thought of as a referee, or
102
umpire, rather than part of the game's world.
105
Our second object is added by writing the following just after the
106
<TT>Forest</TT> ends and just before <TT>Initialise</TT> begins:
109
Object -> mushroom "speckled mushroom"
110
with name "speckled" "mushroom" "fungus" "toadstool";
113
(The arrow <TT>-></TT> means that the mushroom begins inside the Forest
114
rather than alongside it.) If the game is recompiled, the mushroom
115
is now in play: the player can call it "speckled mushroom'',
116
"mushroom'', "toadstool'' and so on. It can be taken, dropped,
117
looked at, looked under and so on. However, it only adds the rather
118
plain line "There is a speckled mushroom here.'' to the Forest's
119
description. So here is a more lavish version:
121
Object -> mushroom "speckled mushroom"
122
with name "speckled" "mushroom" "fungus" "toadstool",
124
"A speckled mushroom grows out of the sodden earth, on a long stalk.";
127
The <TT>initial</TT> message is used to tell the player about the mushroom when
128
the Forest is described. (Once the mushroom has been picked or moved, the
129
message is no longer used: hence the name 'initial'.) The mushroom is,
130
however, still "nothing special'' when the player asks to "look at'' or
131
"examine'' it. To provide a more interesting close-up view, we must give
132
the mushroom its own <TT>description</TT>:
134
Object -> mushroom "speckled mushroom"
135
with name "speckled" "mushroom" "fungus" "toadstool",
137
"A speckled mushroom grows out of the sodden earth, on a long stalk.",
139
"The mushroom is capped with blotches, and you aren't at all sure
140
it's not a toadstool.",
144
Now if we examine the mushroom, as is always wise before eating, we get a
145
cautionary hint; still, thanks to the <TT>edible</TT> notation, we're now able
149
These show the two kinds of feature something can have: a "property'',
150
which has some definite value or list of values (such as <TT>name</TT>), and
151
an "attribute'', which is either present or not but has no particular
152
value (such as <TT>edible</TT>). Values of properties change during play,
153
and attributes come and go. For instance,
155
mushroom.description = "You're sure it's a toadstool now.";
156
give mushroom general;
157
if (mushroom has edible) print "It's definitely edible.^";
160
manipulate the attributes and properties. (<TT>general</TT> is the name used
161
for an attribute with no particular meaning to the game, but which is
162
left free for your program to use as it likes. Similarly, <TT>number</TT>
163
is a general-purpose property.)
166
We can go much further with form-filling like this, but for the sake of
167
example we'll begin some honest programming by adding the following
168
property to the mushroom:
171
[; Take: "You pick the mushroom, neatly cleaving its thin stalk.";
172
Drop: "The mushroom drops to the ground, battered slightly.";
176
The property <TT>after</TT> doesn't just have a string for a value: it has a
177
routine of its own. Now after something happens to the mushroom,
178
the <TT>after</TT> routine is called to see if any special rules apply. In this
179
case, <TT>Take</TT> and <TT>Drop</TT> are the only actions tampered with, and the only
180
effect is that the usual messages ("Taken.'' "Dropped.'') are replaced.
181
The game can now manage a brief but plausible dialogue:
184
In this tiny clearing, the pine-needle carpet is broken by stone-cut steps
185
leading down into darkness. Dark olive trees crowd in on all sides, the air
186
steams with warm recent rain, midges hang in the air.
187
A speckled mushroom grows out of the sodden earth, on a long stalk.
189
You pick the mushroom, neatly cleaving its thin stalk.
191
The mushroom is capped with blotches, and you aren't at all sure it's not a
194
The mushroom drops to the ground, battered slightly.
197
The mushroom is a little more convincing now, but still passive.
198
We can give it a somewhat sad new rule by adding yet another property,
199
this time with a more substantial routine:
202
[; Eat: if (random(100) <= 30)
204
"The tiniest nibble is enough. It was a toadstool,
205
and a poisoned one at that!";
207
"You nibble at one corner, but the curious taste repels you.";
211
The <TT>before</TT> routine is called before the player's intended action takes
212
place. So when the player tries typing, say, "eat the mushroom", what happens
213
is: in 30% of cases, she dies of toadstool poisoning; and in the other
214
70%, she simply nibbles a corner of fungus (without consuming it
218
<P><TR><TD Valign="top"><IMG SRC="icons/dbend.gif" ALT="/\"><TD bgcolor="#EEEEEE"><SMALL> Like many programming languages, Inform braces together blocks of
219
code so that several statements can come under the <TT>if</TT> condition.
220
<TT>deadflag</TT> is a global variable, whose value does not belong to any
221
particular object (or routine). It is defined somewhere in the depths of
222
the library: it's usually 0; setting it to 1 causes the game to be lost,
223
and setting it to 2 causes a win.
227
Note that if the first text is printed, the rule ends there, and does
228
not flow on into the second text. So one and only one message is printed.
229
Here is how this is achieved: although it's not obvious from the look of
230
the program, the <TT>before</TT> routine is being asked the question
231
"Do you want to interfere with the usual rules?''. It must reply,
232
that is, "return'', either "true'' or "false'' meaning yes or no.
233
Because this question is asked and answered many times in a large Inform
234
game, there are several abbreviations for how to reply. For example,
240
both do the same thing. Moreover,
242
print_ret "The tiniest nibble... ...at that!";
245
performs three useful tasks: prints the message, then prints a carriage
246
return, and then returns true. And this is so useful that a bare string
248
"The tiniest nibble... ...at that!";
252
is understood to mean the same thing. To just print the text, the
253
statement <TT>print</TT> has to be written out in full. Here is an example:
256
[; Taste: print "You extend your tongue nervously.^";
261
In this rule, the text is printed, but the answer to "Do you want
262
to interfere?'' is no, so the game will then go on to print something
263
anodyne like "You taste nothing unexpected.'' (In fact the <TT>rfalse</TT>
264
was unnecessary, because if a rule like this never makes any
265
decision, then the answer is assumed to be "false''.)
268
<P><TR><TD Valign="top"><IMG SRC="icons/exercise.gif" ALT="??"><TD bgcolor="#FBB9AC"><A NAME="ex1"><B>EXERCISE 1:</B><BR>(link to <A HREF="answers1/answer1.html">the answer</A>)<TR><TD><TD> The present <TT>after</TT> routine for the mushroom is misleading,
269
because it says the mushroom has been picked every time it's taken (which
270
will be odd if it's taken, dropped then taken again). Correct this to
271
complete the definition of the 'Ruins'
275
<P><TR><TD Valign="top"><IMG SRC="icons/dbend.gif" ALT="/\"><TD bgcolor="#EEEEEE"><SMALL> More generally, some <TT>before</TT> or <TT>after</TT> rules ought to apply only
276
once in the course of a game. For instance, examining the tapestry reveals
277
a key, only once. A sneaky way to do this is to make the appropriate rule
278
destroy itself, so for example
280
tapestry.before = NULL;
283
removes the entire <TT>before</TT> rule for the tapestry. <TT>NULL</TT> is a special
284
value, which the properties <TT>before</TT>, <TT>after</TT>, <TT>life</TT> and <TT>describe</TT>
285
hold to indicate "none''.
290
Here is another typical object definition:
292
Object "stone-cut steps" Forest
293
with name "steps" "stone" "stairs" "stone-cut",
295
"The cracked and worn steps descend into a dim chamber. Yours
296
might be the first feet to tread them for five hundred years.",
297
door_to Square_Chamber,
299
has scenery door open;
302
This is the conventional way to lay out an <TT>Object</TT> declaration: with the
303
header first, then <TT>with</TT> a list of properties and their starting values,
304
finishing up with the attributes it initially <TT>has</TT>. (Though <TT>with</TT> and
305
<TT>has</TT> can be given the other way round.)
309
Note that the first line, the so-called header, is a little different
310
in form to those above. Firstly, it gives no "program name'' for the
311
steps (in the way that <TT>mushroom</TT> was given as program-name for the
312
speckled mushroom) -- there is a blank in between the <TT>Object</TT> directive
313
and the text of the words "short-cut steps''. This is perfectly legal,
314
and is sensible because the program never needs to refer to the steps
315
object directly. Secondly, the initial position of the steps is specified
316
not by using arrows <TT>-></TT> but by actually quoting the object it is to
317
be placed inside, the <TT>Forest</TT>. This is sometimes convenient and is only
318
legal if the <TT>Forest</TT> has already been defined (earlier on in the
319
program). Such a restriction is actually useful as it prevents you from
320
setting up a 'loop' -- one object in another in a third in the first,
324
<HR><A HREF="contents.html">Contents</A> / <A HREF="chapter3.html">Back</A> / <A HREF="section8.html">Forward</A> <BR>
325
<A HREF="chapter1.html">Chapter I</A> / <A HREF="chapter2.html">Chapter II</A> / <A HREF="chapter3.html">Chapter III</A> / <A HREF="chapter4.html">Chapter IV</A> / <A HREF="chapter5.html">Chapter V</A> / <A HREF="chapter6.html">Chapter VI</A> / <A HREF="chapterA.html">Appendix</A><HR><SMALL><I>Mechanically translated to HTML from third edition as revised 16 May 1997. Copyright © Graham Nelson 1993, 1994, 1995, 1996, 1997: all rights reserved.</I></SMALL></BODY></HTML>
added
removed
html/section7.html
