Inform 7 Home Page / Documentation
Chapter 4: Time and Plot
§4.1. The Passage Of Time; §4.2. Scripted Scenes; §4.3. Event Scheduling; §4.4. Scene Changes; §4.5. Flashbacks; §4.6. Plot Management
|Contents of The Inform Recipe Book|
|Chapter 3: Place|
|Chapter 5: The Viewpoint Character|
|Indexes of the examples|
§4.1. The Passage Of Time
A story that makes heavy use of time may want to give the player a hint that time is important - and an easy way to keep track of how it's going - by adding the current time to the status line, instead of the score. To do this, we would write
When play begins:
now the right hand status line is "[time of day]".
All else being equal, time passes at a rate of one minute per turn. But this need not be so: we can imagine a story where turns take much less time, or much more; or a story in which the passage of time was sometimes suspended, or one in which different actions required different amounts of time to perform.
Situation Room provides a way to print 24-hour time, while Zqlran Era 8 implements a completely new measurement of time, for a story set on an alien world.
Uptempo and The Hang of Thursdays speed up time's passage: turns take fifteen minutes in the former, or a quarter day in the latter.
Timeless makes certain actions instant, so that they don't count against the clock; this is sometimes useful in timed situations where the player needs to review the situation before going on with a tricky puzzle. Endurance systematically extends this idea to allow us to assign different durations to any action in the story. The Big Sainsbury's goes the opposite direction, and meticulously adds a minute to the clock for all implicit take actions, just so that the player isn't allowed to economize on moves.
An alternative approach to time is not to tell the player specifically what hour of the day it is at all, but to move from one general time period to another as it becomes appropriate - when the player has solved enough puzzles, or worked his way through enough of the plot. To this end we might use scenes representing, say, Thursday afternoon and then Thursday evening; then our scene rules, rather than the clock, would determine when Thursday afternoon stopped and Thursday evening began:
Thursday afternoon is a scene. Thursday evening is a scene.
Thursday afternoon ends when the player carries the portfolio.
Thursday evening begins when Thursday afternoon ends.
When Thursday evening begins:
say "The great clock over St. Margaret's begins to chime 6.";
Though this gives time a loose relation to the number of turns played, it feels surprisingly realistic: players tend to think of time in a story in terms of the number of significant moves they made, while the random wandering, taking inventory, and looking at room descriptions while stuck don't make as big an impression. So advancing the story clock alongside the player's puzzle solutions or plot progress can work just as well as any stricter calculation.
See Passers-By, Weather and Astronomical Events for cycles of day and night scenes
See Waiting, Sleeping for commands to let the player wait until a specific time or for a specific number of minutes
See Clocks and Scientific Instruments for clocks that can be set to times and that have analog or digital read-outs
See Timed Input for discussion of extensions allowing real-time input
|Start of Chapter 4: Time and Plot|
|Back to Chapter 3: Place: §3.9. Passers-By, Weather and Astronomical Events|
|Onward to §4.2. Scripted Scenes|
Though Inform normally prints times in AM/PM terms, it stores the hours and minutes as 24-hour time; so, if we like, we can easily extract that information again thus:
To say (relevant time - a time) as 24h time:
let H be the hours part of relevant time;
let M be the minutes part of relevant time;
say "[if H is less than 10]0[end if][H][if M is less than 10]0[end if][M]".
The Big Sainsbury's
Implicit takes are a convenience to players; in general, we would like to avoid asking players to type any more obvious commands than strictly necessary, while allowing the computer to guess as much as it safely can.
Occasionally, though, we have designed a timed puzzle in which the player has a limited number of moves in which to accomplish his objectives. In that case, the implicit take complicates matters, because it means that a player who types
gets away with a spare move compared to the precise but naïf dupe who types
...and really, that doesn't seem quite fair. The way to fix this problem is to fill in the extra minute on the clock during the implicit take; and that is indeed what we do in the following example.
Suppose a game in which all actions take a very long time. Here's a simple implementation:
This works fine as it stands, but we may run into some difficulty with it if we add scheduled events:
Time is counted forward after the schedule has already been consulted, so that only the 9:30 AM event happens between 9:30 and 9:45; the next two appear to occur between 9:45 and 10:00 AM, and the 9:50 AM event is not reported until the 10:00 AM to 10:15 wait. To get around this, we might schedule events only on the fifteen-minute mark when we want them to occur. Alternatively, we might try instead
This time our revised time-advancing rule is listed just before the event scheduler, not just afterwards.
In a game with tight timing, it is sometimes friendliest to the player to let him LOOK and EXAMINE as much as necessary without being penalized.
Now we need a rule which, just at the right moment, stops the turn sequence rulebook in the cast of our new fast-acting actions:
Thus the rest of the turn sequence rulebook is omitted for looking or examining: in effect, they become out-of-world actions like "saving the game". If we wanted to add, say, taking inventory to the list of instant activities, we would just need to define it as acting fast, too.
Now the scenario for testing:
Here we move to a systematic way of giving different durations to different actions, including even variations on the same act -- so that for instance climbing a steep hill might take several minutes more than other going actions. We do this by setting a number, "work duration", to represent the number of minutes consumed by a given action, and then consulting a rulebook to find out how long the past turn's action should take. By default, an action will take 1 minute.
We'll start by emulating the behavior of "Uptempo": each turn we'll set the clock forward most of the way, then check to see what has changed since the last turn, print any relevant events, and only then set the clock forward the final minute. The exception is when an action is set to take no time at all; in that case, we'll skip the rest of the turn sequence rules entirely.
The Quai is a room. "An attractive park at the edge of the river Aude: here you can wander among palm trees, and watch cyclists go by on the bike path; in the water there are ducks. In the cafe to your north, patrons sip their pastis; and above you is the medieval walled city and its castle."
The Cafe is north of the Quai. "A charming collection of umbrella-shaded tables, from which one can watch the river and the walls of the city beyond. The noise of traffic is only a minor distraction."
The Hang of Thursdays
This is the new advance time rule:
if the current time period is less than night:
now the current time period is the time period after the current time period;
now the current time period is morning;
now the current weekday is the weekday after the current weekday.
Now we need to borrow from a later chapter to make these instructions apply to the passage of time:
Zqlran Era 8
Suppose that our game takes place on an alien planet that does not follow Earth time. On this planet, we want to track time with different units. We also want time to advance in those units, and we want to be able to set a schedule of timed events.
The Barren Lavender Surface of Zql is a room. "It is late twilight on Zql. Overhead, two crescent moons, both green, mark the sluggish passage of time. A cold wind is blowing over the pale purplish ground cover, but it does not penetrate your airtight suit."
A Zqlran date is a kind of value. 14-88 specifies a Zqlran date with parts zqls and frbs. Current zqlran date is a zqlran date that varies. The current zqlran date is 8-22. Previous zqlran date is a zqlran date that varies. The previous zqlran date is 8-20.
Inform automatically supplies a way to say a new unit, which will look similar to the format in which we defined that unit in the first place. But we can (as shown here) create our own alternative say phrases to express the units in other ways as well.
Next, we need to meddle with time advancement so that time is tracked in Zqlran date rather than in minutes. This requires borrowing a trick from a later chapter, to replace Inform's built-in time handling with an alternative time handling rule of our own:
This is the Zqlran time rule:
increment turn count;
now the previous zqlran date is current zqlran date;
increase the current zqlran date by 0-02;
repeat through the Table of Zql Schedule:
if era entry is greater than previous zqlran date and era entry is not greater than current zqlran date:
say event entry;
say paragraph break;
blank out the whole row.
"A wisp-thin cloud blows rapidly across the face of Nepenthe, the lesser of the two green moons."
"The cloud across Nepenthe clears."
Note that we could if we wished use a different device for scheduling events: this one simply prints text at scheduled eras, but we might also (for instance) make the event entry be a rule for Inform to follow, and tell Inform to carry out that rule at the scheduled time.