Tick some things off the TODO list.
[ibg.git] / chapters / 05.rst
index 1dbcfada5c1e8251b9afc21fa6d3f26d6ef44bf4..873d6a0f4819a044892af313bc81a47f66e6fe97 100644 (file)
@@ -1,26 +1,18 @@
-.. raw:: latex
-
-   \newpage
-
 =================
  Heidi revisited
 =================
 
 .. epigraph::
 
-   | *I was an innkeeper, who loved to carouse;*
-   | *J was a joiner, and built up a house.*
+   | |CENTER| *I was an innkeeper, who loved to carouse;*
+   | |CENTER| *J was a joiner, and built up a house.*
 
 .. only:: html
 
   .. image:: /images/picI.png
      :align: left
 
-.. raw:: latex
-
-    \dropcap{i}
-
-n even the simplest story, there's bound to be scope for the player to
+|I|\n even the simplest story, there's bound to be scope for the player to
 attempt activities that you hadn't anticipated.  Sometimes there may be
 alternative ways of approaching a problem: if you can't be sure which
 approach the player will take, you really ought to allow for all
@@ -68,7 +60,7 @@ LISTEN TO NEST or LISTEN TO TREE, but fairly inappropriate here; we really
 need to substitute a more relevant response after LISTEN TO BIRD.  Here's
 how we do it:
 
-.. code-block:: inform6
+.. code-block:: inform
 
    Object   bird "baby bird" forest
      with   description "Too young to fly, the nestling tweets helplessly.",
@@ -137,7 +129,7 @@ false`` then the interpreter carries on to perform the default action as
 though it hadn't been intercepted.  Sometimes that's what you want it to
 do, but not here: if instead we'd written this:
 
-.. code-block:: inform6
+.. code-block:: inform
 
    Object    bird "baby bird" forest
      with    description "Too young to fly, the nestling tweets helplessly.",
@@ -184,7 +176,7 @@ might lead her to believe that she can go inside:
 Again, that isn't perhaps the most appropriate response, but it's easy to
 change:
 
-.. code-block:: inform6
+.. code-block:: inform
 
    Object    before_cottage "In front of a cottage"
      with    description
@@ -225,7 +217,7 @@ receives the obviously nonsensical reply "You can't see any such thing".
 That's easy to fix; we can add a new ``cottage`` object, making it a piece
 of ``scenery`` just like the ``tree``:
 
-.. code-block:: inform6
+.. code-block:: inform
 
    Object   cottage "tiny cottage" before_cottage
      with   description "It's small and simple, but you're very happy here.",
@@ -248,7 +240,7 @@ response:
 The situation here is similar to our LISTEN TO BIRD problem, and the
 solution we adopt is similar as well:
 
-.. code-block:: inform6
+.. code-block:: inform
 
    Object   cottage "tiny cottage" before_cottage
      with   description "It's small and simple, but you're very happy here.",
@@ -265,7 +257,7 @@ This time, however, we've done it using one statement rather than two.  It
 turns out that the sequence "``print`` a string which ends with a newline
 character, and then ``return true``" is so frequently needed that there's a
 special statement which does it all.  That is, this single statement (where
-you'll note that the string doesn't need to end in ``^``)::
+you'll note that the string *doesn't* need to end in ``^``)::
 
      print_ret "It's such a lovely day -- much too nice to go inside.";
 
@@ -286,7 +278,7 @@ currently gives the completely misleading response "I don't think much is
 to be achieved by that").  Yet another opportunity to use a ``before``
 property, but now with a difference.
 
-.. code-block:: inform6
+.. code-block:: inform
 
    Object   tree "tall sycamore tree" clearing
      with   description
@@ -304,19 +296,20 @@ This time, when we intercept the ``Climb`` action applied to the ``tree``
 object, it's not in order to display a better message; it's because we want
 to move the player character to another room, just as if she'd typed UP.
 Relocating the player character is actually quite a complex business, but
-fortunately all of that complexity is hidden: there's a standard **library
-routine** to do the job, not one that we've written, but one that's
-provided as part of the Inform system.
-
-You'll remember that, when we first mentioned routines (see "Standalone
-routines" on page 57), we used the example of ``Initialise()`` and said
-that "the routine's name followed by opening and closing parentheses is all
-that it takes to call a routine".  That was true for ``Initialise()``, but
-not quite the whole story.  To move the player character, we've got to
-specify where we want her to go, and we do that by supplying the internal
-ID of the destination room within the opening and closing parentheses.
-That is, instead of just ``PlayerTo()`` we call ``PlayerTo(top_of_tree)``,
-and we describe ``top_of_tree`` as the routine's **argument**.
+fortunately all of that complexity is hidden: there's a standard
+:term:`library routine` to do the job, not one that we've written, but one
+that's provided as part of the Inform system.
+
+You'll remember that, when we first mentioned routines (see
+:ref:`standalone-routines`), we used the example of ``Initialise()`` and
+said that "the routine's name followed by opening and closing parentheses
+is all that it takes to call a routine".  That was true for
+``Initialise()``, but not quite the whole story.  To move the player
+character, we've got to specify where we want her to go, and we do that by
+supplying the internal ID of the destination room within the opening and
+closing parentheses.  That is, instead of just ``PlayerTo()`` we call
+``PlayerTo(top_of_tree)``, and we describe ``top_of_tree`` as the routine's
+:term:`argument`.
 
 Although we've moved the player character to another room, we're still in
 the middle of the intercepted ``Climb`` action.  As previously, we need to
@@ -350,7 +343,7 @@ interception not on an object-by-object basis, as we have been doing so
 far, but instead for every ``Drop`` which takes place in our troublesome
 ``top_of_tree`` room.  This is what we have to write:
 
-.. code-block:: inform6
+.. code-block:: inform
 
    Object   top_of_tree "At the top of the tree"
      with   description "You cling precariously to the trunk.",
@@ -431,7 +424,7 @@ Of course, you might think that the standard message "Dropped" is slightly
 unhelpful in these non-standard circumstances.  If you prefer to hint at
 what's just happened, you could use this alternative solution:
 
-.. code-block:: inform6
+.. code-block:: inform
 
    Object   top_of_tree "At the top of the tree"
      with   description "You cling precariously to the trunk.",
@@ -458,7 +451,7 @@ nest, or vice versa.  It would be better not to end the game until we'd
 checked for the bird actually being in the nest; fortunately, that's easy
 to do:
 
-.. code-block:: inform6
+.. code-block:: inform
 
    Object   branch "wide firm bough" top_of_tree
      with   description "It's flat enough to support a small object.",
@@ -471,7 +464,7 @@ The extended ``if`` statement::
     if (bird in nest && nest in branch) deadflag = 2;
 
 should now be read as: "Test whether the ``bird`` is currently in (or on)
-the ``nest``, and whether the ``nest`` is currently on (or in) the
+the ``nest``, *and* whether the ``nest`` is currently on (or in) the
 ``branch``; if both parts are ``true``, set the value of ``deadflag`` to 2;
 otherwise, do nothing".
 
@@ -488,7 +481,8 @@ when you're telling the player "sorry, you can't do that".
 
 The new topics that we've encountered here include these:
 
-.. rubric:: Object properties
+Object properties
+-----------------
 
 Objects can have a ``before`` property -- if there is one, the interpreter
 looks at it *before* performing an action which in some way involves that
@@ -519,11 +513,14 @@ explicitly listed::
     in_to "It's such a lovely day -- much too nice to go inside.",
     cant_go "The only path lies to the east.",
 
-.. rubric:: Routines and arguments
+.. _routines-args:
+
+Routines and arguments
+----------------------
 
 The library includes a number of useful routines, available to perform
-certain common tasks if you require them; there's a list in "Library
-routines" on page 264.  We used the ``PlayerTo`` routine, which moves the
+certain common tasks if you require them; there's a list in
+:ref:`library-routines`.  We used the ``PlayerTo`` routine, which moves the
 player character from her current room to another one -- not necessarily
 adjacent to the first room.
 
@@ -533,7 +530,7 @@ parentheses, thus::
 
     PlayerTo(clearing);
 
-A value given in parentheses like that is called an **argument** of the
+A value given in parentheses like that is called an :term:`argument` of the
 routine.  In fact, a routine can have more than one argument; if so,
 they're separated by commas.  For example, to move the player character to
 a room *without* displaying that room's description, we could have supplied
@@ -544,7 +541,8 @@ a second argument::
 In this example, the effect of the ``1`` is to prevent the description
 being displayed.
 
-.. rubric:: Statements
+Statements
+----------
 
 We encountered several new statements:
 
@@ -613,11 +611,11 @@ PUT NEST ON BRANCH                 PutOn      nest      branch
 
 The value ``nothing`` is a built-in constant (like ``true`` and ``false``)
 which means, well, there isn't any object to refer to.  There's a list of
-standard library actions in "Group 1 actions" on page 270, "Group 2
-actions" on page 271 and "Group 3 actions" on page 271.
+standard library actions in :ref:`group-1-actions`, :ref:`group-2-actions`
+and :ref:`group-3-actions`.
 
 We've now reached the end of our first game.  In these three chapters we've
 shown you the basic principles on which almost all games are based, and
 introduced you to many of the components that you'll need when creating
 more interesting IF.  We suggest that you take one last look at the source
-code (see "Heidi" story on page 213), and then move on to the next stage.
+code (see :doc:`/appendices/b`), and then move on to the next stage.