images, but the main focus of the room isn't the decor: it's the door
leading to the toilet -- and, perhaps, privacy?
+.. _homely-atmos:
+
A homely atmosphere
===================
We define the café room in simple form:
-.. code-block:: inform6
+.. code-block:: inform
Room cafe "Inside Benny's cafe"
with description
We've mentioned a counter:
-.. code-block:: inform6
+.. code-block:: inform
Appliance counter "counter" cafe
with name 'counter' 'bar',
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 **fake action**.
+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 "The
- player's possessions" on page 83, 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):
+ 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):
- .. code-block:: inform6
+ .. code-block:: inform
before [;
Drop,Give:
We've also mentioned some customers. These are treated as NPCs, reacting
to our hero’s performance.
-.. code-block:: inform6
+.. code-block:: inform
Object customers "customers" cafe
with name 'customers' 'people' 'customer' 'men' 'women',
something interesting only while the player stays in the right place
(and hasn’t wandered, say, back into the toilet):
-.. code-block:: inform6
+.. code-block:: inform
if (location ~= cafe) return;
café room from the toilet for the first time, the value of the property
should be zero, so the statement block under the test:
-.. code-block:: inform6
+.. code-block:: inform
if (self.number_of_comments == 0) {
self.number_of_comments = 1;
We want the customers to indulge in witticisms once they see the
costumed Captain, but not on a completely predictable basis.
-.. code-block:: inform6
+.. code-block:: inform
if (random(2) == 1) ...
-.. todo::
-
- "expression" in "random(expression)" should be typewriter and italic
-
``random`` is an Inform routine used to generate random numbers or to
choose randomly between given choices; in the form
-``random(expression)`` it returns a random number between 1 and
+:samp:`random({expression})` it returns a random number between 1 and
``expression`` inclusive. So our condition is actually stating: if a
random choice between 1 and 2 happens to be 1 then perform some action.
Remember that a daemon is run once at the end of every turn, so the
As a consequence of all this, we add an ``after`` property to the café
room object:
-.. code-block:: inform6
+.. code-block:: inform
Room cafe "Inside Benny's cafe"
...
The first line:
-.. code-block:: inform6
+.. code-block:: inform
if (noun ~= s_obj) return false;
Door objects require some specific properties and attributes. Let's
first code a simple door:
-.. code-block:: inform6
+.. code-block:: inform
Object toilet_door "toilet door" cafe
name name 'red' 'toilet' 'door',
little bit complicated and you''ll have to define routines for most
properties:
-.. code-block:: inform6
+.. code-block:: inform
Object toilet_door "toilet door"
with name 'red' 'toilet' 'door',
property`` is the thing. We have already talked about the external name
defined as part of an object's header information:
-.. code-block:: inform6
+.. code-block:: inform
Object toilet_door "toilet door"
to refer to the door. With identical effect, this could also have been
coded thus:
-.. code-block:: inform6
+.. code-block:: inform
Object toilet_door
with short_name "toilet door",
information method is perfect in that case -- but if it needs to change,
it's easy to write a routine as the value of ``short_name``:
-.. code-block:: inform6
+.. code-block:: inform
Object toilet_door
with name 'red' 'toilet' 'door'
.. note::
- what's displayed if there isn't an external name in an object's
- header? If you've read the section "Compile-as-you-go" on page 233,
- you'll recall that the interpreter simply uses the internal
- identifier within parentheses; that is, with no external name and no
- ``short_name`` property, we might see:
+ what's displayed if there isn't an external name in an object's header?
+ If you've read the section :ref:`compile-as-you-go`, you'll recall that
+ the interpreter simply uses the internal identifier within parentheses;
+ that is, with no external name and no ``short_name`` property, we might
+ see:
- .. code-block:: inform6
+ .. code-block:: inform
You open the (toilet_door).
of our ``print`` statement, and then the standard rules would display
the internal ID:
- .. code-block:: inform6
+ .. code-block:: inform
You open the door to the toilet(toilet_door).
worth a shot. Let's provide a few improvements to our toilet door in
``before`` and ``after`` properties:
-.. code-block:: inform6
+.. code-block:: inform
before [ ks;
Open:
standalone routine is declared between the routine’s name and the
semicolon:
-.. code-block:: inform6
+.. code-block:: inform
[ BeenToBefore this_room;
declared between the ``[`` starting marker of the routine and the
semicolon:
-.. code-block:: inform6
+.. code-block:: inform
before [ ks;
spaces -- which are usable only within the embedded routine. When we
assign it thus:
-.. code-block:: inform6
+.. code-block:: inform
ks = keep_silent;
``keep_silent`` to ``true``, make the desired silent actions, and we
assign:
-.. code-block:: inform6
+.. code-block:: inform
keep_silent = ks;
toilet. A dead end? No, the description mentions a scribbled note on its
surface. This one should offer no problem:
-.. code-block:: inform6
+.. code-block:: inform
Object "scribbled note" cafe
with name 'scribbled' 'note',
detail throughout the next chapter, here we present a basic definition,
largely so that the key has a parent object.
-.. code-block:: inform6
+.. code-block:: inform
Object benny "Benny" cafe
with name 'benny',
like TOUCH KEY and TASTE KEY . So, to prevent any interaction with the
key while it’s in Benny’s pockets, we define a ``before`` property.
-.. code-block:: inform6
+.. code-block:: inform
before [;
if (self in benny)
"Benny is trusting you to look after that key.";
];
-All of the ``before`` properties that we've so far created have
-contained one or more labels specifying the actions which they are to
-intercept; you'll remember that in "William Tell" we introduced the
-``default`` action (see "A class for props" on page 74) to mean "any
-value not already catered for". There's one of those labels here, for
-the Drop action, but that's preceded by a piece of code that will be
-executed at the start of *every* action directed at the key. If it’s
-still in Benny’s possession, we display a polite refusal; if the player
-has it then we prevent careless disposal; otherwise, the action
-continues unhindered.
+All of the ``before`` properties that we've so far created have contained
+one or more labels specifying the actions which they are to intercept;
+you'll remember that in "William Tell" we introduced the ``default`` action
+(see :ref:`props-class`) to mean "any value not already catered
+for". There's one of those labels here, for the Drop action, but that's
+preceded by a piece of code that will be executed at the start of *every*
+action directed at the key. If it’s still in Benny’s possession, we display
+a polite refusal; if the player has it then we prevent careless disposal;
+otherwise, the action continues unhindered.
-(In fact, the hat-on-a-pole ``Prop`` introduced on page 91 had this
-all-exclusive ``before`` property:
+(In fact, the hat-on-a-pole ``Prop`` introduced in :ref:`south-side` had
+this all-exclusive ``before`` property:
-.. code-block:: inform6
+.. code-block:: inform
before [;
default:
they'll try to examine the toilet room from the outside, it takes very
little effort to offer a sensible output just in case:
-.. code-block:: inform6
+.. code-block:: inform
Object outside_of_toilet "toilet" cafe
with name 'toilet' 'bath' 'rest' 'room' 'bathroom' 'restroom',
projects / ibg.git / blobdiff