Section 12: Doors

Contents Back Forward | ### 12. Doors
| Standing in front of you to the north, however, is a door surpassing anything you could have imagined. For starters, its massive lock is wrapped in a dozen six-inch thick iron chains. In addition, a certain five-headed monster... ...Marc Blank and P. David Lebling, 'Enchanter' O for doors to be open and an invite with gilded edges To dine with Lord Lobcock and Count Asthma. ...W. H. Auden (1907--1973), Song A useful kind of object is a `door`. This need not literally be a door: it might be a rope-bridge or a ladder, for instance. To set up a `door`: (a) -- give the object the `door` attribute; (b) -- set its `door_to` property to the destination; (c) -- set its `door_dir` property to the direction which that would be, such as `n_to`; (d) -- make the room's map connection in that direction point to the door itself. \PAR For example, here is a closed and locked door, blocking the way into the 'Ruins' shrine:
    Object Corridor "Stooped Corridor"
      with description "A low, square-cut corridor, running north to south,
               stooping you over.",
           n_to Square_Chamber,
           s_to StoneDoor;
    Object -> StoneDoor "stone door"
      with description "It's just a big stone door.",
           name "door" "massive" "big" "stone" "yellow",
           when_closed
               "Passage south is barred by a massive door of yellow stone.",
           when_open
               "The great yellow stone door to the south is open.",
           door_to Shrine,
           door_dir s_to,
           with_key stone_key
      has  static door openable lockable locked;
Note that the door is `static` -- otherwise the player could pick it up and walk away with it! The properties `when_closed` and `when_open` give descriptions appropriate for the door in these two states. Doors are rather one-way: they are only really present on one side. If a door needs to be accessible (openable and lockable from either side), a neat trick is to make it present in both locations and to fix the `door_to` and `door_dir` to the right way round for whichever side the player is on. Here, then, is a two-way door:
    Object -> StoneDoor "stone door"
      with description "It's just a big stone door.",
           name "door" "massive" "big" "stone" "yellow",
           when_closed
               "The passage is barred by a massive door of yellow stone.",
           when_open
               "The great yellow stone door is open.",
           door_to
           [;  if (location==Corridor) return Shrine; return Corridor; ],
           door_dir
           [;  if (location==Shrine) return n_to; return s_to; ],
           with_key stone_key,
           found_in  Corridor  Shrine,
      has  static door openable lockable locked;
where `Corridor` has `s_to` set to `StoneDoor`, and `Shrine` has `n_to` set to `StoneDoor`. The door can now be opened, closed, entered, locked or unlocked from either side. We could also make `when_open` and `when_closed` into routines to print different descriptions of the door on each side. At first sight, it isn't obvious why doors have the `door_dir` property. Why does a door need to know which way it faces? The point is that two different actions cause the player to go through the door. Suppose the door is in the south wall. The player may type "go south'', which directly causes the action `Go s_obj`. Or the player may "enter door'' or "go through door'', causing `Enter the_door`. Provided the door is actually open, the `Enter` action then looks at the door's `door_dir` property, finds that the door faces south and generates the action `Go s_obj`. Thus, however the player tries to go through the door, it is the `Go` action that finally results. This has an important consequence: if you put `before` and `after` routines on the `Enter` action for the `StoneDoor`, they only apply to a player typing "enter door" and not to one just typing "south". So one safe way is to trap the `Go` action. A neater method is to put some code into a `door_to` routine. If a `door_to` routine returns 0 instead of a room, then the player is told that the door "leads nowhere'' (like the famous broken bridge of Avignon). If `door_to` returns 1, or 'true', then the library stops the action on the assumption that something has happened and the player has been told already.
| EXERCISE 13: (link to the answer)
| Create a plank bridge across a chasm, which collapses if the player walks across it while carrying anything.
| REFERENCES: 'Advent' is especially rich in two-way doors: the steel grate in the streambed, two bridges (one of crystal, the other of rickety wood) and a door with rusty hinges. See also the iron gate in 'Balances'.

Contents / Back / Forward
Chapter I / Chapter II / Chapter III / Chapter IV / Chapter V / Chapter VI / Appendix

Mechanically translated to HTML from third edition as revised 16 May 1997. Copyright © Graham Nelson 1993, 1994, 1995, 1996, 1997: all rights reserved.