From: Glenn Hutchings Date: Thu, 16 Jun 2016 20:13:08 +0000 (+0100) Subject: Resolve TODO from chapter 11. X-Git-Url: https://jxself.org/git/?p=ibg.git;a=commitdiff_plain;h=4261ff48a6357e2af0957f5e1b88bdc022243d16 Resolve TODO from chapter 11. --- diff --git a/chapters/11.rst b/chapters/11.rst index 499f75b..a82408e 100644 --- a/chapters/11.rst +++ b/chapters/11.rst @@ -72,40 +72,34 @@ We've mentioned a counter: ], has supporter; -That :prop:`before` property, superficially normal, actually conceals a -little surprise. By now you should be entirely comfortable with using an -object's :prop:`before` property to intercept an action directed at that -object; for example, if the player types HIT COUNTER then the counter's -:prop:`before` property is potentially able to intercept the resulting -Attack action. However, the command PUT KEY ON COUNTER generates *two* -actions. First, a PutOn action is offered to the key (effectively -saying, do you want to be placed on top of the counter?); that’s the -normal bit. And then the surprise: a Receive action is offered to the -counter (effectively saying, are you happy to have the key placed on -you?) Both actions have the same opportunity of returning :const:`false` to -let the action continue, :const:`true` to prevent it. - -.. todo:: - - There are a lot of actions here that are rendered in a typewriter font - and others that are not. Should these ones that are not be promoted - to having a typewriter font? - -The Receive action is generated by the library in the PutOnSub action -handler, and also in InsertSub (so a command like PUT BIRD IN NEST sends a -Receive to the nest object). There’s a matching LetGo, generated by the -library from commands like TAKE KEY OFF COUNTER and REMOVE BIRD FROM -NEST. Receive and LetGo are examples of what’s called a :term:`fake -action`. +That :prop:`before` property, superficially normal, actually conceals a +little surprise. By now you should be entirely comfortable with using an +object's :prop:`before` property to intercept an action directed at that +object; for example, if the player types HIT COUNTER then the counter's +:prop:`before` property is potentially able to intercept the resulting +``Attack`` action. However, the command PUT KEY ON COUNTER generates *two* +actions. First, a ``PutOn`` action is offered to the key (effectively +saying, do you want to be placed on top of the counter?); that’s the normal +bit. And then the surprise: a ``Receive`` action is offered to the counter +(effectively saying, are you happy to have the key placed on you?) Both +actions have the same opportunity of returning :const:`false` to let the +action continue, :const:`true` to prevent it. + +The ``Receive`` action is generated by the library in the ``PutOnSub`` +action handler, and also in ``InsertSub`` (so a command like PUT BIRD IN +NEST sends a Receive to the nest object). There’s a matching ``LetGo``, +generated by the library from commands like TAKE KEY OFF COUNTER and REMOVE +BIRD FROM NEST. ``Receive`` and ``LetGo`` are examples of what’s called a +:term:`fake action`. .. note:: In "William Tell" we defined the ``quiver``, way back in :ref:`possessions`, as an ``open container``. As things stand, the player can put *any* held object, however inappropriate, into it. We could have - trapped the Receive action to ensure that arrows are the only acceptable - contents (recollect that ``~~``, to be read as "not", turns true into - false and vice versa): + trapped the ``Receive`` action to ensure that arrows are the only + acceptable contents (recollect that ``~~``, to be read as "not", turns + true into false and vice versa): .. code-block:: inform @@ -213,18 +207,17 @@ need the customers to perform tasks for us, so instead we provide a simple rejection message, just in case the player tries to order people around. -Which leaves us with the :prop:`daemon` bit. A daemon is a property normally -used to perform some timed or repetitive action without the need of the -player’s direct interaction; for example, machines which work by -themselves, animals that move on their own, or people going about their -business. More powerfully, a daemon may take notice of the player’s -decisions at a particular moment, allowing for some interactive -behaviour; this is, however, an advanced feature that we won't use in -this example. A daemon gets a chance of doing something at the end of -every turn, typically to (or with) the object to which it’s associated. -In our example, the daemon triggers some sneers and nasty comments from -the customers once our hero comes out of the toilet dressed in Captain -Fate’s costume. +Which leaves us with the :prop:`daemon` bit. A daemon is a property +normally used to perform some timed or repetitive action without the need +of the player’s direct interaction; for example, machines which work by +themselves, animals that move on their own, or people going about their +business. More powerfully, a daemon may take notice of the player’s +decisions at a particular moment, allowing for some interactive behaviour; +this is, however, an advanced feature that we won't use in this example. A +daemon gets a chance of doing something at the end of every turn, typically +to (or with) the object to which it’s associated. In our example, the +daemon triggers some sneers and nasty comments from the customers once our +hero comes out of the toilet dressed in Captain Fate’s costume. To code a daemon, you need to do three things: @@ -737,7 +730,7 @@ in scope, and enables the player to refer to it without the interpreter complaining. Because Benny also has an :attr:`animate` attribute, the interpreter would normally intercept a TAKE KEY action with "That seems to belong to Benny"; however, the same wouldn't apply to other commands -like TOUCH KEY and TASTE KEY . So, to prevent any interaction with the +like TOUCH KEY and TASTE KEY. So, to prevent any interaction with the key while it’s in Benny’s pockets, we define a :prop:`before` property. .. code-block:: inform