Inform 7 Home Page / Documentation
§5.5. Memory and Knowledge
All of us carry around in our heads an (incomplete, imperfect) model of the world around us: an idea of where we left the keys, whether the oven is on or off, how many clean pairs of socks are left in the drawer, what we look like in our best pair of jeans. The differences between that mental model and reality are to some degree a reflection of personal character: our forgetfulness, our wishful thinking, our innocence or cynicism.
By default, Inform does not keep track of the player character's knowledge (or any other character's knowledge, for that matter) as a separate thing from the model world, relying on descriptive prose rather than modeling to introduce these quirks of characterization.
All the same, there are often times when we would like to keep track of discrepancies between the world model and the narrator's mental model. Perhaps the most common way to do this is simply to mark everything that the player encounters as "seen" when the player first examines it, thus:
A thing can be seen or unseen.
Carry out examining a thing:
now the noun is seen.
or -- to have things remembered from the first moment they're mentioned in a room description:
Rule for printing the name of something (called the target):
now the target is seen.
The mental model need not always be accurate, of course. We might, for instance, have occasion to keep track of where the player character last saw something, even if the object has since been moved; or keep track of falsehoods the player character has been told in conversation; or make the player refer to a character as "the bearded man" until he is properly introduced.
Included with Inform is the extension Epistemology, by Eric Eve, which provides one way of tracking this kind of information. Epistemology distinguishes between items that the player character has seen, because they're objects in a room the player has been to, and items that are familiar to the player for other reasons, such as a quest item he knows about but hasn't found yet, or an abstract conversation topic. Anything that is either seen or familiar is counted as "known".
Modeling what the player does and does not know is only half the job, of course: we also need that information to affect the behavior of the story in plausible ways.
One obvious occasion to use player character knowledge is in the output of descriptions. We might want to respond to actions differently depending on what the player has previously done, as in Tense Boxing, or change the way we describe objects in light of new knowledge about them, as in Zero. Casino Banale takes that idea much further, with a whole system of facts that can be narrated to the player in a somewhat flexible but interdependent order, as the player looks at relevant objects or notices them in room descriptions.
Along similar lines, we may want an object to change its name for the player depending on what the player knows. That name change should affect both what Inform displays and what it understands about the object. For instance:
An Amherz Amulet is a thing. It can be known or unknown. It is privately-named.
The printed name is "[if known]Amherz Amulet[otherwise]lizard-shaped pewter charm[end if]".
The description is "[if known]It's a unique and magically powerful pewter charm shaped like a lizard[otherwise]It's some cheap tacky pewter charm shaped like a lizard. At least, as far as you can tell -- it's pretty grubby[end if]."
Understand "amherz" or "amulet" as the Amulet when the Amulet is known.
Understand "lizard" or "lizard-shaped" or "pewter" or "charm" as the Amulet when the Amulet is unknown.
Instead of rubbing the amulet when the amulet is unknown:
say "You rub off a bit of the dirt, and... what do you know? It's actually the priceless and fabulously powerful Amherz Amulet!";
now the Amherz Amulet is known.
Finally, the player's knowledge may affect how the story interprets commands, in the determining what is called "scope". When Inform tries to make sense of something the player has typed, it makes a list of everything that the player is allowed to refer to at the moment, and then checks whether all of the objects in the player's command refer to items in that list. Only things that are "in scope" are open for discussion.
If the player mentions an object that is not "in scope" -- say, a red hat left behind in the next room -- Inform will issue the response "You can't see any such thing." This is also Inform's reply if the player mentions a nonsense object ("EXAMINE FURSZWIGGLE") or an object that does not exist in the story world at all ("EXAMINE CELL PHONE" in a story set in Carolingian France).
This is not the only possible way for interactive fiction to handle such communication. Some games will respond differently to EXAMINE RED HAT and EXAMINE FURSZWIGGLE, saying in the first case something like "You can't see that now" and in the second "I don't know the word 'furszwiggle'."
The drawback of such behavior is that the player can make premature discoveries. If he hasn't found a sword yet, but thinks there may be a sword later in the story, he can type EXAMINE SWORD and see from the response whether his guess is correct. Nonetheless, there are people who prefer this alternative exactly because it does expose the limits of the story's understanding, preventing fruitless attempts to use a word that is not recognized at all. If it is desirable, there is an extension that will reproduce this behavior in Inform as well.
Using Inform's default behavior, however, scope is an ad-hoc way of keeping a list of things that are common knowledge between the story and the player. The player knows many things that the story might not (like what a cell phone is); the story knows a few things the player may not (like the fact that there is a sword in an as-yet unvisited room). Neither of those things can fruitfully enter into commands because they have no mutually agreed-upon referent.
By default, Inform assumes that "scope" includes only those things that are currently visible by line of sight. This works pretty well for a wide range of situations, but there are still plenty of occasions when we want to admit that the story and the player share a knowledge of things not seen. GO TO THE KITCHEN might be a useful command even when the player can't currently view the kitchen. ASK FRED ABOUT THE FOOTPRINTS should perhaps work even when the footprints are far away in the garden. SMELL STINKY CHEESE might need to work even when the cheese is invisibly locked away in a porous container but is exuding a stench. In a dark room, the player can't see his own inventory, but he should still remember that he's carrying it and be able to mention it. And sometimes we might want the story to acknowledge that the player is referring to an object that he has seen somewhere, even if that thing is now out of sight.
In practice, we have two ways to tinker with scope: we can change the scope for a specific command, using a token with any, as in
Understand "go to [any room]" as approaching.
Understand "find [any thing]" as finding.
Understand "ask [someone] about [any known thing]" as interrogating it about.
Or we can add areas and items to scope for all commands, as in
After deciding the scope of the player when the surveillance camera is switched on:
place the jail cell in scope.
Puncak Jaya demonstrates understanding references to characters who are currently off-stage.
See Helping and Hinting for objects tagged with a "seen" property when the player first encounters them
See Getting Acquainted for a character whose name is changed during the course of play as the player gets to know him better
See Room Descriptions for more ways to change the description of a room depending on player experience
See Going, Pushing Things in Directions for ways to understand the names of distant rooms and move towards them
See Character Knowledge and Reasoning for models of knowledge for other characters than the player
See Sounds for ways of tracking audible objects separately from visible ones
See Lighting for ways to change what the player knows about and can manipulate in dark rooms
See Clocks and Scientific Instruments for a telescope that lets the player view objects in another location
See Continuous Spaces and The Outdoors for more on seeing into adjacent locations
Here we have a box that prints out its current state and its history each time we open and close it:
To assess the box:
if the box was not open, say "The box was not open.";
if the box was open, say "The box was open.";
if the box had not been open, say "The box had not been open.";
if the box had been open, say "The box had been open.";
if the box is not open, say "The box is not open.";
if the box is open, say "The box is open.";
if the box has not been open, say "The box has not been open.";
if the box has been open, say "The box has been open."
Note that "was..." and "was not..." and so on may describe conditions more complicated than simple properties: we could equally well ask "if the box has been in the sack", "if the box had been carried by the player", and so on.
The past ("if the box was...") and past perfect ("if the box had been...") are especially useful for cases where we want to report on an action after the state of the item has changed; so, for instance:
After taking the mysterious box:
if the box had not been carried by the player, say "You lift the mysterious box for the first time.";
if the box had been carried by the player, say "You again pick up the mysterious box."
This is in many respects similar to a rule beginning "After taking the mysterious box for the first time...", but it is superior in most circumstances, for two reasons.
First, it will respond correctly even if the player has somehow carried the box before without taking it explicitly: for instance, if another character gave him the box, if the box were moved into his inventory as a result of another action, or if the player carried the box at the start of play. Inform begins its reckoning of time when the game begins, so if the box is defined as being open at the outset, "if the box has been open" will always be true.
Second, "after taking... for the first time" fires only the first time the player attempts to take something. If the player tried to take the box, failed, and then tried again later, the "for the first time..." rule would not fire; our "if the box has not been carried..." rule would.
By default, when something is not present, Inform does not allow a player to refer to it. But there are times when we might like to acknowledge that the thing mentioned in a command does exist somewhere in the game; it just happens not to be on hand right now.
One way to do this is to make an object that appears everywhere and responds to the name of its owner only when the owner itself is not in view.
We make the ghost a person rather than some other kind of thing so that it will be able to respond to commands such as KISS BOB or (even trickier) BOB, JUMP: if Inform did not recognize the ghost as an animate creature, it would not accept such input.
This is, technically, an assembly -- except instead of saying that every device has a button part, or that there are three daffodils in every garden room, the assembly is based on a non-physical relation that we just designed.
Based on the "representation" relation, we now devise a conditional relation that applies only when the represented thing is not itself in view:
Further complications of this example might require that the player meet a character before being able to refer to him or her.
The names of objects might want to change also:
This does require a rule for an activity (see the chapter on Activities), but it's a fairly straightforward one:
The Nearly Empty Living Room is a room. "Nearly everything is out, all of Helen's possessions and most of yours." A man called Mr Zero is in the Nearly Empty Living Room. "Mr Zero, despite being heavily paid to assist in this operation, is giving you a look that clearly conveys his lack of interest in budging even one more item." The description of Mr Zero is "Many muscles, no hair."
The book box is a horribly heavy thing in the Living Room. The clothing box is a manageable thing in the Living Room. A broom, a dustpan, some packing tape, and a discarded newspaper are light things in the Living Room.
In a work of interactive fiction that involves many new discoveries, we might want to change the way we narrate room descriptions and describe objects as the player learns new information.
One approach to this is to create a model of the facts we want the player to find out, and attach some narrative text to each. When a fact becomes relevant to the story, that narrative text is shown to the player. So:
First we create the concept of facts, and the idea that facts can make some things more important than others.
Now, we also need a way to tell Inform to introduce certain new facts when the right previous ones have been introduced. We'll create a "following" relation, according to which a new fact can be told to the player when the player has already learned all the facts it follows. This way, we can simulate the effect of putting together several pieces of evidence to come to a conclusion:
To say (new fact - a fact):
say "[narration of the new fact]";
now the new fact is known;
repeat with possible outcome running through facts which follow the new fact:
if every fact which is followed by possible outcome is known:
now the possible outcome is ready to learn.
Next we need a way for the game to introduce these new facts. Let's say we want them to come up when the player examines something appropriate, or sees it in the room:
For writing a paragraph about a narratively significant thing (called item):
now the item is mentioned;
let chosen fact be a random interesting fact which is conveyed by the item;
say "[chosen fact][paragraph break]".
The "after choosing notable locale objects" line here handles things so that any interesting conclusions we want to draw are always given first, followed by the less interesting description.
And finally, we need to give the player a little evidence to piece together:
Frince is a man in the Casino. The description is "Frince is a friend of yours -- if you reckon friendship on the same terms that one reckons a cat as a pet. He spends time with you when he wants to, but if your wishes or convenience ever run counter to a whim of his, it's the whim that wins. Always. [paragraph break]He's also wearing a somewhat ludicrous shirt."
Frince wears a ludicrous shirt. The description of the ludicrous shirt is "Fine white fabric with satiny white pinstripes: it's that expensive, effeminate look that Frince is so fond of, and which -- combined with his name -- gives people completely the wrong idea about him."
Rule for writing a paragraph about a narratively dull person:
let is-are-n be "is";
if the number of unmentioned narratively dull people is not 1:
let is-are-n be "are";
say "[A list of unmentioned narratively dull people] [is-are-n] [one of]watching the croupier[or]following the spin of the roulette[or]chattering[at random][one of] breathlessly[or] impatiently[or][at random]."
Penny-annoying is a fact.
It is ready to learn.
The narration is "[if looking]Penny grimaces at you-- [end if]Penny is the same woman who stepped on your toe in the buffet line. The third time, she blurted, 'You have big shoes, don't you?'"
Penny conveys penny-annoying.
penny-wears-coral is a fact.
It follows penny-annoying.
The narration is "[if looking]Penny catches your eye again. [end if]The bright coral lipstick was really not a wise choice."
Penny conveys penny-wears-coral.
Affair-with-penny is a fact.
It follows lipstick-smudges and penny-wears-coral.
The narration is "You avoid [if examining Frince]his[otherwise]Frince's[end if] eye. You need some time to adjust to the image of him making out with Penny in a storage closet before you can talk to him without appalled giggling."
Frince conveys affair-with-Penny.