§3.5. Doors, Staircases, and Bridges
Inform's "door" kind provides for a tangible thing which comes between one room and another. A door can be open or closed, and openable or not: it can be locked or unlocked, and lockable or not. Here we create a conventional door, a natural gap in the rocks, and a (fixed in place) wooden ladder:
The fire door is an open door. The fire door is east of the Projection Booth and west of the Fire Escape.
The narrow crevice is an open unopenable door. The crevice is east of the Col du Prafleuri and west of Rocky Knoll Above Arolla.
The wooden ladder is an open unopenable door. The ladder is above the Stableyard and below the Hay Loft.
Most doors are visible from both sides: they are single objects but present in two rooms at once, which raises a number of complications. Inform normally uses the same description looking from each way, which is not very interesting: When? and Whence? demonstrate neat ways to describe the two sides differently, and Whither? adds the option for the player to refer to doors as "the west door" and "the east door" automatically.
Neighbourhood Watch goes further by making a door behave differently on each side: from the "outside" you need a key, but "inside" it opens on a latch. Finally, Garibaldi 1 shows how to access information about the two sides of a door.
Higher Calling demonstrates doors which automatically open as needed: though using the Inform extension Locksmith by Emily Short is probably easier and better. Elsie, conversely, demonstrates a door that closes one turn after the player has opened it.
Certain complications apply when characters other than the player have to see and interact with doors that exist in other rooms. Wainwright Acts demonstrates the syntax needed to handle this technically quirky situation.
Something Narsty and Hayseed provide a "staircase" kind useful for vertically arranged, always-open doors like staircases and (fixed in place) ladders.
One Short Plank implements a precarious plank bridge across a chasm as an open unopenable door.
See Windows for climbing through a window from one room to another
See Ropes for portable connections between rooms, much of the development of which could be adapted to handle portable ladders. "Doors" are never allowed to move
See Magic (Breaking the Laws of Physics) for a hat that lets the player walk through closed doors
See Modifying Existing Commands for ways to allow the player to unlock with a key he isn't currently holding
|
|
|
|
|
|
Suppose we want a locked door that can be opened with a key, but is also openable by hand without a key from one side only. We start by defining an ordinary lockable door and the key that controls it:
The next part is going to require that we modify the normal operation of the "lock" command. "Lock" ordinarily requires that the player supply two objects: a thing he wants to unlock, and the key he wants to use on it. The full command is LOCK DOOR WITH THE KEY, and Inform will not accept simply LOCK DOOR as locking. Therefore, we're going to need to create our own new variant on the lock verb (and the unlock verb, while we're at it). The full procedure for this is laid out in the chapters on Action and Understanding, but here is an example:
Here we've created a new action -- locking something without a key -- and we've told Inform to understand LOCK DOOR as this action, rather than an incomplete command to LOCK DOOR WITH SOMETHING. Now we add some instructions so that the game will not let us use this keyless unlocking command unless we're in the right place or are properly equipped:
This check rule is performed before the keyless locking action succeeds. The first thing we do is try to use the key if the player is outside and has the key: this way, LOCK DOOR will turn automatically into LOCK DOOR WITH THE KEY, under circumstances where that is both possible and necessary. The second thing is to check whether the player is outside but keyless, and, if so stop the action from being performed successfully. Here we print a failure message followed by the word "instead", which tells Inform that we've substituted some other outcome for the usual performance of the action. Now we're reasonably sure that the player is only locking keylessly in the case that he is inside the Studio. (We might have to do a more thorough check for this if there were more than two rooms, but as it is, the player can only be in the Stairwell or in the Studio, so if we have ruled out the Stairwell, we are safe.) So now we want to add what happens when locking-without-a-key command succeeds:
That's it. We've just told Inform to make the door be locked. "Now..." syntax will be explained more thoroughly in the chapter on change. But we still haven't described to the player what just happened, so let's provide a description of that, too:
And now we have to do a similar set of things for unlocking:
Some (but not all) of this work is done for you if you like by the Locksmith extension. If you prefer, you can include that extension, then follow the documentation in order to implement the remainder of the scenario. Locksmith takes care of implementing the additional locking and unlocking actions, and provides some other conveniences. |
|
Suppose we want a locked door that can be opened with a key, but is also openable by hand without a key from one side only. We start by defining an ordinary lockable door and the key that controls it:
The next part is going to require that we modify the normal operation of the "lock" command. "Lock" ordinarily requires that the player supply two objects: a thing he wants to unlock, and the key he wants to use on it. The full command is LOCK DOOR WITH THE KEY, and Inform will not accept simply LOCK DOOR as locking. Therefore, we're going to need to create our own new variant on the lock verb (and the unlock verb, while we're at it). The full procedure for this is laid out in the chapters on Action and Understanding, but here is an example:
Here we've created a new action -- locking something without a key -- and we've told Inform to understand LOCK DOOR as this action, rather than an incomplete command to LOCK DOOR WITH SOMETHING. Now we add some instructions so that the game will not let us use this keyless unlocking command unless we're in the right place or are properly equipped:
This check rule is performed before the keyless locking action succeeds. The first thing we do is try to use the key if the player is outside and has the key: this way, LOCK DOOR will turn automatically into LOCK DOOR WITH THE KEY, under circumstances where that is both possible and necessary. The second thing is to check whether the player is outside but keyless, and, if so stop the action from being performed successfully. Here we print a failure message followed by the word "instead", which tells Inform that we've substituted some other outcome for the usual performance of the action. Now we're reasonably sure that the player is only locking keylessly in the case that he is inside the Studio. (We might have to do a more thorough check for this if there were more than two rooms, but as it is, the player can only be in the Stairwell or in the Studio, so if we have ruled out the Stairwell, we are safe.) So now we want to add what happens when locking-without-a-key command succeeds:
That's it. We've just told Inform to make the door be locked. "Now..." syntax will be explained more thoroughly in the chapter on change. But we still haven't described to the player what just happened, so let's provide a description of that, too:
And now we have to do a similar set of things for unlocking:
Some (but not all) of this work is done for you if you like by the Locksmith extension. If you prefer, you can include that extension, then follow the documentation in order to implement the remainder of the scenario. Locksmith takes care of implementing the additional locking and unlocking actions, and provides some other conveniences. |
|
|
|
|