§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 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


arrow-up.pngStart of Chapter 2: Adaptive Prose
arrow-left.pngBack to §2.1. Varying What Is Written
arrow-right.pngOnward to §2.3. Using the Player's Input

*ExampleFirst Name Basis
Allowing the player to use different synonyms to refer to something.

*ExampleQuiz Show
In this example by Mike Tarbert, the player can occasionally be quizzed on random data from a table; the potential answers will only be understood if a question has just been asked.

*ExamplePot of Petunias
Responding sensibly to a pot of petunias falling from the sky.

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:

South of Spring Rolls is a room called Hot and Sour Soup.

prevents Inform from trying to read "Hot and Sour Soup" as two separate rooms, while

The player carries an orange ticket. The player carries a thing called an orange.

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:

The player carries a thing called an incriminating photograph of a woman with blonde hair.

So we might instead give the photograph a printed name:

paste.png "Laura"

The City of Angels is a room. The incriminating photograph is carried by the player. The printed name of the incriminating photograph is "incriminating photograph of a woman with blonde hair".

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:

Understand "woman" or "with" or "blonde" or "hair" or "of" or "a" as the incriminating photograph.

Test one with "x photograph / x incriminating photograph of a woman with blonde hair / x hair / x blonde / x woman with blonde hair / x incriminating photograph of a woman".

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:

The drawing is carried by the player. The printed name of the drawing is "drawing of a man with brown eyes".

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.

Test me with "test one / test two".

Test two with "x drawing / x man / x of / x drawing of man / x drawing of a man / x drawing of a man with brown eyes / x drawing of a brown-eyed man / x brown eyes".

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 purple rabbit is a privately-named thing.

...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.

**ExampleLaura
Some general advice about creating objects with unusual or awkward names, and a discussion of the use of printed names.

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:

South of Spring Rolls is a room called Hot and Sour Soup.

prevents Inform from trying to read "Hot and Sour Soup" as two separate rooms, while

The player carries an orange ticket. The player carries a thing called an orange.

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:

The player carries a thing called an incriminating photograph of a woman with blonde hair.

So we might instead give the photograph a printed name:

paste.png "Laura"

The City of Angels is a room. The incriminating photograph is carried by the player. The printed name of the incriminating photograph is "incriminating photograph of a woman with blonde hair".

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:

Understand "woman" or "with" or "blonde" or "hair" or "of" or "a" as the incriminating photograph.

Test one with "x photograph / x incriminating photograph of a woman with blonde hair / x hair / x blonde / x woman with blonde hair / x incriminating photograph of a woman".

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:

The drawing is carried by the player. The printed name of the drawing is "drawing of a man with brown eyes".

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.

Test me with "test one / test two".

Test two with "x drawing / x man / x of / x drawing of man / x drawing of a man / x drawing of a man with brown eyes / x drawing of a brown-eyed man / x brown eyes".

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 purple rabbit is a privately-named thing.

...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.

**ExampleVouvray
Adding synonyms to an entire kind of thing.

**ExampleNorth by Northwest
Creating additional compass directions between those that already exist (for instance, NNW) -- and dealing with an awkwardness that arises when the player tries to type "north-northwest". The example demonstrates a way around the nine-character limit on parsed words.