The IF Demo Fair at PAX is now in full swing, and I’m not there, but reading about it has started me thinking about what the best IF interface would be like. Details and an example follow after the cut.
In the past, I’ve been an advocate of error messages being automatically hidden from the player, once they’re served their purpose. IF is curious in leaving these examples of blunders and mistakes in full-view, to the point of actually obscuring meaningful text. It would be much better, and cleaner, if error messages appeared after a bad command, and then were “folded away” once the player had produced some comprehensible input.
Looking at the question now, I think this doesn’t go far enough. If I had to produce a single-sentence paradigm for an IF interface it would be:
The player should know, before they hit return, if the command they’ve typed will be understood.
This isn’t unreasonable: the standard phone-typing interfaces make it hard to enter a spelling mistake; Word has been correcting letter substitutions and underlining grammatical mistakes for years. And the implementation of this doesn’t have to turn the game into a process of selections from drop-down lists: it could be as simple as words being highlighted red (if they’re not in the game dictionary), blue (if they don’t make sense in context, like the third and fourth words in “go up to counter”) and black it they’re okay. The colouring would be updated on the fly, character-by-character or word-by-word.
Under the hood, the game would be silently running the parser after every keystroke and returning its findings to the interface layer. Obviously, no in-game event would be triggered.
Ideally, this would be achieved by an extension to the specs: the interpreter would need to be able to send a certain type of message to the game, and the game reply with more data. That’s not possible right now. But a mock-up could be built, if we used character by character input instead of a line.
(A quick aside: I’ve actually done key-by-key input before, in My Angel. In that game, the status line was used for input and error messages. After a parser error, I wanted the error message to disappear once the player started typing a new command, but I wanted that first key-press to also be the start of the command, so that the player wasn’t pressing a button to clear an error, but just getting on with the game.
The only way to do this was to read input character by character, print it to the screen, and send the lot to the parser when the Return key was detected. In this mode, you lose some of the command recall functionality built into interpreters – but I don’t remember any reviewers at the time noticing that a switch in mode had occurred. And it does mean you can edit, recolour and control the command as the player types it in.)
So the mock-up would:
- Read in input, letter by letter
- Pass the current word to the dictionary every letter to see if it’s understood
- If it is (and all the other words are too), pass the whole command so far to the parser, to see if that’s understood
- If it isn’t, communicate the error – was it a misunderstood verb? Or an unexpected additional word? Or an unrecognised noun? Find the first failing word and highlight from there.
There might need to be some tweaks to deal with passwords and such like, but that doesn’t seem impossible.
So, in the spirit of the IF Demo Fair, I present the following example:
Note, there are a few more optimisations to be made for speed, and I’ve not added support for line editing or handling disambiguation questions.
On the plus side, this requires no work from the game-author beyond a one-line extension file include.