Tick some things off the TODO list.
[ibg.git] / chapters / 12.rst
index 595c0b160aeae1a7212c943de2f1f7fdbbf77441..f7009c6a04789ce1257e369e840f45bc349ac553 100644 (file)
@@ -4,21 +4,17 @@ Captain Fate: take 3
 
 .. epigraph::
 
-   | *W was a watchman, and guarded the door;*
-   | *X was expensive, and so became poor.*
+   | |CENTER| *W was a watchman, and guarded the door;*
+   | |CENTER| *X was expensive, and so became poor.*
 
 .. only:: html
 
    .. image:: /images/picW.png
       :align: left
 
-.. raw:: latex
-
-   \dropcap{w}
-
-e've given ourselves an interesting challenge by overusing that 
-convenient word "toilet", and here we show you how we resolve the 
-ambiguities that have been introduced. Also, it's time for the eponymous 
+|W|\e've given ourselves an interesting challenge by overusing that
+convenient word "toilet", and here we show you how we resolve the
+ambiguities that have been introduced. Also, it's time for the eponymous
 owner of Benny's café to be developed in full.
 
 Too many toilets
@@ -52,7 +48,7 @@ could benefit from the effort. The product of this generosity takes the
 form of a library extension: the solution neatly packaged as a file that 
 other designers can incorporate into their source code. These files can 
 be found in the IF Archive: go to 
-``http://mirror.ifarchive.org/indexes/if-archive.html`` and then select 
+http://mirror.ifarchive.org/indexes/if-archive.html and then select 
 "``.../infocom``", "``.../compilers``", "``.../inform6``", 
 "``.../library``", and "``.../contributions``". All of these files 
 contain Inform code. To use a library extension (also known as a library 
@@ -64,15 +60,14 @@ there are rules about where exactly this Include should be placed in
 your source code. It is not unusual to find other suggestions and 
 warnings.
 
-To help us out of the disambiguation problem with the word TOILET, we 
-are going to use Neil Cerutti's extension ``pname.h``, which is designed 
-for situations precisely like this. First, we follow the link to the IF 
-archive and download the compressed file ``pname.zip``, which contains 
-two more files: ``pname.h`` and ``pname.txt``. We place these files in 
-the folder where we are currently developing our game or, if using the 
-environment we proposed in "Tools of the trade" on page 17, in the 
-``Inform\Lib\Contrib`` folder. The text file offers instructions about 
-installation and usage. Here we find a warning:
+To help us out of the disambiguation problem with the word TOILET, we are
+going to use Neil Cerutti's extension ``pname.h``, which is designed for
+situations precisely like this. First, we follow the link to the IF archive
+and download the compressed file ``pname.zip``, which contains two more
+files: ``pname.h`` and ``pname.txt``. We place these files in the folder
+where we are currently developing our game or, if using the environment we
+proposed in :doc:`02`, in the ``Inform\Lib\Contrib`` folder. The text file
+offers instructions about installation and usage. Here we find a warning:
 
   This version of pname.h is recommended for use only with version 6/10 
   of the Inform Library.
@@ -108,14 +103,19 @@ instructions:
   #.  Add four lines near the head of the program (before you include 
       ``Parser.h``).
 
-      ``Replace MakeMatch;``
-      ``Replace Identical;``
-      ``Replace NounDomain;``
-      ``Replace TryGivenObject;``
+      .. code-block:: inform
+
+         Replace MakeMatch;
+         Replace Identical;
+         Replace NounDomain;
+         Replace TryGivenObject;
 
   #.  Include the ``pname.h`` header just after you include ``Parser.h``.
-      ``Include "Parser";``
-      ``Include "pname";``
+
+      .. code-block:: inform
+
+         Include "Parser";
+         Include "pname";
 
   #.  Add ``pname`` properties to those objects which require phrase 
       recognition.
@@ -125,7 +125,7 @@ It seems simple enough. So, following steps one and two, we add those
 ``pname.h`` right after it. ``Replace`` tells the compiler that we're 
 providing replacements for some standard routines.
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Constant Story "Captain Fate";
   Constant Headline
@@ -142,7 +142,7 @@ providing replacements for some standard routines.
 
   Include "Parser";
   Include "pname";
-  !...
+  ...
 
 Now our source code is ready to benefit from the library package. How 
 does it work? We have acquired a new property -- ``pname`` -- which can 
@@ -151,30 +151,26 @@ be added to some of our objects, and which works pretty much like a
 property where we have a disambiguation problem. Let’s change the 
 relevant lines for the toilet door and the toilet key:
 
-.. todo::
-
-  Maybe specially highlight the lines using pname?
-
-.. code-block:: inform6
+.. code-block:: inform
 
   Object  toilet_door
     with  pname '.x' 'red' '.x' 'toilet' 'door',
           short_name [;
-          !...
+          ...
 
   Object  toilet_key "toilet key" benny
     with  pname '.x' 'toilet' 'key',
           article "the",
-          !...
+          ...
 
 while leaving the ``outside_of_toilet`` unchanged:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Object  outside_of_toilet "toilet" cafe
     with  name 'toilet' 'bath' 'rest' 'room' 'bathroom' 'restroom',
           before [;
-          !...
+          ...
 
 We are now using a new operator -- ``'.x'`` -- in our ``pname`` word 
 lists. explains
@@ -186,7 +182,7 @@ and this makes the dictionary word ``'toilet'`` of lesser importance for
 these objects, so that at run-time players could refer to the DOOR or 
 TOILET DOOR or the KEY or TOILET KEY -- but not simply to the TOILET -- 
 when referring to either the door or the key. And, by leaving unchanged 
-the name property of the outside_of_toilet object – where there is also 
+the name property of the ``outside_of_toilet`` object – where there is also 
 another ``'toilet'`` entry -- the ``pname`` properties will tell the 
 interpreter to discard the key and the door as possible objects to be 
 considered when players refer just to TOILET. Looking at it in terms of 
@@ -223,7 +219,7 @@ a coin near the lavatory, enough cash to pay for the coffee. And that
 about sums it all up; pretty simple to describe -- not so simple to 
 code. Remember Benny's basic definition from the previous chapter:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Object  benny "Benny" cafe
     with  name 'benny',
@@ -236,7 +232,7 @@ code. Remember Benny's basic definition from the previous chapter:
 We can now add some complexity, beginning with a ``life`` property. In 
 generic form:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   life [;
     Give:             !... code for giving objects to Benny
@@ -248,6 +244,8 @@ generic form:
 We have seen some of these actions before. We'll take care of the easier 
 ones:
 
+.. code-block:: inform
+
   Attack:
     if (costume has worn) {
         deadflag = 4;
@@ -284,7 +282,7 @@ the coffee has been paid for, and whether the toilet key has been
 returned. The solution, yet again (this really is a most useful 
 capability), is more local property variables:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Object  benny "Benny" cafe
     with  name 'benny',
@@ -296,14 +294,14 @@ capability), is more local property variables:
           coffee_not_paid  false,          ! is Benny waiting to be paid?
           key_not_returned false,          ! is Benny waiting for the key?
           live [;
-          !...
+          ...
 
 Now we are ready to tackle the ``Give`` action of the ``life`` property, 
 which deals with commands like GIVE THE KEY TO BENNY (in a moment, we'll 
 come to the ``Give`` action of the ``orders`` property, which deals with 
 commands like BENNY, GIVE ME THE KEY):
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Give:
     switch (noun) {
@@ -332,31 +330,30 @@ The Give action in the ``life`` property holds the variable ``noun`` as
 the object offered to the NPC. Remember that we can use the ``switch`` 
 statement as shorthand for:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   if (noun == costume) { whatever };
   if (noun == clothes) { whatever };
-  !...
-
-We won't let players give away their clothes or their costume (yes, an 
-improbable action, but you never know). The toilet key and the coin are 
-successfully transferred. The property ``key_not_returned`` will be set 
-to true when we receive the toilet key from Benny (we have not coded 
-that bit yet), and now, when we give it back, it's reset to ``false``. 
-The ``move`` statement is in charge of the actual transfer of the object 
-from the player's inventory to Benny, and we finally display a 
-confirmation message. With the coin, we find a new statement: 
-``remove``. This extracts the object from the object tree, so that it 
-now has no parent. The effect is to make it disappear from the game 
-(though you are not destroying the object permanently -- and indeed you 
-could return it to the object tree using the ``move`` statement); as far 
-as the player is concerned, there isn’t a COIN to be found anywhere. The 
-``coffee_not_paid`` property will be set to true when Benny serves us 
-the cup of coffee (again, we’ll see that in a moment); now we reset it 
-to ``false``, which liberates the player from debt. This culminates with 
-the ``"..."`` print-and-return statement, telling the player that the 
-action was successful. In passing, remember that in "A homely 
-atmosphere" on page 131 we defined the counter such that PUT KEY ON 
+  ...
+
+We won't let players give away their clothes or their costume (yes, an
+improbable action, but you never know). The toilet key and the coin are
+successfully transferred. The property ``key_not_returned`` will be set to
+true when we receive the toilet key from Benny (we have not coded that bit
+yet), and now, when we give it back, it's reset to ``false``.  The ``move``
+statement is in charge of the actual transfer of the object from the
+player's inventory to Benny, and we finally display a confirmation
+message. With the coin, we find a new statement: ``remove``. This extracts
+the object from the object tree, so that it now has no parent. The effect
+is to make it disappear from the game (though you are not destroying the
+object permanently -- and indeed you could return it to the object tree
+using the ``move`` statement); as far as the player is concerned, there
+isn’t a COIN to be found anywhere. The ``coffee_not_paid`` property will be
+set to true when Benny serves us the cup of coffee (again, we’ll see that
+in a moment); now we reset it to ``false``, which liberates the player from
+debt. This culminates with the ``"..."`` print-and-return statement,
+telling the player that the action was successful. In passing, remember
+that in :ref:`homely-atmos` we defined the counter such that PUT KEY ON
 COUNTER is automatically translated into GIVE KEY TO BENNY .
 
 Why move the key to Benny but remove the coin instead? Once players 
@@ -375,7 +372,7 @@ demands. The ``Give`` action in an ``orders`` property deals with inputs
 like ASK BENNY FOR THE KEY or BENNY, GIVE ME THE KEY. The syntax is 
 similar to that of the ``life`` property:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   orders [;   ! handles ASK BENNY FOR X and BENNY, GIVE ME XXX
     Give:
@@ -466,7 +463,7 @@ indeed he will. But where?
 
 We must revisit the café room object:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   Room     cafe "Inside Benny's cafe"
     with   description
@@ -535,7 +532,7 @@ chapter, this technique lets you trap the player who is about to exit a
 room before the movement actually takes place, a good moment to 
 interfere if we want to prevent escape. The first line:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   if (noun ~= s_obj) return false;
 
@@ -557,7 +554,7 @@ attempt to leave:
 
 The first three are covered by the test:
 
-.. code-block:: inform6
+.. code-block:: inform
 
   if (benny.coffee_not_paid == true || benny.key_not_returned == true) ...