Inform 7 Home Page / Documentation
§2.2. Varying What Is Read
Making the printed text adapt to circumstances only makes half of the conversation graceful: the other half is to allow the player's commands to have a similar freedom. The things the player can refer to should always respond to the names which would seem natural to the player. Inform provides a variety of techniques for understanding words always, or only under certain conditions; and, if need be, we can also get direct access to what the player has typed in order to examine it with regular expressions. (This last resort is rarely necessary.)
First Name Basis shows how to assign names to things or to kinds of thing - if, for instance, we want the player to be able to refer to any man as "man" or "gentleman":
Understand "man" or "gentleman" as a man.
We may also sometimes want to give names that are specifically plural, as in
A duck is a kind of animal. Understand "birds" as the plural of duck.
Understand "birds" as the plural of the magpie.
A common challenge arises when two objects have names that overlap or are related, and we wish Inform to choose sensibly between them: for instance, a cigarette vs. a cigarette case. If a word should apply to something only as part of a phrase (e.g., "cigarette" alone should never refer to the cigarette case) we can manage the situation as follows:
The case is a closed openable container. The printed name is "cigarette case". Understand "cigarette case" as the case.
Because "cigarette" here appears only as part of the phrase "cigarette case", it will be understood only in that context; the conflict with the bare cigarette will not arise.
As a variant, we may want one object only to take precedence over another in naming. If we wanted the player to be allowed to refer casually to the cigarette case as "cigarette" when (and only when) the cigarette itself is not in view, we could add
Understand "cigarette" as the case when the cigarette is not visible.
Tricks which consider the visibility of other objects can be bad for performance if used widely; but for adding finesse to the treatment of a few items, they work very well.
(There may still arise cases where the player uses a name which can legitimately refer to two different things in view. To deal with this situation, we may want the Does the player mean... rules, explained in the chapter on Understanding; and to change the way the story asks for clarification, see the two activities Asking which do you mean and Clarifying the parser's choice of something.)
Names of things which contain prepositions can also be tricky because Inform misreads the sentences creating them: Laura shows how some awkward cases can be safely overcome.
A more difficult case is to ensure that if we change the description or nature of something in play, then the names we understand for it adapt, too. "Understand... when..." can be all that's needed:
Understand "king" as Aragorn when we have crowned Aragorn.
Or, similarly, if we want some combination of categories and characteristics to be recognized:
Understand "giant" as a man when the item described is tall.
"The item described" here refers to the thing being named. "...when" can even be useful in defining new commands, and Quiz Show demonstrates how to ask open-ended questions that the player can answer only on the subsequent turn.
Properties can also be matched without fuss:
Tint is a kind of value. The tints are green, aquamarine and darkish purple. The wallpaper is fixed in place in the Hotel. The wallpaper has a tint. Understand the tint property as describing the wallpaper.
This allows EXAMINE AQUAMARINE WALLPAPER if, but only if, it happens to be aquamarine at the moment. Relationships can also be matched automatically:
A box is a kind of container. The red box is a box in the Toyshop. Some crayons are in the red box. Understand "box of [something related by containment]" as a box.
which recognises BOX OF CRAYONS until they are removed, when it reverts to plain BOX only.
Greater difficulty arises if, using some variable or property or table to mark that a bottle contains wine, we print messages calling it "bottle of wine". We are then honour-bound to understand commands like TAKE BOTTLE OF WINE in return, not to insist on TAKE BOTTLE. Almost all "simulation" IF runs in to issues like this, and there is no general solution because simulations are so varied.
A converse challenge arises when we want to avoid understanding the player's references to an object under some or all circumstances. This is relatively uncommon, but does sometimes occur. For this situation, Inform provides the "privately-named" property, as in
The unrecognizable object is a privately-named thing in the Kitchen.
Here "privately-named" tells Inform not to understand the object's source name automatically. It is then up to us to create any understand lines we want to refer to the object, as in
Understand "oyster fork" as the unrecognizable object when the etiquette book is read.
Of course, if we need an object that the player is never allowed to refer to at all, we can just make this privately-named and then not provide any understand lines at all.
A final source of difficulty is that by default Inform truncates words to nine letters before attempting to identify them. This is no problem in most circumstances and is likely to go unnoticed -- until we have two very long words whose names are nearly identical, such as "north-northwest exit" and "north-northeast exit". (To make matters worse, a punctuation mark such as a hyphen counts as two letters on its own.)
When we are compiling for Glulx, the limit is easily changed with a single line, setting the constant called DICT_WORD_SIZE. For instance, if we wanted to raise the limit to 15, we would write
Use DICT_WORD_SIZE of 15.
When compiling for the Z-machine, the solution is harder. North by Northwest shows how to use the reading a command activity to pre-process very long names, rendering them accessible to the parser again.
Inform also allows the player to refer to the most recently seen objects and people as IT, HIM, HER, and so on. It sets these pronouns by default, but there are times when we wish to override the way it does that. Pot of Petunias shows off a way to make Inform recognize an object as IT when it would not otherwise have done so.
See Liquids for a resolution of this bottle-of-wine issue
See Using the Player's Input for an example (Mr. Burns' Repast) in which a fish can be called by any arbitrary word as long as it ends in the letters -fish
See Memory and Knowledge for a way to refer to characters whom the player knows about but who aren't currently in the room
See Clarification and Correction for ways to improve guesses about what the player means
See Alternatives To Standard Parsing for several esoteric variations on the default behavior, such as accepting adverbs anywhere in the command, and scanning the player's input for keywords
|Start of Chapter 2: Adaptive Prose|
|Back to §2.1. Varying What Is Written|
|Onward to §2.3. Using the Player's Input|
First Name Basis
Sometimes we create objects that we want the player to be able to call by different names: a television that should also answer to "tv" and "telly", for instance, or a refrigerator the player might also call "fridge". In this case, we can use instructions like
to add extra names to the object we've defined.
The holographic projector is a device in the Crew Lounge. "The one major source of entertainment is the holographic projector, a top of the line Misthon 9000, on which you view every beam you can get." Understand "holo" or "holograph" or "Misthon" or "9000" as the projector.
The description of the projector is "[if switched on]The projector is now playing a documentary about the early politics of the Mars colony.[otherwise]The air above the projector is disappointingly clear.[end if]".
(This description is for local color; we will learn more about devices, and conditions like "if switched on", later in this chapter.)
By default, Inform does not understand the names of an object's kind as referring to that object, unless the object has no other name of its own. We can change this, if we like, by defining names that should be applied to everything of a given kind:
The description of Lewis is "A wiry, excitable engineer who just signed aboard last week." The description of Harper is "Harper's a good guy: taciturn when sober, affectionate when drunk, but rarely annoying in either state."
Inform's naming abilities go considerably further, in fact: we can also instruct it to understand words only under certain circumstances, or only when they appear with other words. Fuller details may be found in the chapter on Understanding.
Because of the "...when" part of this line, random text is only treated as an answer when a question is being asked.
Carry out guessing a topic listed in the Table of Dates of Statehood:
if state entry is the current state:
say "Correct! ([comment entry], to be exact!)";
increase the score by one;
now answer mode is false.
This next rule allows a player to do something other than answer the question, but then makes him wait for another question before answering.
Every turn when the player is in the lab:
if a random chance of 3 in 5 succeeds:
choose a random row in the Table of Dates of Statehood;
say "Sam asks you, 'In what year was [state entry] admitted into the Union?'";
now current state is state entry;
now answer mode is true.
Note that the situation will become a little more complicated if we have two or more identical topics in our trivia list; in that case, we would need to loop through the Table of Dates of Statehood explicitly, and only mark the player wrong if none of the lines were found to match. (See the chapter on Tables for many more ways to manipulate table behavior.)
Pot of Petunias
Suppose we have an object that makes a dramatic entrance on the scene, like so:
Some clouds and some trees are scenery in Wide Open Field. The description of the clouds is "That one looks like Yoda's head." The description of the trees is "You've never been much good at botany, so it's anyone's guess what kind they are."
At 9:01 am:
move the broken flower pot to the location;
say "Quite unexpectedly, a flower pot falls from the sky and breaks open on the ground. Good thing you weren't standing six inches to the left.";
set pronouns from the broken flower pot.
If we leave out the "set pronouns..." line here, we'll wind up with the following very unsatisfactory end to our test transcript:
Occasionally it is useful to give something a printed name because we want to call it something extremely long-winded; give one thing a name that is the subset of the name of something else; or use words such as "with" or "and" that are likely to confuse Inform into thinking that the object name ends before it actually does.
Often it is enough to preface these ambiguously-titled things with "a thing called..." or "a supporter called..." or the like, as here:
prevents Inform from trying to read "Hot and Sour Soup" as two separate rooms, while
creates two objects instead of the one orange ticket that would result if the second sentence were merely "The player carries an orange."
Really long names can be a bit cumbersome. For example:
So we might instead give the photograph a printed name:
Now we've gotten around any awkwardness with printing the name -- but we also need to understand when the player refers to the photograph. When we define the names of objects under normal circumstances, Inform takes care of this automatically, but if we have especially set the printed name, we must also specially define the appropriate terms for the player to use. For this we need "understand", which will be explained in much more depth in a later chapter:
That's probably as far as we really need to go, and if you are satisfied with this behavior, there is no need to read on.
One possible objection to this solution is that Inform will accept some nonsensical formulations as applying to the photograph: for instance, it will allow >EXAMINE PHOTOGRAPH OF, >X BLONDE PHOTOGRAPH WOMAN INCRIMINATING, or even >X OF ...though in the case there were two items with "of" names, the game would disambiguate with a question such as "Which do you mean, the incriminating photograph of a woman with blonde hair or the essence of wormwood?"
Traditionally, Inform has tended to be fairly flexible about word order, preferring to err in the direction of leniency. On the other hand, there are times when we need more exacting rules in order to distinguish otherwise similar cases.
Two features allow us to specify more exactly if we so desire. The first is that, if we specify a whole phrase as the name of something, all the words in that phrase are required, in the order given. Thus "Understand "blonde hair" as the photograph" would require that both "blonde" and "hair" be present, and would not recognize >X BLONDE, >X HAIR BLONDE, or >X HAIR.
Second, we can create tokens, such as "Understand "blonde hair" or "hair" as "[hair]", and then use these tokens in match phrases. This saves a good deal of time when we want to specify a number of different but fussy alternatives. So, for instance, here is a drawing that would not respond to >X OF, or >X BROWN EYES, but would respond to >X DRAWING OF MAN WITH BROWN EYES, >X MAN WITH BROWN EYES, and so on:
Understand "eyes" or "brown eyes" as "[brown eyes]". Understand "man" or "man with [brown eyes]" or "brown-eyed man" as "[man]". Understand "[man]" or "drawing of [man]" or "drawing of a [man]" as the drawing.
Further refinements are possible: the "privately-named" attribute tells Inform not to try to understand the source name of an object at all, so if we write
...the player will not be able to refer to it as "purple" or "rabbit" or "purple rabbit".
There are also ways to make names to refer to entire kinds of objects (so "dude" will refer to any man in the game); to specify names that only refer to objects in the plural (so GET PICTURES will pick up several pictures together); to reflect an object's properties (so "red apple" works only as long as the apple is in fact red); or even to refer to the object's relationships to other objects (so "bottle of wine" works only when wine is indeed in the bottle). All these refinements are discussed in the chapter on Understanding.
The Understanding chapter lays out ways to change how the player can refer to objects, but we may not want to wait that long for some of the basic features. Here, for instance, is how to add synonyms that the player can use to refer to an entire kind of object:
The Wine Emporium is a room. "Set aside, you rather suspect, for tourists: this chamber is barrel-vaulted stone, lined on each side with casks of aging wine. Discarded brochures here and there advertise Wine Tours of the Loire Valley in three different languages, none of them French."
North by Northwest
Suppose we wanted to add intermediate compass directions such as north-northwest to our game. Because of the limitations of the index map, we won't be able to view these connections on the world map, but we can certainly create them, and use them in route-finding, just like other directions.
Here's how we'd set up such a thing:
A complication arises because we reach the 9-character limit: Inform truncates the names of objects to nine characters before trying to understand them. To make matters worse, the hyphen (and other punctuation marks) count as two letters. So both north-northwest and north-northeast will get truncated to "north-no", and be indistinguishable when the player types them.
When we are compiling for Glulx, the limit is easily changed with a single line, setting the constant called DICT_WORD_SIZE. For instance, if we wanted to raise the limit to 15, we would simply write "Use DICT_WORD_SIZE of 15."
If we're compiling to the Z-machine, however, we'll have to resort to some manipulation of the player's command. The general solution is that when the player's name for an object is going to have to be longer than we can correctly read, we can substitute an unambiguous abbreviation for the thing the player typed. In this case, it will be simplest and most efficient always to condense the player's direction names to single letters, thus:
After reading a command:
let N be "[the player's command]";
replace the text "north" in N with "n";
replace the text "east" in N with "e";
replace the text "south" in N with "s";
replace the text "west" in N with "w";
change the text of the player's command to N.
For more on the use of text, see the Advanced Text chapter.
A crop-dusting plane is a backdrop. It is not scenery. It is in the Deserted Road and Empty Field. The initial appearance of the crop-dusting plane is "[one of]In the distance[or]Approaching faster and faster[or]Flying ominously low and directly towards you[or]Immediately overhead[or]Circling around for another approach[cycling] is a standard crop-dusting plane."
In practice, this is going to be overkill for almost all games: most players already find eight compass directions plus up and down to be enough (or more than enough) to keep track of. But the option exists, in case there is a compelling reason to use it.
(Note also that we are allowed to use multi-word direction names, so we could have called the directions "north by northwest", "north by northeast", and so on. This example deliberately takes the hard way in order to show how to resolve the nine-character problem.)