§9.2. Bags, Bottles, Boxes and Safes
The kind "container" allows one thing to contain others. Things are sometimes containers automatically, sometimes by instruction:
The match is in the matchbox. The bucket is a container.
The matchbox, like the bucket, is a container. Containers come in all sizes and have a variety of behaviours, mainly controlled by the properties we give them: they can be "open" or "closed", "opaque" or "transparent" (when closed), "openable" or not, "lockable" or not, "enterable" or not. The basic ideas of containment are to do with carrying and sometimes hiding the contents, and Inform makes this easy. Allowing for locking and unlocking is again straightforward:
The strongbox is a locked container. The little steel key unlocks the strongbox.
Two built-in extensions enhance and modify the behavior of locks and keys: Locksmith automates a number of steps, automatically unlocking doors when trying to open them (for instance). Skeleton Keys allows us to define multiple keys that unlock the same object, rather than being restricted to one matching key per item.
For a container with a combination lock, rather than a key, see Safety; for a more sophisticated safe requiring digits dialed over multiple turns, see Eyes, Fingers, Toes.
Trachypachidae Maturin 1803 provides a bottle that is stoppered with a cork: when it is closed, the cork is part of the bottle, but otherwise the cork becomes a separate object we can carry around.
The normal assumption is that there is no problem with any two portable items being carried together, but in reality they may affect each other. (For effects like magnetism, or getting each other wet, or setting each other on fire, see the Physics chapter.) Here is a cat which, if boxed up with one or more items of food, will eat something each turn until all is gone:
The player carries a wicker basket and a scarlet fish. The cat is an animal in the wicker basket. The fish is edible.
Every turn when the cat is in a container (called the bag) and something edible (called the foodstuff) is in the bag:
remove the foodstuff from play;
say "With mingled sounds of mewing and chomping, the cat nibbles up [the foodstuff]."
The examples below provide subtler effects, adapting text to the current situation. In Cinco, the container's name changes depending on what it contains: putting beef in a taco allows the player to call it a SHREDDED BEEF TACO. In Unpeeled and Shipping Trunk, the description of something inside a container changes according to other things are alongside it. This is taken further in Hudsucker Industries, which describes the contents of a container as a group.
Finally, any action that destroys a container has to consider what to do with the things inside. Fallout Enclosure demonstrates a zapping action that destroys cash registers and shelves but leaves their contents tidily behind.
See Liquids for a SHAKE command that makes containers rattle when there are contents
See Glass and Other Damage-Prone Substances for opening containers by cutting into them
See Fire for fire damage that spreads between containers and their contents, leaving fireproof objects intact
See Volume, Height, Weight for containers breaking under the weight of their contents
See Heat for keeping things warm in insulated containers
See Furniture for chests with lids that can support other objects
See Modifying Existing Commands for ways to allow the player to unlock with a key he isn't currently holding
![]() | Start of Chapter 9: Props: Food, Clothing, Money, Toys, Books, Electronics |
![]() | Back to §9.1. Food |
![]() | Onward to §9.3. Clothing |
|
|
|
|
|
|
In this scenario, the player starts with a bag full of unsorted letters. These can be polite or rude, but he won't know which until he has examined them. What's more, he is allowed to sort the letters, in which case a group of letters will be shown as (for instance) "two polite letters"; but a group of mixed letters, even if they have all been read, will be called "unsorted letters". Further, the player should be allowed to refer to sorted letters by tone, but not unsorted letters. To do this, we'll need printing the name... and printing the plural name..., as well as some special understanding rules.
Now, there's a good bit of interaction to streamline. We intend that the player will be taking letters from the satchel, reading them, and putting them (perhaps grouped) into boxes. Our interaction rules should assist in this process as much as possible. To start with, the player will be most likely to examine letters he hasn't read yet:
The rules about taking are more subtle: the player is more likely to want to take an ungrouped letter than a grouped one; he is more likely to want one from the satchel than not; and he is most unlikely to want to take a letter (grouped or ungrouped) that he is already holding.
And finally, we will assume by default that anything other than examining or taking is most likely to apply to a letter he's already identified:
And we would also like to understand properties under the same circumstances as printing -- a letter will be identifiable as "polite" if it's already been read and it is either by itself or in a sorted stack of polite letters, but otherwise not. What's more, to make it possible to disambiguate commands in the other direction, we'll call any unsorted letter "random", to represent that the player doesn't know what it is.
That last "repeat" is merely a device to shuffle the order of items in the satchel so that the player will not always encounter the letters in a neatly presorted order, despite our defining them that way. (Of course, that means that the test produced by TEST ME cannot be very exciting...) |
|
In this scenario, the player starts with a bag full of unsorted letters. These can be polite or rude, but he won't know which until he has examined them. What's more, he is allowed to sort the letters, in which case a group of letters will be shown as (for instance) "two polite letters"; but a group of mixed letters, even if they have all been read, will be called "unsorted letters". Further, the player should be allowed to refer to sorted letters by tone, but not unsorted letters. To do this, we'll need printing the name... and printing the plural name..., as well as some special understanding rules.
Now, there's a good bit of interaction to streamline. We intend that the player will be taking letters from the satchel, reading them, and putting them (perhaps grouped) into boxes. Our interaction rules should assist in this process as much as possible. To start with, the player will be most likely to examine letters he hasn't read yet:
The rules about taking are more subtle: the player is more likely to want to take an ungrouped letter than a grouped one; he is more likely to want one from the satchel than not; and he is most unlikely to want to take a letter (grouped or ungrouped) that he is already holding.
And finally, we will assume by default that anything other than examining or taking is most likely to apply to a letter he's already identified:
And we would also like to understand properties under the same circumstances as printing -- a letter will be identifiable as "polite" if it's already been read and it is either by itself or in a sorted stack of polite letters, but otherwise not. What's more, to make it possible to disambiguate commands in the other direction, we'll call any unsorted letter "random", to represent that the player doesn't know what it is.
That last "repeat" is merely a device to shuffle the order of items in the satchel so that the player will not always encounter the letters in a neatly presorted order, despite our defining them that way. (Of course, that means that the test produced by TEST ME cannot be very exciting...) |
|