Inform 7 Home Page / Documentation
Chapter 9: Props: Food, Clothing, Money, Toys, Books, Electronics
§9.1. Food; §9.2. Bags, Bottles, Boxes and Safes; §9.3. Clothing; §9.4. Money; §9.5. Dice and Playing Cards; §9.6. Reading Matter; §9.7. Painting and Labeling Devices; §9.8. Simple Machines; §9.9. Televisions and Radios; §9.10. Telephones; §9.11. Clocks and Scientific Instruments; §9.12. Cameras and Recording Devices
|Contents of The Inform Recipe Book|
|Chapter 8: Vehicles, Animals and Furniture|
|Chapter 10: Physics: Substances, Ropes, Energy and Weight|
|Indexes of the examples|
Inform provides an either/or property called "edible" and an action, "eating", for consuming edible things:
The lardy cake is edible. After eating the lardy cake, say "Sticky but delicious."
For eating something not immediately to hand, see Lollipop Guild. Delicious, Delicious Rocks, conversely, adds a sanity check which prevents the player from automatically taking inedible things only to be told they can't be eaten.
Inform does not normally simulate taste or digestion, but to provide foods with a range of flavours, see Would you...?; to make eating different foods affect the player differently, see Stone, or for the extreme case of poisoning foods, Candy. In MRE, hunger causes the player problems unless he regularly finds and eats food.
See Liquids for things to drink
See Dispensers and Supplies of Small Objects for a pizza buffet table from which the player may take all the slices he wants
|Start of Chapter 9: Props: Food, Clothing, Money, Toys, Books, Electronics|
|Back to Chapter 8: Vehicles, Animals and Furniture: §8.5. Kitchen and Bathroom|
|Onward to §9.2. Bags, Bottles, Boxes and Safes|
For instance, if we want to give some objects a flavor:
Things are, in general, not edible by default, so we have to make them edible specifically in order to allow them to be eaten by the player. Here we've defined food to be edible by default, and we have given it a standard piece of flavor text.
Note that we use "if the noun provides a flavor..." to make sure that the property exists before attempting to use it. Otherwise, there is the risk that we will try to print a property that does not exist, resulting in errors in the game.
We will only get the "It's [noun]-flavored." response if we successfully eat something that is not a food and does not have flavor text. To test this feature, let's suppose something that isn't exactly food but can theoretically be chewed on:
Suppose we want to give the player a bag of candies, of which a random one is poisonous. We can pick which one should be poisoned at the start of play, like this:
Many older interactive fiction games required the player to find food and eat on a regular basis in order to avoid death. This effect was often unrealistic (since most people can survive much longer than a few hours without eating) and is often seen as an annoyance. However, for the sake of argument, suppose that we do want to construct a hunger-and-death system.
To make things a little more interesting, we will postulate that different foods are differently filling, so that if the player manages to find something really caloric, he is off the hook on his hunger search for a while.
We will also implement the system so that the player gets messages when he is hungry, then dies a short time later. (The times involved are ludicrously short, but this allows us to see the effects within a simple example. In a real game we would want to allow a considerably longer timer for the hunger to play out.)
First, a little scene-setting:
When play begins:
now the right hand status line is "[time of day]";
say "The procedure was painless at first: increased strength was the first sign, followed by a sensation of delayed time, as though everyone around you moved more slowly. Your ability to dodge and perform feats of agility doubled, then trebled. You were heralded as a triumph of medicine. They told you there would be no side effects worth speaking of.
The Base Camp Larder is a room. "This room has been reinforced after each incident -- and there have been dozens in the last two months -- so that it now rivals Fort Knox. Only your new skill and speed enabled you to dodge the motion sensors, knock out the computerized security system, fool the retinal scanner, and punch a hole in the steel containment grating. But you're inside now."
Now we define our food, and add some special instructions for what happens to our hunger counters when the food is eaten:
The Larder contains an apple, a candy bar, and a large plate of pasta. The apple, the candy bar, and the pasta are food. The satisfaction period of the apple is 2 minutes. The satisfaction period of the pasta is 125 minutes.
The first of those two phrases, "now the player is replete", causes the player to cease to be hungry; the second one sets up a future event in which the hunger sets in again. The length of time until that event depends on how satisfying the specific food is. Now we define that event:
Note "if the player is hungry": it is possible that the starvation event will be set up but the player will eat before it occurs; in that case, we want it not to take effect.
And now, since we really ought to give the player some warning of what is happening to him:
Table of Hunger Complaints
"Gosh, you're starving."
"It feels as though you haven't eaten in days. Weeks, almost."
"The world seems to slow down and everything becomes sharper and brighter. You are a hunter, a hunter of foodstuffs."
"You find yourself staring at [the random visible thing that is not the player] and wondering how it would taste."
A thing can have a rule as a property, if we like. Here we are going to allow the player to make a soup whose effects will depend on its ingredients. Each ingredient will have its own "food effect" rule, to be followed when the food is eaten.
Note that there are other, slightly less cumbersome ways to do the same thing -- we will see in the chapter on Rulebooks that we could make a "food effects rulebook" and then write a number of rules such as "food effects rule for carrots" or "food effects rule for the stone". Nonetheless, we demonstrate rules-as-properties here for the sake of thoroughness.
Carry out eating a food:
if a food is part of the noun:
repeat with item running through things which are part of the noun:
if item is a food, follow the food effect of the item;
follow the food effect of the noun.
To say diagnosis of (victim - a person):
if the victim is ill:
say "You are ill.";
say "You are healthy. ";
if the victim is awake, say "You are wide awake. ";
otherwise say "You are sleepy. ";
if the victim is bright-eyed, say "Your eyesight is clear. ";
otherwise say "Your eyesight is dim. ";
if the victim is weak, say "You are weak. ";
otherwise say "You are strong. ";
if the victim is hungry, say "You are hungry.";
otherwise say "You are well-fed."
And now to provide some particular foods:
Instead of examining the broth:
if something is part of the broth, say "In the broth, [a list of things that are part of the broth] float[if exactly one thing is part of the broth]s[end if].";
otherwise say "It is just a thin broth with no other ingredients."
And the following is a relatively unimportant nicety:
Delicious, Delicious Rocks
In some cases, we may want to add new stages to action processing. One possibility is a stage where we check the sanity of what the player is trying to do before executing any of the other commands; so that we avoid, for instance
Here is how we might insert such a stage in our action processing, using rulebook manipulation.
Notice that now Inform does not try taking the rock before rejecting the player's attempt to eat it.
It is of course possible to get the same effect with
...and in a small game with few rules, there's not much reason to add an extra stage. The ability to modify the stages of action processing becomes useful when we have a fairly large game with sophisticated modeling and want to be sure that some kinds of message (such as the sanity-check) are always handled before other things that we might be doing at the before stage (such as generating implicit actions like opening doors before going through them).