Inform 7 Home Page / Documentation
§17.16. Understanding things by their relations
Sometimes it makes sense for the name of something to involve the names of other things to which it is related. For instance, if we say TAKE THE BOTTLE OF WINE, we mean that the bottle currently contains wine - if it were the very same bottle containing water, we would call it something else.
For names which must involve related names, a special form of token is provided. For instance, we could say:
A box is a kind of container. Understand "box of [something related by containment]" as a box.
The Toyshop is a room. The red box is a box in the Toyshop. Some crayons are in the red box.
and now TAKE BOX OF CRAYONS will work, because CRAYONS matches against "[something related by containment]" for the red box - or it does for as long as the crayons are there. We can have similar matches against relations of all kinds, but have to name the relation explicitly. (See the examples at the end of this section for plenty of cases.)
We can also reverse the sense. If we write:
A box is a kind of container. Understand "box in [something related by reversed containment]" as a box.
The Toyshop is a room. The crate and the hammock are in the Toyshop. In the crate is a box. In the hammock is a box.
then TAKE THE BOX IN THE HAMMOCK will work: here, the relation goes the other way, because the box is being contained by the other-named item, rather than doing the containing.
|Start of Chapter 17: Understanding|
|Back to §17.15. Understanding things by their properties|
|Onward to §17.17. Context: understanding when|
It's fairly common that we want to be able to refer to a container in terms of what it has in it: a bottle of wine, a salt shaker, a chicken sandwich. The player is free to remove the contents again, and the object will go back to using its usual name:
Rule for printing the name of the taco shell while not inserting or removing:
if the taco contains something (called filling), say "[filling] taco";
otherwise say "taco shell";
omit contents in listing.
By default, when something is not present, Inform does not allow a player to refer to it. But there are times when we might like to acknowledge that the thing mentioned in a command does exist somewhere in the game; it just happens not to be on hand right now.
One way to do this is to make an object that appears everywhere and responds to the name of its owner only when the owner itself is not in view.
We make the ghost a person rather than some other kind of thing so that it will be able to respond to commands such as KISS BOB or (even trickier) BOB, JUMP: if Inform did not recognize the ghost as an animate creature, it would not accept such input.
This is, technically, an assembly -- except instead of saying that every device has a button part, or that there are three daffodils in every garden room, the assembly is based on a non-physical relation that we just designed.
Based on the "representation" relation, we now devise a conditional relation that applies only when the represented thing is not itself in view:
Further complications of this example might require that the player meet a character before being able to refer to him or her.
Here we expand on the simple examples When? and Whence?; this time we want the player to be able to refer to doors by their directions, as in "the west door" when the door in question does in fact lead west.
The initial appearance of a door is usually "Nearby [an item described] leads [if the other side of the item described is visited][direction of the item described from the location] to [other side of the item described][otherwise][direction of the item described from the location][end if]."
Direction-relevance relates a door (called X) to a direction (called Y) when the direction of X from the location is Y. The verb to be directionally-relevant to means the direction-relevance relation.
As an added touch, we respond also to the case where the player postulates a door in some direction when there is no such thing at the moment:
We start by creating a camera and a photograph object. As usual when we want to have a kind of object that can be dispensed in bulk, we start off with a bunch of identical instances of the object out of play (in this case, kept in an out-of-play container called "film roll"); we can then move them into play and give them characteristics when they're needed.
Each photograph can depict exactly one thing -- we're assuming that the player is not a landscape photographer here -- so we create a relation to indicate what is shown by each photograph. We'll then use that relation to determine how photographs are described, named, and parsed:
This allows the player to refer to any photograph by its subject: useful if we have a large number of them.
Now we create an action to let the player use the camera and generate these photograph objects:
Understand "photograph [something] with [camera]" as photographing. Understand "photograph [something] with [something preferably held]" as photographing. Photographing is an action applying to one visible thing and one carried thing, requiring light.
Now we use two activities from the Activities chapter to describe the photographs to the player more elegantly:
After printing the plural name of a photograph (called target):
let N be the holder of the target;
say " of [a list of things which are shown by photographs which are held by N]";
if the number of things which are shown by photographs which are held by N is greater than one, say " (variously)".
And finally we provide a brief scenario to give the player something to take pictures of:
Test me with "photograph degas / i / photograph degas / i / x photograph of degas / photograph me / x photograph of me / i / photograph vase / photograph camera / photograph collection / g / i / test more".