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;

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;

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.