16.19. Does the player mean...

| Chapter 16: Understanding |

| 16.19. Does the player mean...

When the player types an ambiguous reference, we need to work out what is meant. Consider the following source text:

> The Champs du Mars is a room. The great Eiffel Tower is here. "The great Tower stands high over you." The souvenir model Eiffel Tower is here. "Comparatively tiny is the souvenir version."

Now suppose the player types GET TOWER. The response will be:

> Which do you mean, the great Eiffel Tower or the souvenir model Eiffel Tower?

Which is a silly question, exposing our work of IF as something artificial. It's obvious to the author of the source text, and to the player, that the souvenir must be what is meant: but this is not obvious to the computer program running the game. Works of IF gain a subtle feeling of quality from being able to understand ambiguous references of the kind above, and Inform provides us with a way to do this by giving the parser clues in the form of "Does the player mean..." rules. For instance, if we add:

> Does the player mean taking the great Eiffel Tower: it is very unlikely.

then the response to GET TOWER will now be:

> (the souvenir model Eiffel Tower)
> Taken.

"Does the player mean..." rules look at the actions which are possible interpretations of what the player typed, and grade them according to how likely they seem. (Note that these rules are only ever used to handle ambiguities: if the player unambiguously types GET GREAT EIFFEL TOWER, that will be the action. And the rules are only used where they are able to make a decision: if there are still multiple equally plausible meanings, the parser will ask about all possibilities, not just the most likely ones.) Rules in this rulebook can either decide nothing, or come up with one of the following verdicts:

> it is very likely
> it is likely
> it is possible
> it is unlikely
> it is very unlikely

If there are no "does the player mean" rules, or the rules make no decision on a given possible action, it will be ranked as "it is possible".

We may use these rules to affect all sorts of interaction with a specific object or kind of object, as in

> Does the player mean doing something with the cursed dagger of Thog: it is very unlikely.
> Does the player mean doing something with the cursed dagger of Thog when the player is hypnotized: it is likely.

...and so on.

Notice that we can also make rules about actions that apply to two objects, so for instance:

> Does the player mean throwing the can of shoe polish at the shoe polish vending machine: it is likely.

which nicely clarifies THROW POLISH AT POLISH, but does not comment on the likelihood of throwing the can at other things or of throwing other things at the vending machine. Moreover, the (suspected) identity of the first item will be known when the rule is consulted; thus

> Does the player mean tying the noun to the noun: it is very unlikely.

will tell Inform to prefer not to tie something to itself if other interpretations are available.

But there is a caveat. There are some cases where this mechanism will not in fact help Inform to choose its way out of an ambiguous command, because of the way it parses one noun at a time. It usually needs to understand the first noun before it will even try to make sense of the second. So a rule like:

> Does the player mean throwing the can of shoe polish at the tree: it is likely.

may not work if the player types THROW POLISH AT TREE and POLISH is ambiguous, because when the parser is trying to understand POLISH, it hasn't yet seen to the end of the command and realised that the second noun will be the tree; so the second noun is unset and the rule won't match.

As a caveat to the caveat, the "inserting it into", "removing it from" and "putting it on" actions have this slightly back to front. These are parsed using the (little-used) "[other things]" or "[things inside]" tokens, and the Inform parser tries to detect the second noun before the first one, since the identity of the first has to depend on the second. So for instance if the situation contains "an oak tree" and also "an oak chest", we could write:

> Does the player mean inserting into the oak chest:
> it is very likely.

which would successfully make PUT COIN IN OAK mean the chest, not the tree. (Note the way we write "inserting into" without saying anything about what's being inserted, not even that it's "something".)

315
| Example Masochism Deli Multiple potatoes, with rules to make the player drop the hot potato first and pick it up last. |
RB

Previous | Contents | Next