§17.7. Understanding any, understanding rooms
Ordinarily, if we write
Understand "manipulate [something]".
then the "[something]" will only match what is within reach or sight: this is the concept of "scope", which is what prevents a player from spookily acting on objects from a distance. The parser itself prevents the manipulation rules from ever being invoked on such distant items, which is as it should be.
Sometimes, though, we positively want to allow this possibility. If we use the special word "any", as in
Understand "manipulate [any door]".
then any door, anywhere in the model world, can be allowed in the player's command. (Of course, the manipulation rules may not do what the player hopes: all that has happened is that the command is now possible to type.) The "any" can be followed by any description of items or rooms, and the latter opens up new possibilities, since rooms are ordinarily never allowed to be named in the player's commands.
For example, the following gives the player the ability to walk between rooms without giving explicit directions of movement.
Going by name is an action applying to one thing.
Carry out going by name: say "You walk to [the noun]."; move the player to the noun.
Understand "go to [any adjacent visited room]" as going by name.
(This is really only a sketch: in a finished work, "go to" would produce helpful errors if non-adjacent but visited rooms were named, and we might also worry about rules applying to movement, because the method above will circumvent them.)
As might be expected, "[anything]" means the same as "[any thing]"; "[anybody]" and "[anyone]" mean the same as "[any person]"; and "[anywhere]" means the same as "[any room]".
![]() | Start of Chapter 17: Understanding |
![]() | Back to §17.6. Actions applying to kinds of value |
![]() | Onward to §17.8. Understanding names |
Suppose that, contrary to the usual rules of interactive fiction, we want to allow the player to discover the locations of things he hasn't actually seen yet:
The holder of the noun can be a room, a supporter, or a container: the phrase is not picky. We would want to be a little more careful if it were ever possible for an item to have been "removed from play" in our game, since then the holder could be nothing, and that would have odd results. In this particular example, though, that will not arise. And that's it, as far as the find command goes. The rest is local color.
If we want to have the key found in different places when the game is replayed:
|
|
Suppose that, contrary to the usual rules of interactive fiction, we want to allow the player to discover the locations of things he hasn't actually seen yet:
The holder of the noun can be a room, a supporter, or a container: the phrase is not picky. We would want to be a little more careful if it were ever possible for an item to have been "removed from play" in our game, since then the holder could be nothing, and that would have odd results. In this particular example, though, that will not arise. And that's it, as far as the find command goes. The rest is local color.
If we want to have the key found in different places when the game is replayed:
Suppose that, contrary to the usual rules of interactive fiction, we want to allow the player to discover the locations of things he hasn't actually seen yet:
The holder of the noun can be a room, a supporter, or a container: the phrase is not picky. We would want to be a little more careful if it were ever possible for an item to have been "removed from play" in our game, since then the holder could be nothing, and that would have odd results. In this particular example, though, that will not arise. And that's it, as far as the find command goes. The rest is local color.
If we want to have the key found in different places when the game is replayed:
|
|