I thought I’d share an Inform 7 programming tip I’ve come up with in recent work on my new game.  As you could probably have guessed from previous blog entries (here and here), I’m using a keyword-based interface in this new work.

At its core, what a keyword-based interface does is to link up a generic single-token input to one or more default actions, such as examining, asking about, or going.  Here’s a very basic example of some code that you might use to effect this:

Understand "[something]" as examining.

Simple, right?  Now if you type a word that refers to an object, the game will examine it.

Well, most of the time it will, except in a couple of annoying cases.  What if you have a drill in your game?  You could refer to the drill as the keyword “drill”, but if you have a drill you likely also have a drilling action as well.  What happens then?

Drilling is an action applying to one thing.

Understand "drill [something]" as drilling.
Understand "drill in/into [something]" as drilling.

What happens here is that whenever you type “drill”, the system immediately assumes that you want to use the specific “drilling” action rather than the generic keyword examination, and it asks you to clarify what you want to drill.

Likely this is not really what you want.  If it is, you’re fine; you can leave things as they are.  But in a keyword-focused game, you might judge it more important to preserve the behavior of the keywords and force the user to actually specify an object to drill if they want to perform the drilling action.

The reason the parser resolves a command of “drill” the way it does is not easy to pin down through standard Inform debugging commands, but is almost certainly due to the same general prioritization rules that it uses throughout the system:  the most specific match wins.  Even though “[something]” and “drill [something]” are both potentially valid matches for an input string of “drill”, Inform counts the exact text match of the drilling action as a closer match, even though it requires a second token. To Inform, that’s not a problem; it knows how to prompt the player for that required noun.

To get around this behavior, you need to provide a match that’s even closer.  Fortunately, this is pretty easy:

Drill-referring is an action applying to nothing.

Understand "drill" as drill-referring.

Instead of drill-referring:
	try examining the electric drill;

Now we’ve implemented an action tied to an exact match to the input token.  “Drill-referring” is now the best match for an input string of “drill”, and we can wire up the “drill-referring” action to do the appropriate thing.

Likely you won’t run into this type of behavior in a whole lot of places, but it can be nice to know how to resolve it if you do.