appendices/c.rst

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