X-Git-Url: https://jxself.org/git/?a=blobdiff_plain;ds=sidebyside;f=chapters%2F12.rst;h=d00131f3b0ccffe28c198e352bb8666168739176;hb=d102cdffefa7d68901d9f6e7d564656270bd0280;hp=7b632e48ef023a0a50db0404481392acc8fd67af;hpb=323dd0e951d6ccf567b6a13ca4b4cef87c52d39d;p=ibg.git diff --git a/chapters/12.rst b/chapters/12.rst index 7b632e4..d00131f 100644 --- a/chapters/12.rst +++ b/chapters/12.rst @@ -64,15 +64,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. @@ -125,7 +124,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 @@ -155,7 +154,7 @@ relevant lines for the toilet door and the toilet key: Maybe specially highlight the lines using pname? -.. code-block:: inform6 +.. code-block:: inform Object toilet_door with pname '.x' 'red' '.x' 'toilet' 'door', @@ -169,7 +168,7 @@ relevant lines for the toilet door and the toilet key: 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', @@ -223,7 +222,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 +235,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,7 +247,7 @@ generic form: We have seen some of these actions before. We'll take care of the easier ones: -.. code-block:: inform6 +.. code-block:: inform Attack: if (costume has worn) { @@ -286,7 +285,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', @@ -305,7 +304,7 @@ 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) { @@ -334,31 +333,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 @@ -377,7 +375,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: @@ -468,7 +466,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 @@ -537,7 +535,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; @@ -559,7 +557,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) ...