X-Git-Url: https://jxself.org/git/?a=blobdiff_plain;f=chapters%2F12.rst;h=f7009c6a04789ce1257e369e840f45bc349ac553;hb=0d516f59baf6cdad07fe8f00264da39ddd8b0ebb;hp=4e8654ad071dc9891228bebe1f81f16824f8f24a;hpb=a94081289bc21041a8daac44d8c8b6714a831281;p=ibg.git diff --git a/chapters/12.rst b/chapters/12.rst index 4e8654a..f7009c6 100644 --- a/chapters/12.rst +++ b/chapters/12.rst @@ -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. @@ -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,21 +151,17 @@ 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:: 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: @@ -174,7 +170,7 @@ while leaving the ``outside_of_toilet`` unchanged: 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 @@ -298,7 +294,7 @@ 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 @@ -338,27 +334,26 @@ statement as shorthand for: 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