§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 wording | only if victorious | topic | final response rule | final 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.
![]() | Start of Chapter 11: Out Of World Actions and Effects |
![]() | Back to §11.5. Settings and Status Checks During Play |
![]() | Onward to Chapter 12: Typography, Layout, and Multimedia Effects: §12.1. Typography |
|
|
|
|
A tradition among Nethack-like computer games of the old school is that a player's death in a given place leaves a ghost behind to haunt subsequent players. Information about past lives is sometimes stored in a "bones file", and in this example we do exactly that, for a grievously unfair little dungeon. To begin with, the labyrinth itself. We create a kind of value to remember possible means of death in these tunnels, and we assign a coordinate position in some grid to each location. (We do this because grid positions can safely be stored in tables saved out to external files, whereas room names cannot - they represent data which changes each time we amend the source.)
And as compensation for these hazards:
We are now ready for the actual undertaking. The Table of Ghostly Presences holds up to twenty death notices, and is initially blank. Deaths are sequentially numbered, and this number is stored in the sequence column.
As the story file starts up, we look to see if a ghosts file already exists. If one does, we load up the Table of Ghostly Presences with it: and if not, as will be the case the first time the player explores, we leave the table blank. We sort the table so that it has earlier deaths (lower sequence numbers) first.
How will ghosts manifest themselves? Because this is only a small example, we will simply tell the player that he senses something. If several ghosts are present in the same place, the most aggrieved (that is, the most recent) is sensed first...
(For instance, "You sense the ghostly presence of an adventurer, buried by a rockfall with a score of 10 in 5 turns.") That just leaves the rule for bumping off the player. When the Table is full, and there are already 20 ghosts, the one who died longest ago (with the lowest sequence count) is eliminated, and his row blanked out. (This will always be row 1 since we sorted the table in sequence order on reading it in.)
Strictly speaking we ought to worry that after 2,147,483,647 deaths, the sequence numbers would grow too large to store in a single value, and then the sequence of ghosts will be erratic. But it seems unlikely that anyone will play this example 2.1 billion times. |
|
A tradition among Nethack-like computer games of the old school is that a player's death in a given place leaves a ghost behind to haunt subsequent players. Information about past lives is sometimes stored in a "bones file", and in this example we do exactly that, for a grievously unfair little dungeon. To begin with, the labyrinth itself. We create a kind of value to remember possible means of death in these tunnels, and we assign a coordinate position in some grid to each location. (We do this because grid positions can safely be stored in tables saved out to external files, whereas room names cannot - they represent data which changes each time we amend the source.)
And as compensation for these hazards:
We are now ready for the actual undertaking. The Table of Ghostly Presences holds up to twenty death notices, and is initially blank. Deaths are sequentially numbered, and this number is stored in the sequence column.
As the story file starts up, we look to see if a ghosts file already exists. If one does, we load up the Table of Ghostly Presences with it: and if not, as will be the case the first time the player explores, we leave the table blank. We sort the table so that it has earlier deaths (lower sequence numbers) first.
How will ghosts manifest themselves? Because this is only a small example, we will simply tell the player that he senses something. If several ghosts are present in the same place, the most aggrieved (that is, the most recent) is sensed first...
(For instance, "You sense the ghostly presence of an adventurer, buried by a rockfall with a score of 10 in 5 turns.") That just leaves the rule for bumping off the player. When the Table is full, and there are already 20 ghosts, the one who died longest ago (with the lowest sequence count) is eliminated, and his row blanked out. (This will always be row 1 since we sorted the table in sequence order on reading it in.)
Strictly speaking we ought to worry that after 2,147,483,647 deaths, the sequence numbers would grow too large to store in a single value, and then the sequence of ghosts will be erratic. But it seems unlikely that anyone will play this example 2.1 billion times. |
|