§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.
or
Understand "birds" as the plural of the magpie.
Vouvray demonstrates.
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 game 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 |
|
|
|
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." Even so, if we try to compile
Inform will misunderstand our meaning. 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:
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. |
|
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." Even so, if we try to compile
Inform will misunderstand our meaning. 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:
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. |
|
|