As we have seen, Inform divides up space into individual places called "rooms", and allows us to group rooms together into "regions" if we find that convenient. And Inform also divides time up, into individual turns. These too we can group together: the equivalent of a region is a "scene".
To put this another way, if we think of the interactive fiction as a stage play, then up to now it has simply contained endless dialogue and stage directions - there has been no convenient way to divide up its running time into dramatic episodes, in the same way that a playwright might make Act II take place in the same drawing-room as Act I, but (let us say) six months later, after many things have changed. The script contains cues for one scene to end and another to begin: when those cues are reached, the stage hands rearrange props, actors reposition themselves and so on.
Inform also allows us to create scenes, with cues for them to start and end, and some stage machinery (so to speak) making it easy to move the action on. But interactive fiction is interactive, so the metaphor of the theatre only goes so far. We can have several different scenes going on at once - perhaps with the relevant events taking place in different rooms, which the player is free to walk between. And the player may make a choice which changes the story-line, causing scenes to happen which otherwise would not have happened, and so on. Scenes can even be "recurring", that is, can repeat themselves.
So organising the story-line into scenes is not simply a matter of making a list (Scene 1, then Scene 2, then Scene 3, finis). It is more like a chart in which one scene can lead in several possible ways to others - a sort of map of time, which as we shall see Inform displays in its "Scenes" index.
As usual, we only need to say that something is a scene to make it so:
We conventionally write scene names with capital letters, as this demonstrates.
This works, and shows up in the "Scenes" index, but does nothing. We have given no instructions on when it begins - no cue, in stage-play terms - so it never will begin, and even if it did, nobody would notice since it does nothing. First, to give it a beginning:
Train Stop begins when the player is in the Station for the third turn.
In theory any condition can be used to cue the scene - here, it's "the player is in the Station for the third turn" - but it's wise to look for a state of affairs which will last at least a brief time, because scene changes only happen at the start and end of turns. (Something like "…when examining the timetable" may be true only for a part of the middle of a turn, and so go unnoticed.)
Every scene has two rulebooks attached, one at each end, so to speak. These look very like "when play begins" and "when play ends", and work in the same way. Thus:
When Train Stop begins:
now the Flying Scotsman is in the Station;
say "The Flying Scotsman pulls up at the platform, to a billow of steam and hammering."
When Train Stop ends:
now the Flying Scotsman is nowhere;
if the player is in the Station, say "The Flying Scotsman inches away, with a squeal of released brakes, gathering speed invincibly until it disappears around the hill. All is abruptly still once more."
Thus when the scene begins, our imaginary stage-hands wheel in a steam train; when it ends, they get rid of it again. Note that we know where the player will be at the start of the scene, but by the end he may have wandered off across the fields, so we must be careful not to report something he might not be in a position to see.
When Train Stop begins, we printed some text, but we did this by hand. We didn't need to, because Inform automatically prints out the description of a scene (if it has one) when the scene begins. Scenes can have properties, just like objects, and in particular they have the "description" property. For example, we could write:
Arrival is a scene. "There's a flourish of trumpets."
which saves us the trouble of writing the rule:
When Arrival begins: say "There's a flourish of trumpets."
We can also write rules like this which apply to a whole variety of scenes at once. For instance:
A scene can be bright or dim. A scene is usually dim. Dawn is a bright scene.
When a scene which is bright ends: say "So passes the bright [scene being changed]."
Here, instead of naming a scene ("Train Stop"), we've given a description ("a scene which is bright"). When a scene begins, these general rules come before those which name the scene exactly; when it ends, the reverse is true.
Pine: Using a scene to watch for the solution of a puzzle, however arrived-at by the player.
A scene in which the player is allowed to explore as much as he likes, but another character strolls in as soon as he has gotten himself into an awkward or embarrassing situation.
But when we test the previous section's example, we find that after a brief wait, the train pulls up: but it never goes away again. We have given instructions on how the scene ends, but not when it ends, and as a result the scene goes on forever once started.
Even with simple story-lines, and this one could hardly be simpler, it is surprisingly easy to overlook something so that the whole story-line is derailed.
The Scenes page of the index is intended to help with this. The Plot section shows all of the scenes and how they are to begin, along with a key to the symbols used on it. One scene always included is "Entire Game", a special scene which, as its name implies, is always being played out. But if we look at the Scene index for the previous example, we will also see our Train Stop scene, and find that it is marked with the red warning symbol for "never ends". Let us fix this:
Train Stop ends when the time since Train Stop began is 3 minutes.
Note the useful value "time since Train Stop began":
time since (scene) began ⇒ time
This phrase produces the time since the named scene began, which only makes sense, of course, if it has indeed begun. Example:
time since Entire Game began
time since (scene) ended ⇒ time
This phrase produces the time since the named scene ended, which only makes sense, of course, if it has indeed ended. Example:
time since Formal Dinner ended
The actual times, in case they are needed, can be obtained with:
time when (scene) began ⇒ time
This phrase produces the time (i.e., the value of the "time of day" variable) at the moment when the given scene began.
time when (scene) ended ⇒ time
This phrase produces the time (i.e., the value of the "time of day" variable) at the moment when the given scene ended.
The testing command SCENES causes Inform to monitor the beginning and ending of scenes, and report on them. For instance:
>ask monk about lodging
"Welcome a poor traveler for the night?" you ask, rubbing your fingers together to restore a little feeling.
The monk looks you up and down for a moment and you sense his reaction hanging in the balance; then he slaps you on the back, hard enough to drive the air from your lungs. "In."
[Scene 'Greeting' ends]
The monk takes your elbow and pushes you imperiously toward dinner.
[Scene 'Banquet' begins]
The railway-station examples so far put together into a short game called "Age of Steam".
Scenes are not only useful for changing the setting, by moving items or people around and providing a little narration. We can also make the rules different in one scene from another. For instance, at a sleepy country halt there is no reason why one should not walk across the tracks: but if there is a train in the way, that would be impossible.
Before going north during the Train Stop, say "The train blocks your way." instead.
Any rule can have the clause "during …" attached, provided that clause goes at the end and either explicitly names a scene, or gives a description of which scenes would match. This is especially useful with "every turn":
Every turn during the Train Stop, say "Water is sluiced out of the tank and into the engine."
We can test whether a scene is happening with the adjective "happening":
if Train Stop is happening, ...
if (scene) has happened:
This condition is true if the given scene has both begun and ended.
if (scene) has not happened:
This condition is true if the given scene has not ended (or never started).
if (scene) has ended:
This condition is true if the given scene ended at least once.
if (scene) has not ended:
This condition is true if the given scene has never ended.
We need to be a bit careful: it's possible to set things up so that the Train Stop scene will play out more than once, so "Train Stop is happening" and "Train Stop has happened" might both be true at once.
The kind of value "scene" is one which is allowed to have properties - it has a tick in the "properties" column in the chart in the Kinds index - and this can be very useful in describing scenes. For instance, we could write:
A scene can be thrilling or dull. Train Stop is dull.
A scene has a text called cue speech. The cue speech of Train Stop is "All aboard!".
Inform has the adjectives "recurring", "non-recurring" and "happening" all built in to describe scenes, and the above would add "thrilling" and "dull". Moreover, the "during" clause of a rule can give a description of a scene as easily as a specific scene name. For instance:
Before going north during a dull non-recurring scene, ...
Random atmospheric events which last the duration of a scene.
We'll be back in just a moment, with more exciting adventures of the… Space Patrol!
Creating a category of scenes that restrict the player's behavior.
A scene which plays through a series of events in order, then ends when the list of events is exhausted.
Let us suppose that somebody gets off the train, after all, so that a second scene follows on.
Brief Encounter is a scene. Brief Encounter begins when Train Stop ends.
The effect of this is that they occur in sequence. If we add a third to the chain of scenes:
Village Exploration is a scene. Village Exploration begins when Brief Encounter ends.
…we find another chance to fool ourselves: if we check the Scenes index again, we can see the linkages between these scenes, but we also see that Brief Encounter never ends (despite its name). All we have said is that another scene begins where Brief Encounter leaves off, but it never does, so this is moot.
Pine: Adding a conversation with the princess, in which a basic set of facts must be covered before the scene is allowed to end.
We are allowed to link the beginning or end of any scene to the beginning or end of any other scene. So, for instance:
Luggage Trouble is a scene. Luggage Trouble begins when Brief Encounter begins.
Thus the two scenes run concurrently, at least for a while. We can also add that:
Luggage Trouble ends when Brief Encounter ends.
This can be useful when a large, complicated scene really contains several smaller sub-scenes.
A special exceptional case is that we can have any scene or scenes starting right at the outset:
Railway Meeting is a scene. Railway Meeting begins when play begins.
When play ends, of course, all scenes end, so there is no need to say that.
Scenes used to provide pacing while the player goes through his possessions.
Organizing the game by scenes, where each scene has a location and prop lists so that it can be set up automatically.
It is quite allowed for a scene to be linked to several other scenes, and this is useful if several alternate strands of plot are being brought together in a common resolution scene:
Bittersweet Ending begins when Stranger's Rejection ends.
Bittersweet Ending begins when Stranger's Acceptance ends.
and we can also have the same scene beginning when a condition holds. In general, it will begin the first time it gets any chance to do so.
All scenes are ordinarily set up so that they can happen only once. But sometimes we want them to repeat. Suppose the train calls not once only, but every twenty minutes. We could set this up with two scenes linked back to back like so:
Train Stop is a recurring scene. Train Wait is a recurring scene.
Train Wait begins when play begins.
Train Stop begins when Train Wait ends.
Train Wait begins when Train Stop ends.
The difference here is that these scenes have been declared as "recurring". In all other respects they are the same as any other scene.
Cycling through a sequence of scenes to represent day and night following one another during a game.
Pine: Allowing the player to visit aspects of the past in memory and describe these events to the princess, as a break from the marriage-proposal scene.
Interactive fictions vary considerably in the extent to which the player is allowed to influence the story-line. Sometimes the appearance of making choices is wholly bogus, as only one possible line is given more than lip service. But in other works, the player can radically change the outcome, and whole rafts of plot differ between one person's experience and another's. Inform allows multiple endings to its scenes to make this kind of branching story-line easy to achieve.
Any scene can have up to 31 alternate endings, differentiated by name (unless the Z-machine format has been selected on the Settings panel, in which case, 15). These alternates are created as and when conditions are set for them:
Brief Encounter ends happily when ...
Brief Encounter ends wisely but sadly when ...
"Ends happily" and "ends wisely but sadly" behave just like "ends". We can have rules "When Brief Encounter ends happily, …" and so forth, in addition to rules "When Brief Encounter ends, …" - if a rule doesn't specify any particular ending, it applies to all of them.
We can also link rules together from these branches, so
Stranger's Acceptance begins when Brief Encounter ends happily.
Stranger's Rejection begins when Brief Encounter ends wisely but sadly.
With this set-up and that of the previous section, there are now two possible paths through the story:
(i) Train Stop - Brief Encounter - Stranger's Acceptance - Bittersweet Ending
(ii) Train Stop - Brief Encounter - Stranger's Rejection - Bittersweet Ending
We might later need to know which of these paths has been taken, and to help with this Inform provides conditions like so:
if Brief Encounter ended happily ...
if Brief Encounter did not end happily ...
if Brief Encounter ended wisely but sadly ...
if Brief Encounter did not end wisely but sadly ...
(For a scene which repeats, note that these conditions apply only to the most recent repetition: and that such conditions are always false if the scene is currently going on. "Brief Encounter did not end happily" will be true only when the scene has finished but in a different way.)
Replacing the score with a plot summary that records the events of the plot, scene by scene.
Pine: Adding a flashback scene that, instead of repeating endlessly, repeats only until the Princess has understood the point.
In the part it plays in stories, time is like space. The endings of a scene (along with its beginning) are like the map connections leading out of a room. The Scenes index keeps track of the "map of time" through which these possible story-lines traverse. Some works of IF will have immensely complicated story-lines in only a few rooms, some will have no scenes at all despite a sprawling geography. The Scenes and World index tabs, side by side, show both kinds of map.
Just as Inform uses a simple but practical design for the boundaries between rooms (map connections and doors, that is), it also simplifies transitions between scenes. Scenes are based on states of things: we give circumstances for them to begin or end. There is no phrase with the power to say "make Act II begin right now", so perhaps it is worth explaining why not. The state-based approach was chosen because:
* it guarantees that each action falls entirely inside, or entirely outside, of any given scene (and therefore that "during..." clauses in the conditions for a rule are not affected by rule ordering);
* it ensures that scene changes occur outside actions, like every turn rules;
* it promotes a style of writing which makes it clearer to the reader of the source text when a scene begins and ends, and what conditions are guaranteed to be true during it;
* it makes it possible for the Scenes index page to show this information in a communicative way.
Settings in IF where one revisits the same location but at a different time, or after a dramatic change, have historically been difficult to test properly and prone to mistakes. (The classic example would be where a character killed during Act I reappears unharmed in Act II.) The design of scenes is an attempt to encourage a style of writing which minimises the risk of these accidents.
Since scenes are, in the end, only a convenient way to organise rules, and do nothing that cannot be done by other means, this simplified system of scene changing does not really restrict us.
Scenes used to control the way a character reacts to conversation and comments, using a TALK TO command.