Some proofreading and fixes here and there.
[ibg.git] / chapters / 03.rst
index d9a18001f6ac902bde6aa5b9f9107553f1caa598..aff3993823c0ba616ebd884a05d9f7a01b8df1ee 100644 (file)
@@ -7,7 +7,16 @@
    | *E was an esquire, with pride on his brow;*
    | *F was a farmer, and followed the plough.*
 
-Each of the three games in this guide is created step by step; you'll get
+.. only:: html
+
+  .. image:: /images/picE.png
+     :align: left
+
+.. raw:: latex
+
+    \dropcap{e}
+
+ach of the three games in this guide is created step by step; you'll get
 most benefit (especially to begin with) if you take an active part, typing
 in the source code on your computer.  Our first game, described in this
 chapter and the two which follow, tells this sentimental little story:
@@ -41,7 +50,7 @@ that we design will start out like this.  Follow these steps:
 #. In that folder, use your text editor to create this source file
    ``Heidi.inf``:
 
-   .. code-block:: inform
+   .. code-block:: inform6
 
       !% -SD
       !============================================================================
@@ -79,12 +88,12 @@ that we design will start out like this.  Follow these steps:
    Ensure the file is named ``Heidi.inf``, rather than ``Heidi.txt`` or
    ``Heidi.inf.txt``.
 
-   Remember that, throughout this guide, we place the "TYPE" symbol
+   Remember that, throughout this guide, we place the "``TYPE``" symbol
    alongside pieces of code that we recommend you to type into your own
    game files as you read through the examples (which, conversely, means
-   that you don't need to type the unmarked pieces of code).  You'll learn
-   Inform more quickly by trying it for yourself, rather than just taking
-   our word for how things work.
+   that you *don't* need to type the unmarked pieces of code).  You'll 
+   learn Inform more quickly by trying it for yourself, rather than just 
+   taking our word for how things work.
 
    .. todo::
 
@@ -189,9 +198,9 @@ looking at the source file.
   By the way, the compiler *doesn't* give special treatment to exclamation
   marks in quoted text: ``!`` within quotes "..." is treated as a normal
   character.  On this line, the first ``!`` is part of the sequence (or
-  string) of characters to be displayed:
+  **string**) of characters to be displayed:
 
-  .. code-block:: inform
+  .. code-block:: inform6
 
      print "Hello world!";         ! <- is the start of this comment
 
@@ -199,7 +208,7 @@ looking at the source file.
   space (except when the spaces are part of a character string).  So, these
   two rules tell us that we *could* have typed the source file like this:
 
-  .. code-block:: inform
+  .. code-block:: inform6
 
      Constant Story "Heidi";
      Constant Headline
@@ -222,7 +231,7 @@ looking at the source file.
 * Every game needs the three lines which ``Include`` the standard library
   files -- that is, they merge those files' contents into your source file:
 
-  .. code-block:: inform
+  .. code-block:: inform6
 
      Include "Parser";
      Include "VerbLib";
@@ -235,7 +244,7 @@ looking at the source file.
 * Every game needs to define an ``Initialise`` routine (note the British
   spelling):
 
-  .. code-block:: inform
+  .. code-block:: inform6
 
      [ Initialise; ];
 
@@ -250,7 +259,7 @@ looking at the source file.
   that's why we were able to take three lines to define the ``Headline``
   constant
 
-  .. code-block:: inform
+  .. code-block:: inform6
 
      Constant Headline
            "^A simple Inform example
@@ -278,7 +287,7 @@ In IF, we talk about each of these locations as a **room**, even though in
 this example none of them has four walls.  So let's use Inform to define
 those rooms.  Here's a first attempt:
 
-.. code-block:: inform
+.. code-block:: inform6
 
    Object   "In front of a cottage"
      with   description
@@ -372,7 +381,7 @@ clearing.  Now, although our descriptions mention or imply these available
 routes, we also need to explicitly add them to the room definitions in a
 form that the game itself can make sense of.  Like this:
 
-.. code-block:: inform
+.. code-block:: inform6
 
    Object   before_cottage "In front of a cottage"
      with   description
@@ -462,7 +471,7 @@ At this stage, you should study the four room definitions, comparing them
 with the sketch map until you're comfortable that you understand how to
 create simple rooms and define the connections between them.
 
-.. code-block:: inform
+.. code-block:: inform6
 
    !============================================================================
    Constant Story "Heidi";
@@ -535,7 +544,7 @@ Given what we said earlier, you won't be surprised to hear that both the
 bird and its nest are Inform objects.  We'll start their definitions like
 this:
 
-.. code-block:: inform
+.. code-block:: inform6
 
    Object  bird "baby bird"
      with  description "Too young to fly, the nestling tweets helplessly.",
@@ -563,7 +572,7 @@ relevant vocabulary so that the player can use whatever term seems
 appropriate to her, with a good chance of it being understood.  We add a
 line to each definition:
 
-.. code-block:: inform
+.. code-block:: inform6
 
    Object  bird "baby bird"
      with  description "Too young to fly, the nestling tweets helplessly.",
@@ -575,17 +584,18 @@ line to each definition:
            name 'bird^s' 'nest' 'twigs' 'moss',
       has  ;
 
-The ``name`` introduces a list in single quotes '...'.  We call each of
-those quoted things a **dictionary word**, and we do mean "word", not
-"phrase" (``'baby'``\ ``'bird'`` rather than ``'baby bird'``); you can't
-uses spaces, commas or periods in dictionary words, though there's a space
-*between* each one, and the whole list ends with a comma.  The idea is that
-the interpreter decides which object a player is talking about by matching
-what she types against the full set of all dictionary words.  If the player
-mentions BIRD, or BABY BIRD, or NESTLING, it's the ``baby bird`` that she
-means; if she mentions NEST, BIRD'S NEST or MOSS, it's the ``bird's nest``.
-And if she types NEST BABY or BIRD TWIGS, the interpreter will politely say
-that it doesn't understand what on earth she's talking about.
+The ``name`` introduces a list in single quotes '...'.  We call each of 
+those quoted things a **dictionary word**, and we do mean "word", not 
+"phrase" (``'baby'``\ ``'bird'`` rather than ``'baby bird'``); you can't 
+uses spaces, commas or periods *in* dictionary words, though there's a 
+space *between* each one, and the whole list ends with a comma.  The 
+idea is that the interpreter decides which object a player is talking 
+about by matching what she types against the full set of all dictionary 
+words.  If the player mentions BIRD, or BABY BIRD, or NESTLING, it's the 
+``baby bird`` that she means; if she mentions NEST, BIRD'S NEST or MOSS, 
+it's the ``bird's nest``. And if she types NEST BABY or BIRD TWIGS, the 
+interpreter will politely say that it doesn't understand what on earth 
+she's talking about.
 
 .. note::
 
@@ -614,7 +624,7 @@ that the player can type PUT (or INSERT) BIRD IN (or INTO) NEST.
 Furthermore, we label it as ``open``; this prevents the interpreter from
 asking us to open it before putting in the bird.
 
-.. code-block:: inform
+.. code-block:: inform6
 
    Object   nest "bird's nest"
      with   description "The nest is carefully woven of twigs and moss.",
@@ -626,7 +636,7 @@ To do this, we need to choose the locations where the player will find
 them.  Let's say that the bird is found in the forest, while the nest is in
 the clearing.  This is how we set this up:
 
-.. code-block:: inform
+.. code-block:: inform6
 
    Object   bird "baby bird" forest
      with   description "Too young to fly, the nestling tweets helplessly.",
@@ -648,7 +658,7 @@ but you'll find it convenient to insert them following the rooms where
 they're found.  This means adding the bird just after the forest, and the
 nest just after the clearing.  Here's the middle piece of the source file:
 
-.. code-block:: inform
+.. code-block:: inform6
 
    !============================================================================
    ! The game objects
@@ -710,7 +720,7 @@ Adding the tree and the branch
 The description of the clearing mentions a tall sycamore tree, up which the
 player character supposedly "climbs".  We'd better define it:
 
-.. code-block:: inform
+.. code-block:: inform6
 
    Object   tree "tall sycamore tree" clearing
      with   description
@@ -727,23 +737,23 @@ labelling the tree as ``scenery`` we suppress that, and also prevent it
 from being picked up by the player character.  One final object: the branch
 at the top of the tree.  Again, not many surprises in this definition:
 
-.. code-block:: inform
+.. code-block:: inform6
 
    Object   branch "wide firm bough" top_of_tree
      with   description "It's flat enough to support a small object.",
             name 'wide' 'firm' 'flat' 'bough' 'branch',
      has    static supporter;
 
-The only new things are those two labels.  ``static`` is similar to
-``scenery``: it prevents the branch from being picked up by the player
-character, but *doesn't* suppress mention of it when describing the
-setting.  And ``supporter`` is rather like the ``container`` that we used
-for the nest, except that this time the player character can put other
-objects *onto* the branch.  (In passing, we'll mention that an object can't
-normally be both a ``container`` and a ``supporter``.)  And so here are our
-objects again:
+The only new things are those two labels.  ``static`` is similar to 
+``scenery``: it prevents the branch from being picked up by the player 
+character, but *doesn't* suppress mention of it when describing the 
+setting.  And ``supporter`` is rather like the ``container`` that we 
+used for the nest, except that this time the player character can put 
+other objects *onto* the branch.  (In passing, we'll mention that an 
+object can't normally be both a ``container`` *and* a ``supporter``.)  
+And so here are our objects again:
 
-.. code-block:: inform
+.. code-block:: inform6
 
    !============================================================================
    ! The game objects
@@ -811,7 +821,7 @@ carrying the bird and the nest separately: we want the player character to
 put the bird into the nest first.  One easy way to enforce this is by
 adding a line near the top of the file:
 
-.. code-block:: inform
+.. code-block:: inform6
 
    !============================================================================
    Constant Story "Heidi";
@@ -833,7 +843,7 @@ to put the bird in the nest, take the nest to the top of the tree, and
 place it on the branch; when that happens, the game should be over.  This
 is one way of making it happen:
 
-.. code-block:: inform
+.. code-block:: inform6
 
    Object  branch "wide firm bough" top_of_tree
      with  description "It's flat enough to support a small object.",