Interactive Parsing is now up to version 2. This latest release handles disambiguation prompts by the parser.
This release means the extension is now at playable quality and while I’m sure there are still improvements to be made, the extension is serviceable with no known bugs.
The approach taken to deal with disambiguation is reasonably interesting, so I’ll talk more about that after the cut.
Disambiguation questions, such as:
Which do you mean, the red cup or the blue cup?
present a challenge for the Interactive Parser. That’s partly because of where they’re handled by the normal Inform process (right at the bottom of the parser, instead of at the top where typing normally happens).
But it’s also because of their structure. The idea that the game would stop, ask you a question, get an answer, and then continue, is very tied into the input/output interaction model. Isn’t that what this extension is trying to get away from?
So before I cut up and hacked into the parser, I stopped to actually do some design. (This was the first time I hadn’t just been able to steal all my ideas from the iPhone.) The question was: what are disambiguation questions good for?
The answer, I think, is that they spells out the player’s options. In general, this is considered a bad thing in parser IF, where the “open prompt” is our genre’s defining feature and albatross, all in one.
But when there’s enough confusion/overlap that the parser can’t work out which one of many things you mean, suddenly not listing options is a bit like blindfolding the player in a first-person shooter. The protagonist would have no problem choosing between the red and blue cups, after all. Do we want the player to be faced with some kind of bizarre memory game, where they need to recall while typing an input line which keys they have, or what colours the levers are?
Almost certainly not. But a suggestion/prediction system that removed the need for disambiguations (by, say, marking ambiguous input with a highlight, until the player went back and typed more detail) is good, but it’s not as good as a set of options. (Maybe even a set of options which numbers to pick which one you want.)
But the standard model – a parser question, to which the player types a response – does take away from Interactive Parsing’s mandate of encouraging the player to be always typing full, complete, correct commands, all of the time.
So the solution I’ve decided to pursue is a balanced approach, that combines the strengths of both. It keeps the call/response, input/output structure, with the player typing a command, and the game responding with a request for more input. But instead of the game simply asking and a new prompt appearing, the player’s player’s previous command is recalled and the cursor positioned at the point where the ambiguity was.
The game and the player work together to fix up the command.
(At the moment, the first command is still printed to the transcript (as are parser errors) – it might be better if internal messages like this stayed in the input window, but that doesn’t feel like core functionality, but extensions on top of what’s already here, so I can leave that for later.)
So version 2 of the extension brings in new features for free: command line recall, command line editing, suggestions for whichever word in an input line the player is currently working on, and – almost for free – disambiguation input handling.
(The sad cost is the Quixe version, which now fails. This might be a bug in the interpreter and it might be a sloppiness in my code; at the moment I’m not sure.But in Zoom the example game is zipping along.)