5 ==============================
6 Heidi: our first Inform game
7 ==============================
11 | *E was an esquire, with pride on his brow;*
12 | *F was a farmer, and followed the plough.*
16 .. image:: /images/picE.png
23 ach of the three games in this guide is created step by step; you'll get
24 most benefit (especially to begin with) if you take an active part, typing
25 in the source code on your computer. Our first game, described in this
26 chapter and the two which follow, tells this sentimental little story:
28 "Heidi lives in a tiny cottage deep in the forest. One sunny day,
29 standing before the cottage, she hears the frenzied tweeting of baby
30 bird; its nest has fallen from the tall tree in the clearing! Heidi
31 puts the bird into the nest, and then climbs the tree to place the nest
34 It's a very simple tale, but even so we'll cover quite a lot of ground
35 before we have a finished Inform game. We'll get there in stages, first
36 making a very rough approximation of the story, and then successively
37 refining the details until it's good enough for an initial attempt (there's
38 time later for more advanced stuff).
40 Creating a basic source file
41 ============================
43 The first task is to create an Inform source file template. Every game
44 that we design will start out like this. Follow these steps:
46 #. Create an ``Inform\Games\Heidi`` folder (maybe by copying ``Inform\Games\MyGame1``).
50 In this guide, we use the PC convention of placing a backslash
51 between folder names. On a Macintosh, use a regular slash:
52 ``Inform/Games/Heidi``.
54 #. In that folder, use your text editor to create this source file
57 .. code-block:: inform6
60 !============================================================================
61 Constant Story "Heidi";
63 "^A simple Inform example
64 ^by Roger Firth and Sonja Kesserich.^";
69 !============================================================================
72 !============================================================================
73 ! Entry point routines
77 !============================================================================
78 ! Standard and extended grammar
82 !============================================================================
84 Soon, we'll explain what this means. For now, just type it all in,
85 paying particular attention to those seven semicolons, and ensuring that
86 the double quotes "..." always come in pairs. The first line beginning
87 with "``!%``" is special, and we'll talk about it in a moment; the
88 remaining exclamation mark lines, on the other hand, are purely
89 decorative; they just make the file's structure a little easier to
92 Ensure the file is named ``Heidi.inf``, rather than ``Heidi.txt`` or
95 Remember that, throughout this guide, we place the "TYPE" symbol
96 alongside pieces of code that we recommend you to type into your own
97 game files as you read through the examples (which, conversely, means
98 that you don't need to type the unmarked pieces of code). You'll learn
99 Inform more quickly by trying it for yourself, rather than just taking
100 our word for how things work.
104 Again, revisit the TYPE symbol. Maybe a standard indicator above
107 #. In the same folder, use your text editor to create the compilation
108 support file ``Heidi.bat`` (on a PC)::
110 ..\..\Lib\Base\Inform Heidi
111 +include_path=.\,..\..\Lib\Base,..\..\Lib\Contrib | more
113 pause "at end of compilation"
115 or ``Heidi.command`` (on a Macintosh)::
117 cd ~/Inform/Games/Heidi/
119 ../../Lib/Base/inform30_macosx Heidi
120 +include_path=./,../../Lib/Base,../../Lib/Contrib
122 Remember that there's just one space between "``Heidi``" and
125 Type in the file from scratch, or copy and edit ``MyGame1.bat`` (or
126 ``MyGame1.command``). At this point, you should have a ``Heidi`` folder
127 containing two files: ``Heidi.inf`` and either ``Heidi.bat`` or
130 #. Compile the source file ``Heidi.inf``; refer back to "Inform on an IBM
131 PC (running Microsoft Windows)" on page 19 or "Inform on an Apple
132 Macintosh (running OS X)" on page 24 for guidance. If the compilation
133 works, a story file ``Heidi.z5`` appears in the folder. If the
134 compilation *doesn't* work, you've probably made a typing mistake; check
135 everything until you find it.
137 #. You can run the story file in your Inform interpreter; you should see
138 this (except that the Serial number will be different -- it's based on
141 .. code-block:: transcript
144 A simple Inform example
145 by Roger Firth and Sonja Kesserich.
146 Release 1 / Serial number 040804 / Inform v6.30 Library 6/11 SD
149 It is pitch dark, and you can't see a thing.
153 When you get that far, your template source file is correct. Let's explain
156 Understanding the source file
157 =============================
159 Although we've got a certain amount of freedom of expression, source files
160 tend to conform to a standard overall structure: these lines at the start,
161 that material next, those pieces coming at the end, and so on. What we're
162 doing here is mapping out a structure that suits us, giving ourselves a
163 clear framework onto which the elements of the game can be fitted. Having
164 a clear (albeit sparse) map at the start will help us to keep things
165 organised as the game evolves. We can infer several Inform rules just by
166 looking at the source file.
168 * If the *very first line* (or lines) of the source file begin with the
169 characters "``!%``", then the compiler treats what follows on those lines
170 as control instructions to itself rather than as part of the game's
171 source. The instructions most commonly placed here are compiler
172 switches, a way of controlling detailed aspects of how the compiler
173 operates. These particular switches, two of many, are turning on
174 **Strict mode**, which makes the game less likely to misbehave when being
175 played, and **Debug mode**, which provides some extra commands which can
176 be helpful when tracking down problems.
180 Actually, the ``-S`` is redundant, since Strict mode is already on by
181 default. We include it here as a reminder that (a) to turn Strict
182 mode *off*, you change this setting to ``-~S``, and (b) alphabetic
183 case matters here: ``-s`` causes a display of compiler statistics (and
184 ``-~s`` does nothing at all).
186 * Otherwise, when the compiler comes across an exclamation mark, it ignores
187 the rest of the line. If the ``!`` is at the start of a line, the whole
188 line is ignored; if the ``!`` is halfway along a line, the compiler takes
189 note of the first half, and then ignores the exclamation mark and
190 everything after it on that line. We call material following an
191 exclamation mark, not seen by anybody else, a **comment**; it's often a
192 remark that we write to remind ourselves of how something works or why we
193 tackled a problem in a particular way. There's nothing special about
194 those equals signs: they just produce clear lines across the page.
196 It's always a good idea to comment code as you write it, for later it
197 will help you to understand what was going on at a particular spot.
198 Although it all seems clear in your head when you first write it, in a
199 few months you may suspect that a totally alien mind must have produced
200 that senseless gibberish.
202 By the way, the compiler *doesn't* give special treatment to exclamation
203 marks in quoted text: ``!`` within quotes "..." is treated as a normal
204 character. On this line, the first ``!`` is part of the sequence (or
205 string) of characters to be displayed:
207 .. code-block:: inform6
209 print "Hello world!"; ! <- is the start of this comment
211 * The compiler ignores blank lines, and treats lots of space like a single
212 space (except when the spaces are part of a character string). So, these
213 two rules tell us that we *could* have typed the source file like this:
215 .. code-block:: inform6
217 Constant Story "Heidi";
219 "^A simple Inform example^by Roger Firth and Sonja Kesserich.^";
220 Include "Parser";Include "VerbLib";
224 We didn't type it that way because, though shorter, it's much harder to
225 read. When designing a game, you'll spend a lot of time studying what
226 you've typed, so it's worthwhile taking a bit of care to make it as
227 readable as possible.
229 * Every game should have the **constant** definitions for ``Story`` (the
230 game's name) and ``Headline`` (typically, information on the game's
231 theme, copyright, authorship and so on). These two **string** values,
232 along with a release number and date, and details of the compiler,
233 compose the **banner** which is displayed at the start of each game.
235 * Every game needs the three lines which ``Include`` the standard library
236 files -- that is, they merge those files' contents into your source file:
238 .. code-block:: inform6
245 They always have to be in this order, with ``Parser`` and ``VerbLib``
246 near the start of the file, and ``Grammar`` near the end.
248 * Every game needs to define an ``Initialise`` routine (note the British
251 .. code-block:: inform6
255 The **routine** that we've defined here doesn't do anything useful, but
256 it still needs to be present. Later, we'll come back to ``Initialise``
257 and explain what a routine is and why we need this one.
259 * You'll notice that each of the items mentioned in the previous three
260 rules ends with a semicolon. Inform is very fussy about its punctuation,
261 and gets really upset if you forget a terminating semicolon. In fact,
262 the compiler just keeps reading your source file until it finds one;
263 that's why we were able to take three lines to define the ``Headline``
266 .. code-block:: inform6
269 "^A simple Inform example
270 ^by Roger Firth and Sonja Kesserich.^";
272 Just to repeat what we said earlier: every game that you design will start
273 out from a basic source file like this (in fact, it might be sensible to
274 keep a copy of this template file in a safe place, as a starting point for
275 future games). Think of this stuff as the basic preparation which you'll
276 quickly come to take for granted, much as a landscape artist always begins
277 by sizing the canvas before starting to paint. So, now that we've taken a
278 quick tour of Inform's general needs, we can start thinking about what this
279 particular game requires.
281 Defining the game's locations
282 =============================
284 A good starting point in any game is to think about the locations which are
285 involved: this sketch map shows the four that we'll use:
287 .. image:: /images/heidi1.*
290 In IF, we talk about each of these locations as a **room**, even though in
291 this example none of them has four walls. So let's use Inform to define
292 those rooms. Here's a first attempt:
294 .. code-block:: inform6
296 Object "In front of a cottage"
298 "You stand outside a cottage. The forest stretches east.",
301 Object "Deep in the forest"
303 "Through the dense foliage, you glimpse a building to the west.
304 A track heads to the northeast.",
307 Object "A forest clearing"
309 "A tall sycamore stands in the middle of this clearing.
310 The path winds southwest through the trees.",
313 Object "At the top of the tree"
314 with description "You cling precariously to the trunk.",
317 Again, we can infer some general principles from these four examples:
319 * A room definition starts with the word ``Object`` and ends, about four
320 lines later, with a semicolon. Each of the components that appears in
321 your game -- not only the rooms, but also the people, the things that you
322 see and touch, intangibles like a sound, a smell, a gust of wind -- is
323 defined in this way; think of an "object" simply as the general term for
324 the myriad thingies which together comprise the model world which your
327 * The phrase in double quotes following the word ``Object`` is the name
328 that the interpreter uses to provide the player character with a list of
329 the objects around her: where she is, what she can see, what she's
334 We're using the word "player" to mean both the person who is playing
335 the game, and the principal protagonist (often known as the player
336 character) within the game itself. Since the latter -- Heidi -- is
337 female, we'll refer to the player as "she" while discussing this game.
339 * A keyword ``with`` follows, which simply tells the compiler what to
342 * The word ``description``, introducing another piece of text which gives
343 more detail about the object: in the case of a room, it's the appearance
344 of the surrounding environment when the player character is in that room.
345 The textual description is given in double quotes, and is followed by a
348 * Near the end, the keyword ``has`` appears, which again tells the compiler
349 to expect a certain kind of information.
351 * The word ``light`` says that this object is a source of illumination, and
352 that therefore the player character can see what's happening here. There
353 has to be at least one light source in every room (unless you want the
354 player to be told that "It's pitch dark and you can't see a thing"); most
355 commonly, that light source is the room itself.
357 A smidgeon of background may help set this into context (there's more in
358 the next chapter). An object can have both **properties** (introduced by
359 the keyword ``with``) and **attributes** (written after the word ``has``).
360 A property has both a name (like ``description``) and a value (like the
361 character string "``You stand outside a cottage. The forest stretches
362 east.``"); an attribute has merely a name.
364 In a little while, when you play this game, you'll observe that it starts
367 .. code-block:: transcript
369 In front of a cottage
370 You stand outside a cottage. The forest stretches east.
372 And here you can see how the room's name (``In front of a cottage``) and
373 description (``You stand outside a cottage. The forest stretches east.``)
379 We said that this was a first attempt at defining the rooms; it's fine as
380 far as it goes, but a few bits of information are missing. If you look at
381 the game's sketch map, you can see how the rooms are intended to be
382 connected; from "Deep in the forest", for example, the player character
383 should be able to move west towards the cottage, or northeast to the
384 clearing. Now, although our descriptions mention or imply these available
385 routes, we also need to explicitly add them to the room definitions in a
386 form that the game itself can make sense of. Like this:
388 .. code-block:: inform6
390 Object before_cottage "In front of a cottage"
392 "You stand outside a cottage. The forest stretches east.",
396 Object forest "Deep in the forest"
398 "Through the dense foliage, you glimpse a building to the west.
399 A track heads to the northeast.",
404 Object clearing "A forest clearing"
406 "A tall sycamore stands in the middle of this clearing.
407 The path winds southwest through the trees.",
412 Object top_of_tree "At the top of the tree"
413 with description "You cling precariously to the trunk.",
417 We've made two changes to the room objects.
419 * First, between the word ``Object`` and the object's name in double
420 quotes, we've inserted a different type of name: a private, internal
421 identification, never seen by the player; one that we can use *within*
422 the source file when one object needs to refer to another object. For
423 example, the first room is identified as ``before_cottage``, and the
424 second as ``forest``.
426 Unlike the external name contained in double quotes, the internal
427 identifier has to be a single word -- that is, without spaces. To aid
428 readability, we often use an underscore character to act as sort of
429 pseudo-space: ``before_cottage`` is a bit clearer than ``beforecottage``.
431 * Second, we've added lines after the object descriptions which use those
432 internal identifiers to show how the rooms are connected; one line for
433 each connection. The ``before_cottage`` object has this additional
438 This means that a player standing in front of the cottage can type GO
439 EAST (or EAST, or just E), and the game will transport her to the room
440 whose internal identification is ``forest``. If she tries to move in any
441 other direction from this room, she'll be told "You can't go that way".
443 What we've just defined is a *one-way* easterly connection:
444 ``before_cottage`` → ``forest``. The forest object has two additional
450 The first line defines a westerly connection ``forest`` →
451 ``before_cottage`` (thus enabling the player character to return to the
452 cottage), and the second defines a connection ``forest`` → ``clearing``
453 which heads off to the northeast.
455 Inform provides for eight "horizontal" connections (``n_to``, ``ne_to``,
456 ``e_to``, ``se_to``, ``s_to``, ``sw_to``, ``w_to``, ``nw_to``) two
457 "vertical" ones (``u_to``, ``d_to``) and two specials ``in_to``, and
458 ``out_to``. You'll see some of these used for the remaining inter-room
461 There's one last detail to attend to before we can test what we've done.
462 You'll recollect that our story begins with Heidi standing in front of her
463 cottage. We need to tell the interpreter that ``before_cottage`` is the room
464 where the game starts, and we do this in the ``Initialise`` routine::
466 [ Initialise; location = before_cottage; ];
468 ``location`` is a **variable**, part of the library, which tells the
469 interpreter in which room the player character currently is. Here, we're
470 saying that, at the start of the game, the player character is in the
471 ``before_cottage`` room.
473 Now we can add what we've done to the ``Heidi.inf`` source file template.
474 At this stage, you should study the four room definitions, comparing them
475 with the sketch map until you're comfortable that you understand how to
476 create simple rooms and define the connections between them.
478 .. code-block:: inform6
480 !============================================================================
481 Constant Story "Heidi";
483 "^A simple Inform example
484 ^by Roger Firth and Sonja Kesserich.^";
489 !============================================================================
492 Object before_cottage "In front of a cottage"
494 "You stand outside a cottage. The forest stretches east.",
498 Object forest "Deep in the forest"
500 "Through the dense foliage, you glimpse a building to the west.
501 A track heads to the northeast.",
506 Object clearing "A forest clearing"
508 "A tall sycamore stands in the middle of this clearing.
509 The path winds southwest through the trees.",
514 Object top_of_tree "At the top of the tree"
515 with description "You cling precariously to the trunk.",
519 !============================================================================
520 ! Entry point routines
522 [ Initialise; location = before_cottage; ];
524 !============================================================================
525 ! Standard and extended grammar
529 !============================================================================
531 Type this in, as always taking great care with the punctuation -- watch
532 those commas and semicolons. Compile it, and fix any mistakes which the
533 compiler reports. You can then play the game in its current state.
534 Admittedly, you can't do very much, but you should be able to move freely
535 among the four rooms that you've defined.
539 In order to minimise the amount of typing that you have to do, the
540 descriptive text in this game has been kept as short as possible. In a
541 real game, you would typically provide more interesting descriptions
544 Adding the bird and the nest
545 ============================
547 Given what we said earlier, you won't be surprised to hear that both the
548 bird and its nest are Inform objects. We'll start their definitions like
551 .. code-block:: inform6
553 Object bird "baby bird"
554 with description "Too young to fly, the nestling tweets helplessly.",
557 Object nest "bird's nest"
558 with description "The nest is carefully woven of twigs and moss.",
561 You can see that these definitions have exactly the same format as the
562 rooms we defined previously: a one-word internal identifier (``bird``,
563 ``nest``), and a word or phrase naming the object for the player's benefit
564 (``baby bird``, ``bird's nest``). They both have some descriptive detail:
565 for a room this is printed when the player first enters, or when she types
566 LOOK; for other objects it's printed when she EXAMINEs that object. What
567 they *don't* have are connections (``e_to``, ``w_to``, etc. apply only to
568 rooms) or ``light`` (it's not necessary -- the rooms ensure that light is
571 When the game is running, the player will want to refer to these two
572 objects, saying for instance EXAMINE THE BABY BIRD or PICK UP THE NEST.
573 For this to work reliably, we need to specify the word (or words) which
574 relate to each object. Our aim here is flexibility: providing a choice of
575 relevant vocabulary so that the player can use whatever term seems
576 appropriate to her, with a good chance of it being understood. We add a
577 line to each definition:
579 .. code-block:: inform6
581 Object bird "baby bird"
582 with description "Too young to fly, the nestling tweets helplessly.",
583 name 'baby' 'bird' 'nestling',
586 Object nest "bird's nest"
587 with description "The nest is carefully woven of twigs and moss.",
588 name 'bird^s' 'nest' 'twigs' 'moss',
591 The ``name`` introduces a list in single quotes '...'. We call each of
592 those quoted things a **dictionary word**, and we do mean "word", not
593 "phrase" (``'baby'``\ ``'bird'`` rather than ``'baby bird'``); you can't
594 uses spaces, commas or periods in dictionary words, though there's a space
595 *between* each one, and the whole list ends with a comma. The idea is that
596 the interpreter decides which object a player is talking about by matching
597 what she types against the full set of all dictionary words. If the player
598 mentions BIRD, or BABY BIRD, or NESTLING, it's the ``baby bird`` that she
599 means; if she mentions NEST, BIRD'S NEST or MOSS, it's the ``bird's nest``.
600 And if she types NEST BABY or BIRD TWIGS, the interpreter will politely say
601 that it doesn't understand what on earth she's talking about.
605 You'll notice the use of ``'bird^s'`` to define the dictionary word
606 BIRD'S; this oddity is necessary because the compiler expects the single
607 quotes in the list always to come in pairs -- one at the start of the
608 dictionary word, and one at the end. If we had typed ``'bird's'`` then
609 the compiler would find the opening quote, the four letters ``b``,
610 ``i``, ``r`` and ``d``, and what looks like the closing quote. So far
611 so good; it's read the word BIRD and now expects a space before the next
612 opening quote... but instead finds ``s'`` which makes no sense. In
613 cases like this we must use the circumflex ``^`` to *represent* the
614 apostrophe, and the compiler then treats ``bird's`` as a dictionary
617 You may be wondering why we need a list of ``name`` words for the bird and
618 its nest, yet we didn't when we defined the rooms? It's because the player
619 can't interact with a room in the same way as with other objects; for
620 example, she doesn't need to say EXAMINE THE FOREST -- just being there and
621 typing LOOK is sufficient.
623 The bird's definition is complete, but there's an additional complexity
624 with the nest: we need to be able to put the bird into it. We do this by
625 labelling the nest as a ``container`` -- able to hold other objects -- so
626 that the player can type PUT (or INSERT) BIRD IN (or INTO) NEST.
627 Furthermore, we label it as ``open``; this prevents the interpreter from
628 asking us to open it before putting in the bird.
630 .. code-block:: inform6
632 Object nest "bird's nest"
633 with description "The nest is carefully woven of twigs and moss.",
634 name 'bird^s' 'nest' 'twigs' 'moss',
637 Both objects are now defined, and we can incorporate them into the game.
638 To do this, we need to choose the locations where the player will find
639 them. Let's say that the bird is found in the forest, while the nest is in
640 the clearing. This is how we set this up:
642 .. code-block:: inform6
644 Object bird "baby bird" forest
645 with description "Too young to fly, the nestling tweets helplessly.",
646 name 'baby' 'bird' 'nestling',
649 Object nest "bird's nest" clearing
650 with description "The nest is carefully woven of twigs and moss.",
651 name 'bird^s' 'nest' 'twigs' 'moss',
654 Read that first line as: "Here's the definition of an object which is
655 identified within this file as ``bird``, which is known to the player as
656 ``baby bird``, and which is initially located inside the object identified
657 within this file as ``forest``."
659 Where in the source file do these new objects fit? Well, anywhere really,
660 but you'll find it convenient to insert them following the rooms where
661 they're found. This means adding the bird just after the forest, and the
662 nest just after the clearing. Here's the middle piece of the source file:
664 .. code-block:: inform6
666 !============================================================================
669 Object before_cottage "In front of a cottage"
671 "You stand outside a cottage. The forest stretches east.",
675 Object forest "Deep in the forest"
677 "Through the dense foliage, you glimpse a building to the west.
678 A track heads to the northeast.",
683 Object bird "baby bird" forest
684 with description "Too young to fly, the nestling tweets helplessly.",
685 name 'baby' 'bird' 'nestling',
688 Object clearing "A forest clearing"
690 "A tall sycamore stands in the middle of this clearing.
691 The path winds southwest through the trees.",
696 Object nest "bird's nest" clearing
697 with description "The nest is carefully woven of twigs and moss.",
698 name 'bird^s' 'nest' 'twigs' 'moss',
701 Object top_of_tree "At the top of the tree"
702 with description "You cling precariously to the trunk.",
706 !============================================================================
708 Make those changes, recompile the game, play it and you'll see this:
710 .. code-block:: transcript
713 Through the dense foliage, you glimpse a building to the west. A track heads
716 You can see a baby bird here.
720 Adding the tree and the branch
721 ==============================
723 The description of the clearing mentions a tall sycamore tree, up which the
724 player character supposedly "climbs". We'd better define it:
726 .. code-block:: inform6
728 Object tree "tall sycamore tree" clearing
730 "Standing proud in the middle of the clearing,
731 the stout tree looks easy to climb.",
732 name 'tall' 'sycamore' 'tree' 'stout' 'proud',
735 Everything there should be familiar, apart from that ``scenery`` at the
736 end. We've already mentioned the tree in the description of the forest
737 clearing, so we don't want the interpreter adding "You can see a tall
738 sycamore tree here" afterwards, as it does for the bird and the nest. By
739 labelling the tree as ``scenery`` we suppress that, and also prevent it
740 from being picked up by the player character. One final object: the branch
741 at the top of the tree. Again, not many surprises in this definition:
743 .. code-block:: inform6
745 Object branch "wide firm bough" top_of_tree
746 with description "It's flat enough to support a small object.",
747 name 'wide' 'firm' 'flat' 'bough' 'branch',
748 has static supporter;
750 The only new things are those two labels. ``static`` is similar to
751 ``scenery``: it prevents the branch from being picked up by the player
752 character, but *doesn't* suppress mention of it when describing the
753 setting. And ``supporter`` is rather like the ``container`` that we used
754 for the nest, except that this time the player character can put other
755 objects *onto* the branch. (In passing, we'll mention that an object can't
756 normally be both a ``container`` and a ``supporter``.) And so here are our
759 .. code-block:: inform6
761 !============================================================================
764 Object before_cottage "In front of a cottage"
766 "You stand outside a cottage. The forest stretches east.",
770 Object forest "Deep in the forest"
772 "Through the dense foliage, you glimpse a building to the west.
773 A track heads to the northeast.",
778 Object bird "baby bird" forest
779 with description "Too young to fly, the nestling tweets helplessly.",
780 name 'baby' 'bird' 'nestling',
783 Object clearing "A forest clearing"
785 "A tall sycamore stands in the middle of this clearing.
786 The path winds southwest through the trees.",
791 Object nest "bird's nest" clearing
792 with description "The nest is carefully woven of twigs and moss.",
793 name 'bird^s' 'nest' 'twigs' 'moss',
796 Object tree "tall sycamore tree" clearing
798 "Standing proud in the middle of the clearing,
799 the stout tree looks easy to climb.",
800 name 'tall' 'sycamore' 'tree' 'stout' 'proud',
803 Object top_of_tree "At the top of the tree"
804 with description "You cling precariously to the trunk.",
808 Object branch "wide firm bough" top_of_tree
809 with description "It's flat enough to support a small object.",
810 name 'wide' 'firm' 'flat' 'bough' 'branch',
811 has static supporter;
813 !============================================================================
815 Once again, make the changes, recompile, and investigate what you can do in
821 Our first pass at the game is nearly done; just two more changes to
822 describe. The first is easy: Heidi wouldn't be able to climb the tree
823 carrying the bird and the nest separately: we want the player character to
824 put the bird into the nest first. One easy way to enforce this is by
825 adding a line near the top of the file:
827 .. code-block:: inform6
829 !============================================================================
830 Constant Story "Heidi";
832 "^A simple Inform example
833 ^by Roger Firth and Sonja Kesserich.^";
835 Constant MAX_CARRIED 1;
837 The value of ``MAX_CARRIED`` limits the number of objects that the player
838 character can be holding at any one time; by setting it to 1, we're saying
839 that she can carry the bird or the nest, but not both. However, the limit
840 ignores the contents of ``container`` or ``supporter`` objects, so the nest
841 with the bird inside it is still counted as one object.
843 The other change is slightly more complex and more important: there's
844 currently no way to "win" the game! The goal is for the player character
845 to put the bird in the nest, take the nest to the top of the tree, and
846 place it on the branch; when that happens, the game should be over. This
847 is one way of making it happen:
849 .. code-block:: inform6
851 Object branch "wide firm bough" top_of_tree
852 with description "It's flat enough to support a small object.",
853 name 'wide' 'firm' 'flat' 'bough' 'branch',
854 each_turn [; if (nest in branch) deadflag = 2; ],
855 has static supporter;
859 Here's an explanation of what's going on. If you find this difficult to
860 grasp, don't worry. It's the hardest bit so far, and it introduces
861 several new concepts all at once. Later in the guide, we'll explain
862 those concepts more clearly, so you can just skip this bit if you want.
864 The variable ``deadflag``, part of the library, is normally 0. If you set
865 its value to 2, the interpreter notices and ends the game with "You have
866 won". The statement::
868 if (nest in branch) deadflag = 2;
870 should be read as: "Test whether the ``nest`` is currently in the
871 ``branch`` (if the branch is a ``container``) or on it (if the
872 ``branch`` is a supporter); if it is, set the value of ``deadflag`` to
873 2; if it isn't, do nothing." The surrounding part::
877 should be read as: "At the end of each turn (when the player is in the
878 same room as the branch), do whatever is written inside the square
879 brackets". So, putting that all together:
881 * At the end of each turn (after the player has typed something and
882 pressed the Enter key, and the interpreter has done whatever was
883 requested) the interpreter checks whether the player and the
884 ``branch`` are in the same room. If not, nothing happens. If they're
885 together, it looks to see where the nest is. Initially it's in the
886 ``clearing``, so nothing happens.
888 * Also at the end of each turn, the interpreter checks the value of
889 ``deadflag``. Usually it's 0, so nothing happens.
891 * Finally the player character puts the ``nest`` on the ``branch``.
892 "Aha!" says the interpreter (to itself, of course), and sets the
893 value of ``deadflag`` to 2.
895 * Immediately afterwards, (another part of) the interpreter checks and
896 finds that the value of ``deadflag`` has changed to 2, which means
897 that the game is successfully completed; so, it says to the player,
900 That's as far as we'll take this example for now. Make those final
901 changes, recompile, and test what you've achieved. You'll probably find a
902 few things that could be done better -- even on a simple game like this
903 there's considerable scope for improvement -- so we'll revisit Heidi in her
904 forest shortly. First, though, we'll recap what we've learnt so far.