§9.11. Future events
We often want to arrange for something to happen at some point in the future. Here is yet another timepiece:
An egg-timer is in the Chamber. "A plastic egg timer in the shape of a chicken can be pressed to set it going."
Instead of pushing the egg-timer:
say "It begins to mark time.";
the egg-timer clucks in four turns from now.
At the time when the egg-timer clucks:
say "Cluck! Cluck! Cluck! says the egg-timer."
The event here is called "the egg-timer clucks". It only happens if we instruct so, using one of the following phrases:
(rule) in (time) from now
This phrase causes the given rule to be run at a given time offset from the current time of day. Example:
the egg-timer clucks in 18 minutes from now;
(rule) in (number) turn/turns from now
This phrase causes the given rule to be run at a given number of turns after the current one. Example:
the egg-timer clucks in four turns from now;
(rule) at (time)
This phrase causes the given rule to be run at a given time of day. Example:
the egg-timer clucks at 11:35 AM;
If we know in advance what time we want something to happen, we can more simply write:
At 4 PM: say "The great bells of the clock tower chime four."
(Note that in either case such rules begin with the word "at": they are the only rules allowed to begin with the word "at".)
A small warning: timed events like these only have a chance to occur during the turn sequence, that is, once every turn. In most stories, one turn takes one minute, so there will in due course be a turn happening at exactly (say) 11:35 AM. But if the clock is being advanced faster than this, it's possible that there are turns at (say) 11:32 AM and then not until 11:37 AM. But an event set for 11:35 AM will nevertheless happen -- it will run at the first available turn after that time, which will be 11:37 AM. Events can thus happen up to half an hour late, though Inform cancels them if the elapsed time is greater than that.
The Scenes panel of the Index can be a useful way to see what events have been set.
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:
Now we define our food, and add some special instructions for what happens to our hunger counters when the food is eaten:
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:
|
|
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:
Now we define our food, and add some special instructions for what happens to our hunger counters when the food is eaten:
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:
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:
Now we define our food, and add some special instructions for what happens to our hunger counters when the food is eaten:
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:
|
|
|
|