7 | *U was a usurer, a miserable elf;*
8 | *V was a vintner, who drank all himself.*
12 .. image:: /images/picV.png
19 iewed from the inside, Benny's café is warm and welcoming, and packed
20 with lunchtime customers. We'll try to conjure up some appropriate
21 images, but the main focus of the room isn't the decor: it's the door
22 leading to the toilet -- and, perhaps, privacy?
29 Benny's café is populated with customers enjoying their lunch, so it
30 won't be a good place to change identities. However, the toilet to the
31 north looks promising, though Benny has strict rules about its use and
32 the door seems to be locked.
34 .. admonition:: Cultural Note
35 :class: admonition note
37 Not for the first time, this guide betrays its origins. In
38 European countries the word "toilet" often refers not only to the
39 white porcelain artefact, but also to the room in which it can be
40 found (also, a "bathroom" is for taking a bath, a "restroom" for
41 taking a rest). Bear with us on this; the dual usage becomes
42 important a little later on.
44 We define the café room in simple form:
46 .. code-block:: inform
48 Room cafe "Inside Benny's cafe"
50 "Benny's offers the FINEST selection of pastries and
51 sandwiches. Customers clog the counter, where Benny himself
52 manages to serve, cook and charge without missing a step. At
53 the north side of the cafe you can see a red door connecting
58 We'll elaborate on the last line (``n_to toilet_door``) later, when we
59 define the door object which lies between the café and the toilet.
61 We've mentioned a counter:
63 .. code-block:: inform
65 Appliance counter "counter" cafe
66 with name 'counter' 'bar',
69 "The counter is made of an astonishing ALLOY of metals,
70 STAIN-PROOF, SPILL-RESISTANT and VERY EASY to clean. Customers
71 enjoy their snacks with UTTER tranquillity, safe in the notion
72 that the counter can take it all.",
79 That ``before`` property, superficially normal, actually conceals a
80 little surprise. By now you should be entirely comfortable with using an
81 object's ``before`` property to intercept an action directed at that
82 object; for example, if the player types HIT COUNTER then the counter's
83 ``before`` property is potentially able to intercept the resulting
84 Attack action. However, the command PUT KEY ON COUNTER generates *two*
85 actions. First, a PutOn action is offered to the key (effectively
86 saying, do you want to be placed on top of the counter?); that’s the
87 normal bit. And then the surprise: a Receive action is offered to the
88 counter (effectively saying, are you happy to have the key placed on
89 you?) Both actions have the same opportunity of returning ``false`` to
90 let the action continue, ``true`` to prevent it.
94 There are a lot of actions here that are rendered in a typewriter font
95 and others that are not. Should these ones that are not be promoted
96 to having a typewriter font?
98 The Receive action is generated by the library in the PutOnSub action
99 handler, and also in InsertSub (so a command like PUT BIRD IN NEST sends a
100 Receive to the nest object). There’s a matching LetGo, generated by the
101 library from commands like TAKE KEY OFF COUNTER and REMOVE BIRD FROM
102 NEST. Receive and LetGo are examples of what’s called a :term:`fake
107 In "William Tell" we defined the ``quiver``, way back in
108 :ref:`possessions`, as an ``open container``. As things stand, the player
109 can put *any* held object, however inappropriate, into it. We could have
110 trapped the Receive action to ensure that arrows are the only acceptable
111 contents (recollect that ``~~``, to be read as "not", turns true into
112 false and vice versa):
114 .. code-block:: inform
118 print_ret "But it was a present from Hedwig, your wife.";
120 if (~~(noun ofclass Arrow))
121 print_ret "Only arrows -- clean arrows -- go in your quiver.";
124 Here, we intercept any attempt to place an item on the counter, and
125 translate it into an attempt to give that item to Benny. Part of the
126 game's plot depends on the player returning the toilet key to Benny, and
127 also paying him for his delicious cup of world-famous Cappuccino.
128 Putting the key and the money on the counter is a reasonable alternative
129 way for the player to accomplish this.
131 We've also mentioned some customers. These are treated as NPCs, reacting
132 to our hero’s performance.
134 .. code-block:: inform
136 Object customers "customers" cafe
137 with name 'customers' 'people' 'customer' 'men' 'women',
139 if (costume has worn)
140 "Most seem to be concentrating on their food, but some do
141 look at you quite blatantly. Must be the MIND-BEFUDDLING
142 colours of your costume.";
144 "A group of HELPLESS and UNSUSPECTING mortals, the kind
145 Captain FATE swore to DEFEND the day his parents choked on a
146 DEVIOUS slice of RASPBERRY PIE.";
150 if (costume has worn)
151 "People seem to MISTRUST the look of your FABULOUS costume.";
153 "As John Covarth, you attract LESS interest than Benny's
156 "There's no telling what sorts of MUTANT bacteria these
157 STRANGERS may be carrying around.";
159 "Mindless massacre of civilians is the qualification for
160 VILLAINS. You are SUPPOSED to protect the likes of these
164 "These people don't appear to be of the cooperative sort.";
166 number_of_comments 0, ! for counting the customer comments
168 if (location ~= cafe) return;
169 if (self.number_of_comments == 0) {
170 self.number_of_comments = 1;
171 print "^Nearby customers glance at your costume with open
174 if (random(2) == 1) { ! do this 50% of the time
175 self.number_of_comments = self.number_of_comments + 1;
176 switch (self.number_of_comments) {
177 2: "^~Didn't know there was a circus in town,~ comments one
178 customer to another. ~Seems like the clowns have the
180 3: "^~These fashion designers don't know what to do to show
181 off,~ snorts a fat gentleman, looking your way. Those
182 within earshot try to conceal their smiles.";
183 4: "^~Must be carnival again,~ says a man to his wife, who
184 giggles, stealing a peek at you. ~Time sure flies.~";
185 5: "^~Bad thing about big towns~, comments someone to his
186 table companion, ~is you get the damnedest bugs coming
188 6: "^~I sure WISH I could go to work in my pyjamas,~ says a
189 girl in an office suit to some colleagues. ~It looks SO
191 default: StopDaemon(self);
195 has scenery animate pluralname;
197 Let's go step by step. Our hero enters the café dressed as John Covarth,
198 but will eventually manage to change clothes in the toilet, and he'll
199 have to cross back through the café to reach the street and win the
200 game. The customers' ``description`` takes into consideration which
201 outfit the player character is wearing.
203 In "William Tell" we’ve seen a brief manifestation of the ``life``
204 property, but here we'll extend it a little. As we explained, ``life``
205 lets you intercept those actions particular to animate objects. Here we
206 trap ``Attack`` and ``Kiss`` to offer some customised messages for these
207 actions when applied to the customers. Also, we avoid conversation by
208 intercepting ``Ask``, ``Tell`` and ``Answer`` in order just to produce a
209 message which depends on the player character's attire.
211 One other feature of ``animate`` objects is the possibility of giving
212 them orders: BILL, SHAKE THE SPEAR or ANNIE, GET YOUR GUN . These
213 actions are dealt with in the ``orders`` property and, as with the
214 ``life`` property, the embedded routine can become quite complex if you
215 want your NPCs to behave in an interesting way. In this case, we don't
216 need the customers to perform tasks for us, so instead we provide a
217 simple rejection message, just in case the player tries to order people
220 Which leaves us with the ``daemon`` bit. A daemon is a property normally
221 used to perform some timed or repetitive action without the need of the
222 player’s direct interaction; for example, machines which work by
223 themselves, animals that move on their own, or people going about their
224 business. More powerfully, a daemon may take notice of the player’s
225 decisions at a particular moment, allowing for some interactive
226 behaviour; this is, however, an advanced feature that we won't use in
227 this example. A daemon gets a chance of doing something at the end of
228 every turn, typically to (or with) the object to which it’s associated.
229 In our example, the daemon triggers some sneers and nasty comments from
230 the customers once our hero comes out of the toilet dressed in Captain
233 To code a daemon, you need to do three things:
235 #. First, define a daemon property in the object’s body; the value of
236 the property is always an embedded routine.
238 #. However, daemons do nothing until you activate them. This is easily
239 achieved with the call :samp:`StartDaemon({obj_id})`, which may happen
240 anywhere (if you want some object's daemon to be active from the
241 beginning of the game,you can make the call in your Initialise
244 #. Once the daemon has finished its mission (if ever) you may stop it
245 with the call :samp:`StopDaemon({obj_id})`.
247 How does our particular daemon work? The appearance of our hero in full
248 crime-fighting wear will make the customers stare at him and make snarky
249 remarks. This must happen in the café room – the place where the
250 customers are -- so we need to make certain that the daemon does
251 something interesting only while the player stays in the right place
252 (and hasn’t wandered, say, back into the toilet):
254 .. code-block:: inform
256 if (location ~= cafe) return;
258 So if the location is not the café room (remember ~= means "not equal
259 to"), return without doing anything else; on this turn, there’s nothing
260 for the daemon to do. We use a plain ``return`` statement because the
261 value returned from a daemon doesn’t matter.
263 We have defined a customised local property, ``number_of_comments``, to
264 control the sequence of customers' remarks. When the Captain enters the
265 café room from the toilet for the first time, the value of the property
266 should be zero, so the statement block under the test:
268 .. code-block:: inform
270 if (self.number_of_comments == 0) {
271 self.number_of_comments = 1;
272 print "^Nearby customers glance at your costume with open
276 will happen only this once. What we intend is to output the text "Nearby
277 customers..." right after the startling entrance of our hero, setting up
278 the scene for the comments which are about to happen. Since we assign a
279 value of 1 to the property, the message will not be printed again.
280 Notice how we use an explicit ``print`` statement; the execution of the
281 daemon will continue normally to the next line.
283 We want the customers to indulge in witticisms once they see the
284 costumed Captain, but not on a completely predictable basis.
286 .. code-block:: inform
288 if (random(2) == 1) ...
290 ``random`` is an Inform routine used to generate random numbers or to
291 choose randomly between given choices; in the form
292 :samp:`random({expression})` it returns a random number between 1 and
293 ``expression`` inclusive. So our condition is actually stating: if a
294 random choice between 1 and 2 happens to be 1 then perform some action.
295 Remember that a daemon is run once at the end of every turn, so the
296 condition is trying to squeeze a comment from a customer roughly once
299 Next, we proceed as we have already seen in "William Tell", with a
300 switch statement to order the comments in a controlled sequence by
301 cunning use of our tailored local property, ``number_of_comments``. We
302 have written just five messages (could have been one or a hundred) and
303 then we reach the default case, which is a good place to stop the
304 daemon, since we have no more customers’ remarks to display.
306 Ah, but when does the daemon *start* functioning? Well, as soon as our
307 protagonist comes out of the toilet dressed in his multicoloured
308 super-hero pyjamas. Since we want to minimise the possible game states,
309 we’ll make some general rules to avoid trouble: (a) players will be able
310 to change only in the toilet; (b) we won’t let players change back into
311 street clothes; and (c) once players manage to step into the street thus
312 dressed, the game is won. So, we can safely assume that if players enter
313 the café in their Captain’s outfit, they’ll be coming from the toilet.
314 As a consequence of all this, we add an ``after`` property to the café
317 .. code-block:: inform
319 Room cafe "Inside Benny's cafe"
321 first_time_out false, ! Captain Fate's first appearance?
323 Go: ! The player has just arrived. Did he come from the toilet?
324 if (noun ~= s_obj) return false;
325 if (costume has worn && self.first_time_out == false) {
326 self.first_time_out = true;
327 StartDaemon(customers);
333 There are two useful techniques to detect when the player is entering or
334 leaving a room. We'll later see in detail how to deal with a player
335 trying to go away and how to avoid it if need be. For now, let’s just
336 mention that, in both cases, you have to intercept the ``Go`` action in
337 a room object; if you trap it in a ``before`` property, you’re checking
338 for departure from the room; if you trap it in an ``after`` property,
339 you’re checking for arrivals into the room. Right now we wish to know if
340 the player just came from the toilet, so we use an ``after`` property.
344 .. code-block:: inform
346 if (noun ~= s_obj) return false;
348 is telling the interpreter that we want to do something if the player
349 entered the room by typing a GO SOUTH command (this would normally mean
350 "coming from the north", but remember that nothing stops you from
351 connecting rooms without cardinal logic); the interpreter will apply
352 normal rules for the other available directions.
354 Then we check whether the player character is wearing the costume, in
355 which case it starts the ``daemon`` of the ``customers`` object. The use
356 of the local ``first_time_out`` property ensures that the condition is
357 ``true`` only once, so the statement block attached to it runs also
360 We've finished with the customers in the café. Now, we have the toilet
361 to the north which, for reasons of gameplay *and* decency, is protected
367 Door objects require some specific properties and attributes. Let's
368 first code a simple door:
370 .. code-block:: inform
372 Object toilet_door "toilet door" cafe
373 name name 'red' 'toilet' 'door',
375 "A red door with the unequivocal black man-woman
376 silhouettes marking the entrance to hygienic facilities.
377 There is a scribbled note stuck on its surface.",
381 has scenery door openable lockable locked;
383 We find this door in the café. We must specify the direction in which
384 the door leads and, as we have mentioned in the café's description, that
385 would be to the north. That’s what the ``door_dir`` property is for, and
386 in this case it takes the value of the north direction property
387 ``n_to``. Then we must tell Inform the identity of the room to be found
388 behind the door, hence the ``door_to`` property, which takes the value
389 of the toilet room -- to be defined later. Remember the café's
390 connection to the north, ``n_to toilet_door``? Thanks to it, Inform will
391 know that the door is in the way, and thanks to the ``door_to``
392 property, what lies beyond.
394 Doors *must* have the attribute ``door``, but beyond that we have a
395 stock of options to help us define exactly what kind of door we are
396 dealing with. As for containers, doors can be ``openable`` (which
397 activates the verbs OPEN and CLOSE so that they can be applied to this
398 object) and, since by default they are closed, you can give them the
399 attribute ``open`` if you wish otherwise. Additionally, doors can be
400 ``lockable`` (which sets up the LOCK/UNLOCK verbs) and you can make them
401 ``locked`` to override their default unlocked status. The verbs LOCK
402 and UNLOCK are expecting some kind of key object to operate the door.
403 This must be defined using the ``with_key`` property, whose value should
404 be the internal ID of the key; in our example, the soon-to-be-defined
405 ``toilet_key`` . If you don't supply this property, players won't be
406 able to lock or unlock the door.
408 This simple door definition has one problem, namely, that it exists only
409 in the café room. If you wish the door to be present also from the
410 toilet side, you can either (a) define another door to be found in the
411 ``toilet room``, or (b) make this one a two-sided door.
413 Solution (a) seems superficially straightforward, but then you have the
414 problem of keeping the states of the two doors – open/closed,
415 locked/unlocked -- in synch. In this scenario, where you can access the
416 toilet only through this door, that wouldn't be too complicated, since
417 you could leave the door object in the café room opened all the time,
418 regardless of what players do with the door object in the toilet room
419 and vice versa -- they are never going to see them at the same time. In
420 general terms, though, such inconsistencies lead to problems; solution
421 (a) is best ignored for most purposes.
423 Solution (b) is better, since you have only one door object to deal with
424 and its possible states affect both sides. However, the coding gets a
425 little bit complicated and you''ll have to define routines for most
428 .. code-block:: inform
430 Object toilet_door "toilet door"
431 with name 'red' 'toilet' 'door',
433 if (location == cafe)
434 "A red door with the unequivocal black man-woman silhouettes
435 marking the entrance to hygienic facilities. There is a
436 scribbled note stuck on its surface.";
438 "A red door with no OUTSTANDING features.";
440 found_in cafe toilet,
442 if (location == cafe) return n_to;
446 if (location == cafe) return toilet;
450 has scenery door openable lockable locked;
452 First of all, the door now needs a ``found_in`` property, since it's
453 going to be located both in the café and the toilet. The ``description``
454 checks which side of the door we are looking at – testing the current
455 value of the variable ``location``, which holds the room the player is
456 in -- because we have a scribbled note stuck on one side, but not on the
457 other. And the ``door_dir`` and ``door_to`` properties must use the same
458 trick, because we travel north from the café into the toilet, but south
459 from the toilet into the café.
461 Right now, the game will display "the toilet door" every time it needs
462 to refer to this object. It would be nice if we could somehow get the
463 game to distinguish between "the door to the toilet" and "the door to
464 the cafe", depending on the side we are facing. For this, a ``short_name
465 property`` is the thing. We have already talked about the external name
466 defined as part of an object's header information:
468 .. code-block:: inform
470 Object toilet_door "toilet door"
472 That ``toilet door`` will be the name displayed by the game at run-time
473 to refer to the door. With identical effect, this could also have been
476 .. code-block:: inform
479 with short_name "toilet door",
481 ``short_name`` is a property that supplies the external name of an
482 object, either as a string or an embedded routine. Normally, objects
483 retain the same external name throughout the game -- and the header
484 information method is perfect in that case -- but if it needs to change,
485 it's easy to write a routine as the value of ``short_name``:
487 .. code-block:: inform
490 with name 'red' 'toilet' 'door'
492 if (location == cafe) print "door to the toilet";
493 else print "door to the cafe";
499 Notice the ``return true`` at the end of the routine. You''ll recall
500 that the standard rule says "return false to carry on, true to take over
501 and stop normal execution”. In the case of ``short_name``, "carry on"
502 means "and now display the external name from the header information",
503 which is sometimes handy; for instance, you could write a ``short_name``
504 routine to prefix an object's external name with one of a range of
505 adjectives -- perhaps a shining/flickering/fading/useless lantern.
509 What's displayed if there isn't an external name in an object's header?
510 If you've read the section :ref:`compile-as-you-go`, you'll recall that
511 the interpreter simply uses the internal identifier within parentheses;
512 that is, with no external name and no ``short_name`` property, we might
515 You open the (toilet_door).
517 And the same principle applies if we were mistakenly to ``return
518 false`` from this short_name routine: we would get, first, the result
519 of our ``print`` statement, and then the standard rules would display
522 You open the door to the toilet(toilet_door).
524 Doors can get more complicated than this (no, please, don't throw our
525 guide out of the window). Here comes some optional deluxe coding to make
526 the door object a bit friendlier in game play, so you can skip it if you
529 Our door now behaves nicely at run-time. It can be locked and unlocked
530 if the player character has the right key; it can be opened and closed.
531 A sequence of commands to go into the toilet and lock the door behind
532 you would be: UNLOCK DOOR WITH KEY, OPEN DOOR, GO NORTH, CLOSE DOOR,
533 LOCK DOOR WITH KEY. After we are finished, let's go back to the café:
534 UNLOCK DOOR WITH KEY, OPEN DOOR, SOUTH. If the player is of the
535 fastidious kind: CLOSE DOOR, LOCK DOOR WITH KEY. This game features only
536 one door, but if it had three or four of them, players would grow
537 restless (at the very least) if they needed to type so many commands
538 just to go through a door. This is the kind of thing reportedly
539 considered as poor design, because the game is suddenly slowed down to
540 get over a simple action which involves no secrets or surprises. How
541 exciting can the crossing of an ordinary door be, after all?
543 If a few lines of code can make the life of the player easier, it's
544 worth a shot. Let's provide a few improvements to our toilet door in
545 ``before`` and ``after`` properties:
547 .. code-block:: inform
551 if (self hasnt locked || toilet_key notin player)
553 ks = keep_silent; keep_silent = true;
554 <Unlock self toilet_key>; keep_silent = ks;
557 if (self hasnt open) return false;
558 print "(first closing ", (the) self, ")^";
559 ks = keep_silent; keep_silent = true;
560 <Close self>; keep_silent = ks;
565 if (self has locked) return false;
566 print "You unlock ", (the) self, " and open it.^";
567 ks = keep_silent; keep_silent = true;
568 <Open self>; keep_silent = ks;
572 The basic idea here is to let the player who holds the key perform just
573 one action to both unlock *and* open the door (and, conversely, to close
574 *and* lock it). The relevant actions are ``Unlock`` and ``Open``, and
575 ``Lock`` ( ``Close`` is not necessary; if players just close the door we
576 shouldn’t assume that they want to lock it as well).
578 * **Open**: if the door isn't locked or the player doesn't hold the key,
579 keep going with the default ``Open`` action defined by the library.
580 That leaves a locked door and a player holding the key, so we
581 redirect processing to the ``Unlock`` action, giving as arguments the
582 door (self) and the toilet key. Since we are using single
583 angle-brackets ``<...>``, the action resumes after the unlocking is
584 done (note that the ``Unlock`` action also takes care of opening the
585 door). Finally, we ``return true`` to stop the library from trying to
586 open the door by itself.
588 * **Lock**: if the door is already closed, keep going with the standard
589 library ``Lock`` action. If not, tell players that we are closing the
590 door for them, redirect the action briefly to actually close it, and
591 then ``return false`` to let the ``Lock`` action proceed as before.
593 * **Unlock**: we place this action in the after property, so (let's
594 hope) the ``Unlock`` action has already happened. If the door is still
595 locked, something went wrong, so we ``return false`` to display the
596 standard message for an unsuccessful unlocking. Otherwise, the door is
597 now unlocked, so we inform the player that we are opening the door and
598 redirect the action to actually open it, returning ``true`` to
599 suppress the standard message.
601 In all processes there is a library variable called ``keep_silent``,
602 which can be either ``false`` (the normal state) or ``true``; when
603 ``true``, the interpreter does not display the associated message of an
604 action in progress, so we can avoid things like:
606 .. code-block:: transcript
609 You open the door to the toilet.
610 You unlock the door to the toilet and open it.
612 Although we want to set ``keep_silent`` to ``true`` for the duration of
613 our extra processing, we need to reset it afterwards. In a case like
614 this, good design practice is to preserve its initial value (which was
615 probably ``false``, but you should avoid risky assumptions); we use a
616 local variable ``ks`` to remember that initial setting so that we can
617 safely restore it afterwards. You’ll remember that a local variable in a
618 standalone routine is declared between the routine’s name and the
621 .. code-block:: inform
623 [ BeenToBefore this_room;
625 In exactly the same way, a local variable in an embedded routine is
626 declared between the ``[`` starting marker of the routine and the
629 .. code-block:: inform
633 You can declare up to fifteen variables this way -- just separated by
634 spaces -- which are usable only within the embedded routine. When we
637 .. code-block:: inform
641 we are actually making ``ks`` equal to whatever value ``keep_silent``
642 has (either ``true`` or ``false``; we actually don't care). We then set
643 ``keep_silent`` to ``true``, make the desired silent actions, and we
646 .. code-block:: inform
650 which restores the value originally stored in ``ks`` to ``keep_silent``.
651 The effect is that we manage to leave it as it was before we tampered
654 Well, that's about everything about doors. Everything? Well, no, not
655 really; any object can grow as complex as your imagination allows, but
656 we’ll drop the subject here. If you care to see more sophisticated doors,
657 check Exercises :dm4:`3 and 4 <s6.html#ex3>` in the |DM4|, where an
658 obliging door opens and unlocks by itself if the player simply walks in its
661 So far, we have the player in front of a locked door leading to the
662 toilet. A dead end? No, the description mentions a scribbled note on its
663 surface. This one should offer no problem:
665 .. code-block:: inform
667 Object "scribbled note" cafe
668 with name 'scribbled' 'note',
670 if (self.read_once == false) {
671 self.read_once = true;
672 "You apply your ENHANCED ULTRAFREQUENCY vision to the note
673 and squint in concentration, giving up only when you see the
674 borders of the note begin to blacken under the incredible
675 intensity of your burning stare. You reflect once more how
676 helpful it would've been if you'd ever learnt to read.
677 ^^A kind old lady passes by and explains:
678 ~You have to ask Benny for the key, at the counter.~^^
679 You turn quickly and begin, ~Oh, I KNOW that, but...~^^
680 ~My pleasure, son,~ says the lady, as she exits the cafe.";
683 "The scorched undecipherable note holds no SECRETS from
686 read_once false, ! has the player read the note once?
689 "No reason to start collecting UNDECIPHERABLE notes.";
693 Just notice how we change the description after the first time the
694 player examines the note, using the local property ``read_once`` created
695 just for this purpose. We don’t want the player to walk off with the
696 note, so we intercept the ``Take`` action and display something more in
697 character than the default message for scenery objects: "That's hardly
700 We've talked a lot about the toilet key; it seems about time to code it.
701 Originally, the key is in Benny's possession, and the player will have
702 to ask for it, just as the note explains. Although we'll define Benny in
703 detail throughout the next chapter, here we present a basic definition,
704 largely so that the key has a parent object.
706 .. code-block:: inform
708 Object benny "Benny" cafe
711 "A deceptively FAT man of uncanny agility, Benny entertains his
712 customers crushing coconuts against his forehead when the mood
714 has scenery animate male proper transparent;
716 Object toilet_key "toilet key" benny
717 with name 'toilet' 'key',
720 if (clothes has worn) print "the CRUCIAL key";
721 else print "the used and IRRELEVANT key";
725 "Your SUPRA PERCEPTIVE senses detect nothing of consequence
726 about the toilet key.",
729 "You SCAN your surroundings with ENHANCED AWARENESS,
730 but fail to detect any key.";
732 "Benny is trusting you to look after that key.";
735 While Benny has the key, there's logically no way to examine it (or
736 perform any other action involving it), but we want to prevent the
737 interpreter from objecting that ``You can't see any such thing``. We've
738 made the ``toilet_key`` a child of the ``benny`` object, and you can see
739 that Benny's got a ``transparent`` attribute; this means that the key is
740 in scope, and enables the player to refer to it without the interpreter
741 complaining. Because Benny also has an ``animate`` attribute, the
742 interpreter would normally intercept a TAKE KEY action with "That seems
743 to belong to Benny"; however, the same wouldn't apply to other commands
744 like TOUCH KEY and TASTE KEY . So, to prevent any interaction with the
745 key while it’s in Benny’s pockets, we define a ``before`` property.
747 .. code-block:: inform
751 "You SCAN your surroundings with ENHANCED AWARENESS,
752 but fail to detect any key.";
754 "Benny is trusting you to look after that key.";
757 All of the ``before`` properties that we've so far created have contained
758 one or more labels specifying the actions which they are to intercept;
759 you'll remember that in "William Tell" we introduced the ``default`` action
760 (see :ref:`props-class`) to mean "any value not already catered
761 for". There's one of those labels here, for the Drop action, but that's
762 preceded by a piece of code that will be executed at the start of *every*
763 action directed at the key. If it’s still in Benny’s possession, we display
764 a polite refusal; if the player has it then we prevent careless disposal;
765 otherwise, the action continues unhindered.
767 (In fact, the hat-on-a-pole ``Prop`` introduced in :ref:`south-side` had
768 this all-exclusive ``before`` property:
770 .. code-block:: inform
774 print_ret "You're too far away at the moment.";
777 It would have behaved exactly the same if we'd omitted the ``default``
778 label, as we do here for Benny's key.)
780 Another small innovation here: the ``invent`` library property (we
781 didn’t make it up) which enables you to control how objects appear in
782 inventory listings, overriding the default. Left to itself, the
783 interpreter simply displays the object’s external name, preceded either
784 by a standard article like "a" or "some", or one specifically defined in
785 the object's ``article`` property. Here we replace "the toilet key" with
786 one of two more helpful descriptions, making it a most valuable object
787 in the eyes of John Covarth, and something to be despised haughtily by
788 Captain Fate once it's of no further use to him.
790 When we had players in the street, we faced the problem that they might
791 choose to examine the café from the outside. While it's unlikely that
792 they'll try to examine the toilet room from the outside, it takes very
793 little effort to offer a sensible output just in case:
795 .. code-block:: inform
797 Object outside_of_toilet "toilet" cafe
798 with name 'toilet' 'bath' 'rest' 'room' 'bathroom' 'restroom',
801 if (toilet_door has open) {
806 "Your SUPERB deductive mind detects that the DOOR is
809 if (toilet_door has open)
810 "A brilliant thought flashes through your SUPERLATIVE
811 brain: detailed examination of the toilet would be
812 EXTREMELY facilitated if you entered it.";
814 "With a TREMENDOUS effort of will, you summon your
815 unfathomable ASTRAL VISION and project it FORWARD
816 towards the closed door... until you remember that it's
817 Dr Mystere who's the one with mystic powers.";
819 <<Open toilet_door>>;
821 <<Close toilet_door>>;
823 "That would be PART of the building.";
825 has scenery openable enterable;
827 As with the ``outside_of_cafe`` object, we intercept an ``Enter``
828 action, to teleport players into the toilet room if they type ENTER
829 TOILET (or to display a refusal if the toilet door is closed). Players
830 may try to EXAMINE TOILET; they'll get a different message if the door
831 is open -- we invite them to enter it -- or if it's closed. OPEN TOILET
832 and CLOSE TOILET inputs are redirected to ``Open`` and ``Close`` actions
833 for the toilet door; remember that the double angle-brackets imply a
834 ``return true``, so that the action stops there and the interpreter does
835 not attempt to ``Open`` or ``Close`` the ``outside_of_toilet`` object
836 itself after it has dealt with the door.
838 You're right: the toilet looms large in this game (we blame it on early
839 maternal influences). We’ve introduced an ambiguity problem with the
840 ``outside_of_toilet`` object, and we'll need some help in fixing it.