appendices/c.rst

   1 ======================================
   2  Appendix C -- "William Tell" story
   3 ======================================
   4
   5 .. only:: html
   6
   7   .. image:: /images/picW.png
   8      :align: left
   9
  10 .. raw:: latex
  11
  12     \dropcap{w}
  13
  14 illiam Tell, our second game, is also very straightforward. See "William
  15 Tell: a tale is born" on page 69, "William Tell: the early years" on
  16 page 79, "William Tell: in his prime" on page 91 and "William Tell: the
  17 end is nigh" on page 103.
  18
  19 Transcript of play
  20 ==================
  21
  22 .. literalinclude:: /examples/Tell.txt
  23    :language: transcript
  24
  25 Game source code
  26 ================
  27
  28 .. literalinclude:: /examples/Tell.inf
  29    :language: inform6
  30
  31 Compile-as-you-go
  32 =================
  33
  34 Your understanding of how the "William Tell" game works will be
  35 considerably enhanced if you type in the code for yourself as you read
  36 through the guide. However, it takes us four chapters to describe the
  37 game, which isn't complete and playable until the end of Chapter 9. Even
  38 if you make no mistakes in your typing, the game won't compile without
  39 errors before that point, because of references in earlier chapters to
  40 objects which aren't presented until later chapters (for example,
  41 Chapter 6 mentions the ``bow`` and ``quiver`` objects, but we don't
  42 define them until Chapter 7). This is a bit of a nuisance, because as a
  43 general rule we advise you to compile frequently -- more or less after
  44 every change you make to a game -- in order to detect syntax and
  45 spelling mistakes as soon as possible.
  46
  47 Fortunately, there's a fairly easy way round the difficulty, though it
  48 involves a little bit of cheating. The trick is temporarily to add
  49 minimal definitions -- often called "stubs" -- of the objects whose full
  50 definitions have yet to be provided.
  51
  52 For example, if you try to compile the game in the state that it's
  53 reached by the end of Chapter 6, you’ll get this::
  54
  55         Tell.inf(16): Warning: Class "Room" declared but not used
  56         Tell.inf(19): Warning: Class "Prop" declared but not used
  57         Tell.inf(27): Warning: Class "Furniture" declared but not used
  58         Tell.inf(44): Error: No such constant as "street"
  59         Tell.inf(46): Error: No such constant as "bow"
  60         Tell.inf(47): Error: No such constant as "quiver"
  61         Compiled with 3 errors and 3 warnings
  62
  63 However, by adding these lines to the end of your game file::
  64
  65         ! ===============================================================
  66         ! TEMPORARY DEFINITIONS NEEDED TO COMPILE AT THE END OF CHAPTER 6
  67
  68         Room    street;
  69         Object  bow;
  70         Object  quiver;
  71
  72 a compilation should now give only this::
  73
  74         Tell.inf(19): Warning: Class "Prop" declared but not used
  75         Tell.inf(27): Warning: Class "Furniture" declared but not used
  76         Compiled with 2 warnings
  77
  78 That's a lot better. It's not worth worrying about those warnings, since
  79 it's easy to understand where they come from; anyway, they'll go away
  80 shortly. More important, there are no errors, which means that you've
  81 probably not made any major typing mistakes. It also means that the
  82 compiler has created a story file, so you can try "playing" the game. If
  83 you do, though, you'll get this::
  84
  85         William Tell
  86         A simple Inform example
  87         by Roger Firth and Sonja Kesserich.
  88         Release 3 / Serial number 040804 / Inform v6.30 Library 6/11 SD
  89
  90         (street)
  91         ** Library error 11 (27,0) **
  92         ** The room "(street)" has no "description" property **
  93         >
  94
  95 Whoops! We've fallen foul of Inform's rule saying that every room must
  96 have a ``description`` property, to be displayed by the interpreter when
  97 you enter that room. Our ``street`` stub hasn't got a ``description``,
  98 so although the game compiles successfully, it still causes an error to
  99 be reported at run-time.
 100
 101 The best way round this is to extend the definition of our ``Room``
 102 class, thus::
 103
 104         Class  Room
 105           with description "UNDER CONSTRUCTION",
 106           has  light;
 107
 108 By doing this, we ensure that *every* room has a description of some
 109 form; normally we'd override this default value with something
 110 meaningful -- "The narrow street runs north towards the town square..."
 111 and so on -- by including a ``description`` property in the object's
 112 definition. However, in a stub object used only for testing, a default
 113 description is sufficient (and less trouble)::
 114
 115         William Tell
 116         A simple Inform example
 117         by Roger Firth and Sonja Kesserich.
 118         Release 3 / Serial number 040804 / Inform v6.30 Library 6/11 SD
 119
 120         (street)
 121         UNDER CONSTRUCTION
 122
 123         >INVENTORY
 124         You are carrying:
 125           a (quiver) (being worn)
 126           a (bow)
 127
 128         >EXAMINE QUIVER
 129         You can't see any such thing.
 130
 131         >
 132
 133 You'll notice a couple of interesting points. Because we didn't supply
 134 external names with our ``street`` , ``bow`` and ``quiver`` stubs, the
 135 compiler has provided some for us -- ``(street)`` , ``(bow)`` and
 136 ``(quiver)`` -- simply by adding parentheses around the internal IDs
 137 which we used. And, because our ``bow`` and ``quiver`` stubs have no
 138 ``name`` properties, we can't actually refer to those objects when
 139 playing the game. Neither of these points would be acceptable in a
 140 finished game, but for testing purposes at this early stage -- they'll
 141 do.
 142
 143 So far, we've seen how the addition of three temporary object
 144 definitions enables us to compile the incomplete game, in its state at
 145 the end of Chapter 6. But once we reach the end of Chapter 7, things
 146 have moved on, and we now need a different set of stub objects. For a
 147 test compilation at this point, remove the previous set of stubs, and
 148 instead add these -- ``south_square`` and ``apple`` objects, and a dummy
 149 action handler to satisfy the ``Talk`` action in Helga’s life property::
 150
 151         ! ===============================================================
 152         ! TEMPORARY DEFINITIONS NEEDED TO COMPILE AT THE END OF CHAPTER 7
 153
 154         Room    south_square;
 155         Object  apple;
 156
 157         [ TalkSub; ];
 158
 159 Similarly, at the end of Chapter 8, replace the previous stubs by these
 160 if you wish to check that the game compiles::
 161
 162         ! ===============================================================
 163         ! TEMPORARY DEFINITIONS NEEDED TO COMPILE AT THE END OF CHAPTER 8
 164         Room    marketplace;
 165         Object  apple;
 166         NPC     son;
 167
 168         [ TalkSub; ];
 169         [ FireAtSub; ];
 170         [ SaluteSub; ];
 171
 172 Finally, by the end of Chapter 9 the game is complete, so you can delete
 173 the stubs altogether.
 174
 175 Used with care, this technique of creating a few minimal stub objects
 176 can be convenient -- it enables you to "sketch" a portion of your game
 177 in outline form, and to compile and test the game in that state, without
 178 needing to create complete object definitions. However, you've got very
 179 little interaction with your stubs, so don't create too many of them.
 180 And of course, never forget to flesh out the stubs into full definitions
 181 as soon as you can.