11. Out Of World Actions and Effects

Recipe Book

RB §11.1 Start-Up Features

When the story file starts up, it often prints a short introductory passage of text (the "overture") and then a heading describing itself, together with some version numbering (the "banner"). It is traditional that the banner must appear eventually (and one of the few requirements of the Inform licence is that the author acknowledge Inform somewhere, for which the banner is sufficient) but some designs call for a multi-turn prologue before the banner finally appears, and marks the start of play in earnest. Bikini Atoll demonstrates this.

If a story file represents the latest in a sequence of story files representing chapters in some larger narrative, it will need some way to pick up where its predecessor left off. This can be done with the aid of external files (in the Glulx format, at least). Alien Invasion Part 23 shows how.

Another task we might want to perform a the beginning of play is to arrange any randomized features that are supposed to change from one playing to the next. We can add such instructions with "When play begins" rule, as in:

When play begins:
   now the priceless treasure is in a random room.

Since we may want to do something a bit more complicated than this, Hatless ★★ demonstrates effective and ineffective methods of distributing multiple objects (in this case, one randomly-selected hat per person).

See Also

Map for a way to generate a randomized maze at the start of play.
Food for a way to choose a random piece of candy to be poisonous.
Getting Acquainted for a way to choose a murderer from among the characters at the start of each story.

Examples

382.
Delaying the banner for later.
Keeping a preference file that could be loaded by any game in a series.
126.
Hatless ★★
It's tempting to use "now…" to distribute items randomly at the start of play, but we need to be a little cautious about how we do that.

RB §11.2 Saving and Undoing

A very few titles in the IF literature - very few being still too many, some would say - restrict the player's ability to save the story.

Removing the player's ability to UNDO is also a risky choice. Inform does provide the facility with the use option

Use undo prevention.

which makes it impossible to UNDO at any time (unless, that is, the player is playing on an interpreter that itself has a built-in UNDO feature -- these do exist). When it works, undo prevention safeguards a randomized story or combat session against brute-force solutions, but it also means that the player who makes even a minor mistake of typing will be stuck with the undesired results.

In many cases it may be preferable to use some subtler method to enforce random effects in a story. Several extensions exist for Inform that either allow selective manipulation of the UNDO command or rig randomization to prevent UNDO and replay attempts.

Examples

210.
P. David Lebling's classic "Spellbreaker" (1986) includes a room where the game cannot be saved: here is an Inform implementation.
In some of the late 1970s "cave crawl" adventure games, an elaborate scoring system might still leave the player perplexed as to why an apparently perfect play-through resulted in a score which was still one point short of the supposed maximum. Why only 349 out of 350? The answer varied, but sometimes the last point was earned by never saving the game - in other words by playing it right through with nothing to guard against mistakes (except perhaps UNDO for the last command), and in one long session.

RB §11.3 Helping and Hinting

IF is difficult to play: often harder than the writer ever suspects. Players are held up by what is "obvious", and they stumble into unforeseen combinations, or spend inordinate amounts of time working on the "wrong" problems. Too much of this and they give up, or post questions on online forums. Against this, many IF authors like to include in-story hints.

There are many approaches, which differ on two main issues.

First: do we spontaneously offer help to the player? The difficulty here is detecting the player's need: Y ask Y? tries to spot aimlessness, while Solitude ★★ has a novice mode where it is reasonable to assume that help is almost always needed. On the other hand, suppose we require that the initiative come from the player. Will a novice know to type HELP? Query shows how to redirect any attempt to ask a direct question into a HELP request. At the other end of the scale, wearily experienced players may type HELP all the time, out of habit, cheating themselves of the fun of frustration: if so, Real Adventurers Need No Help ★★★ provides the nicotine patch against this addiction.

Second: how do we decide what help is needed? Normally the player only types HELP, which is unspecific. The simplest approach offers a menu, diagnosing the player's problem by obliging him to make choices: see Food Network Interactive . Listing all the possible problems in the story may give away too much, though, since players may not have reached the puzzles in question yet; so some authors prefer to create menus that adapt to the current state of the story (commonly called "adaptive hints").

Failing this, we can also try to parse commands like HELP ABOUT MICRODOT, as in Ish. Trieste ★★ takes a similar tack, except that instead of offering hints about puzzles, it offers help on story features (such as how to save), and lists all the available topics if the player types simply HELP.

Finally, and perhaps most stylishly, we can try to deduce what the player is stuck on from his immediate circumstances and from what is not yet solved: this needs a powerful adaptive hints system like the one in The Unexamined Life ★★★.

See Also

Getting Started with Conversation for a way to redirect a player using the wrong conversation commands.
Footnotes for another medium by which hints could perhaps be transmitted.

Examples

111.
Noticing when the player seems to be at a loss, and recommending the use of hints.
Using a menu system from an extension, but adding our own material to it for this game.
296.
Ish.
A (very) simple HELP command, using tokens to accept and interpret the player's text whatever it might be.
329.
Query
Catching all questions that begin with WHO, WHAT, WHERE, and similar question words, and responding with the instruction to use commands, instead.
285.
Trieste ★★
Table amendment to adjust HELP commands provided for the player.
399.
Solitude ★★
Novice mode that prefaces every prompt with a list of possible commands the player could try, and highlights every important word used, to alert players to interactive items in the scenery.
Allowing the player to turn off all access to hints for the duration of a game, in order to avoid the temptation to rely on them overmuch.
230.
An adaptive hint system that tracks what the player needs to have seen or to possess in order to solve a given puzzle, and doles out suggestions accordingly. Handles changes in the game state with remarkable flexibility, and allows the player to decide how explicit a nudge he wants at any given moment.

RB §11.4 Scoring

Not every work of IF allots a numerical score to the player: for some authors, this emphasises the idea of a story rather than a narrative. The simple sentence

Use scoring.

introduces the concept. Once this is included, Inform will provide built-in support for a single number measuring progress ("score"), and will expect to measure this against a maximum possible ("maximum score", which can either be set by hand or worked out automatically from a table of ranks).

In a story in which scoring exists, the player may choose to turn score notifications (such as "[Your score has just gone up by one point.]") on or off. The commands to do this are NOTIFY ON and NOTIFY OFF; the actions are called switching score notification on and switching score notification off. In the event that we need to amend the behavior of notification, we could do so by adding, removing, or modifying the elements of the check and carry out rulebooks for these commands; as in

Check switching score notification off:
   if the turn count is less than 10:
      say "You are still a novice, grasshopper. Allow your teacher to give you advice until such time as you are ready to go on alone."

If we wish to change the wording of the default message ("[Your score has…"), we may want to use the Responses system.

An especially insidious style of bug allows the player to type the same sequence of commands over and over, earning score endlessly for the same insight, and to avoid this it is usually safest to write source like:

After taking the Picasso miniature when the Picasso miniature is not handled:
   increase the score by 10;
   say "As they say in Montmartre: dude!"

We might also write our condition with "for the first time", like so:

After jumping for the first time:
   increase the score by 5;
   say "Boing! That was certainly entertaining."

But we should be careful not to use "for the first time" in scoring situations where it's possible for the player to try the action but fail. Inform counts even unsuccessful attempts towards the number of times an action is understood to have occurred, so if the player tries to jump and fails, his "for the first time" will be used up and he will never receive the score points.

If there are many "treasure" items like the Picasso miniature, it is best to be systematic, as in No Place Like Home ★★★. Bosch takes another approach to the same idea, by creating a table of point-earning actions that the player will be rewarded for doing; the FULL SCORE command will then play these back.

Mutt's Adventure ★★ demonstrates how we might add a scored room feature, such that the player earns a point when he first arrives at a special room.

A single number does not really sum up a life, or even an afternoon, and Goat-Cheese and Sage Chicken ★★★ and Panache ★★★ offer more detailed citations. Works that are more story than story may prefer to offer a plot summary of the player's experience to date in lieu of more conventional scoring.

Finally, Rubies ★★★ provides a scoreboard that keeps track of the ten highest-scoring players from one playthrough to the next.

Examples

219.
Bosch
Creating a list of actions that will earn the player points, and using this both to change the score and to give FULL SCORE reports.
136.
Awarding points for visiting a room for the first time.
137.
Recording a whole table of scores for specific treasures.
166.
Panache ★★★
Replacing the score with a plot summary that records the events of the plot, scene by scene.
Implementing a FULL SCORE command which lists more information than the regular SCORE command, adding times and rankings, as an extension of the example given in this chapter.
441.
Rubies ★★★
A scoreboard that keeps track of the ten highest-scoring players from one playthrough to the next, adding the player's name if he has done well enough.

RB §11.5 Settings and Status Checks During Play

Several default actions allow the player some control over the presentation of the story, or permit the player to request information about what is going on. In addition to the standard commands described elsewhere in this section (SCORE, SAVE, UNDO, QUIT, RESTART, and RESTORE), Inform has the following actions that control the player's experience:

Preferring abbreviated room descriptions (SUPERBRIEF)
Preferring unabbreviated room descriptions (VERBOSE)
Preferring sometimes abbreviated room descriptions (BRIEF)
Switching score notification on (NOTIFY ON)
Switching score notification off (NOTIFY OFF)

The first three of these allow the player to change the way rooms are described on first and subsequent versions; the last two, when used in a story that provides a score feature, toggle on and off reports such as "[Your score has just gone up by three points.]" These are discussed elsewhere in the Recipe Book (see cross-references below).

These provide immediate feedback about the status of the story file being played:

Verifying the story file (VERIFY)
Requesting the story file version (VERSION)
Requesting the pronoun meanings (PRONOUNS)

VERIFY examines checksums to make sure that the story file being run is intact and correct. This is less often an issue now than it was in the days when story files were distributed by highly corruptible floppy disk, but the command persists and is very occasionally useful. VERSION gives the full banner text associated with the story, including title, author, release number, IFID, and other bibliographical data; it follows this with a list of the included extensions.

PRONOUNS announces to the player what the story is currently understanding as the antecedents of "him", "her", "it", and "them". This is often useful during testing, but sometimes also during play.

The following allow the player (when supported by his interpreter) to create a log of play:

Switching the story transcript on (TRANSCRIPT ON)
Switching the story transcript off (TRANSCRIPT OFF)

It is rarely a good idea to change the default performance of such commands: they are often finicky and closely tied to the interpreter in which the story runs. Moreover, disabling the "version" command means that the story file is not able to display attribution information for Inform and any included extensions, in violation of their respective licenses.

See Also

Looking for a way to set the story's verbosity level for the player.
Scoring for a discussion of score notification.
Testing for some examples of status-check commands created for alpha- or beta-testing of a story.

RB §11.6 Ending The Story

Play can end in many ways, at the writer's discretion:

end the story;
end the story finally;
end the story saying "You have reached an impasse, a stalemate";
end the story finally saying "You have succeeded.";

The phrase "end the story" by itself will finish play, printing "*** The End ***". Using one of the phrases with "saying…" allows us to specify some other text with which to conclude. Including "finally" means that the player has earned access to AMUSING text and other notes, if any of these are provided.

We can eliminate the asterisked headline entirely by removing the rule that prints it, thus:

The print obituary headline rule is not listed in any rulebook.

The next step is to print the player's score and, if applicable, the rank he achieved. By default a story doesn't feature scoring, but the following use option will incorporate it:

Use scoring.

Then, if we want to allow a score but alter the way it is reported, we may remove or modify the print final score rule, as in

The print final score rule is not listed in any rulebook.

or perhaps something like

The chatty final score rule is listed instead of the print final score rule in for printing the player's obituary.
This is the chatty final score rule: say "Wow, you achieved a whole [score in words] point[s] out of a possible [maximum score in words]! I'm very proud of you. This was a triumph. I'm being so sincere right now."

What happens next is normally that the player is invited to RESTART, RESTORE (from a saved story), QUIT or UNDO the last command. The presence of the question can somewhat undercut a tragedy, and Battle of Ridgefield shows another way to go out.

If we do leave the question in, the text is formed by the Table of Final Question Options, which by default looks like this:

Table of Final Question Options
final question wordingonly if victorioustopicfinal response rulefinal response activity
"RESTART"false"restart"immediately restart the VM rule--
"RESTORE a saved story"false"restore"immediately restore saved story rule--
"see some suggestions for AMUSING things to do"true"amusing"--amusing a victorious player
"QUIT"false"quit"immediately quit rule--
"UNDO the last command"false"undo"immediately undo rule--

Because this is a table, we may alter the behavior by changing entries or continuing the table. Finality shows how we might take out the option to UNDO the last command, for instance.

Using an ending phrase that includes "finally" tells Inform to include the options that are marked "only if victorious". One common use is to let the player read some special bit of additional text, perhaps describing easter eggs he might have missed in the story or presenting some authorial notes. Xerxes ★★ demonstrates a simple AMUSING command to read final information, while Jamaica 1688 shows how to add completely new elements to the list of options.

Old-school adventures expected their adventurers to die early and die often. Labyrinth of Ghosts ★★ shows how the residue of such past attempts can be preserved into subsequent attempts, using an external file. Big Sky Country ★★★ shows how a player can be resurrected by, let us say, some beneficent god, so that a player can even die more than once in the same attempt.

Examples

Completely replacing the endgame text and stopping the game without giving the player a chance to restart or restore.
384.
Not mentioning UNDO in the final set of options.
385.
Adding a feature to the final question after victory, so that the player can choose to reveal notes about items in the game.
386.
Xerxes ★★
Offering the player a menu of things to read after winning the game.
Remembering the fates of all previous explorers of the labyrinth.
138.
Big Sky Country ★★★
Allowing the player to continue play after a fatal accident, but penalizing him by scattering his possessions around the game map.