§6.17. Clarification and Correction
Some commands and some objects raise special challenges when it comes to working out the player's intention.
Sometimes this can be done with good rules about the assumptions Inform should make. Alpaca Farm demonstrates a USE command, always a challenge because USE can mean very different actions with different items.
There are also times when we need to ask the player for more information. Apples demonstrates how sensibly to use properties to disambiguate between similar objects, while Walls and Noses rephrases the disambiguation question when special objects are involved: examining one of the walls of the room will make the game ask "In which direction?" and EXAMINE NOSE will lead to "Whose nose do you mean, Frederica's, Betty's, Wilma's or your own?"
At other times, the player types something that is wrong in a predictable way: for instance, we might want to remove all the "with..." phrases from commands like
HIT DOOR WITH FIST
KICK DRAGON WITH FOOT
LOOK WEST WITH EYES
and merely parse the remainder of the command. (That last command may be unlikely, but novice players do quite often type commands that refer unnecessarily to body parts.) Cave-troll demonstrates how.
WXPQ demonstrates how to modify the error message the parser gives in response to a command it doesn't understand; this particular example focuses on the "That noun doesn't make sense in this context" message that arises from using the "[any thing]" or "[any room]" tokens, but the techniques could be adapted to handling other parser errors as well.
For catching typing errors, Cedric Knight's extension Mistype may also be of use: it provides an automatic typo-correction function that the player can turn on or off.
![]() | Start of Chapter 6: Commands |
![]() | Back to §6.16. Alternate Default Messages |
![]() | Onward to §6.18. Alternatives To Standard Parsing |
|
|
The parser error "That noun did not make sense in this context" arises instead of "You can't see any such thing" when the player uses a command that could apply to any item in the game -- that is, a command such as
...and so on. The idea here is that "You can't see any such thing" isn't a sensible rejoinder when the player doesn't really need to be able to see the object. Nonetheless, "That noun did not make sense..." is itself a fairly dry and uninformative response, and we may want to override it to something more appropriate for the specific kind of context in which it might appear. For instance:
Note that this solution works as simply as it does because we only have one command in the game that can apply to an "[any]" token. If we had several, we'd need to distinguish between the parser error attached to "discuss" and the parser error attached to "go to" (for instance). In that case, we might instead write something like
|
|
The parser error "That noun did not make sense in this context" arises instead of "You can't see any such thing" when the player uses a command that could apply to any item in the game -- that is, a command such as
...and so on. The idea here is that "You can't see any such thing" isn't a sensible rejoinder when the player doesn't really need to be able to see the object. Nonetheless, "That noun did not make sense..." is itself a fairly dry and uninformative response, and we may want to override it to something more appropriate for the specific kind of context in which it might appear. For instance:
Note that this solution works as simply as it does because we only have one command in the game that can apply to an "[any]" token. If we had several, we'd need to distinguish between the parser error attached to "discuss" and the parser error attached to "go to" (for instance). In that case, we might instead write something like
|
|
|