Fiction is a Three-Edged Sword

Fiction, interactive fiction and narrative

A proposal for an intelligent IF interface


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.


Author: joningold

Jon Ingold is a writer and games designer from Cambridge, UK. He is co-founder of inkle, a company specialising in interactive narrative for mobile devices. He has written prose, plays, short films as well as interactive fiction, both in hypertext and parser-based systems. His short stories have appeared in Interzone magazine and his IF works have won competitions and awards.

23 thoughts on “A proposal for an intelligent IF interface

  1. I claim First Comment. 🙂


  2. Very nice. I particularly appreciated knowing that “cover goat with blanket” would be understood.

    This is probably a quixe/my old computer/my recalcitrant browser thing, but my keypresses often don’t show up — I type faster than the game can understand it. That’s optimization for you, I suppose.

    Also, there’s no line break after parser errors; obviously the point is partly that there shouldn’t be parser errors, but it looks funny to me.

    (BTW, is there anything more to do once the goat is in?)

    • The keypress-thing is a speed thing, yeah. At present, when the game starts work on an input string, there’s no way to jump out until it finishes. I’m going to look at using the new Glk profiling commands to decide if the interim parser should break out early, and hopefully smooth out some of these issues.

      Hardware is likely to have a big impact, too; I’m running on a fairly modern laptop. I’ve not yet even dared try it on a mobile…

      (Did you rescue your father? But otherwise no; the rain lasts a long time…)

      • Ah! I thought the other puzzle would be to light a fire.

        …hey, wasn’t this in second person? (You’ve still got a “You can see also my father here,” btw.)

  3. Amazing.

    It would be great to actually present the most common/suitable choices to the player as he is typing, like in Google Instant, perhaps with a little intervention from the programmer.

    Excellent work

  4. I’m not sure where the issue is here, but my browser (firefox) won’t let me put keyboard focus on the bar where you type the URL.

    • Thanks for the URL issue: I’ve changed the basic logic a little and the problem’s gone away. (It seems that, every time a new keypress request was declared, it stole the focus, and the game was making new keypress events every second or so, so it can process whenever the player’s isn’t typing. I’ve changed it so it only drops out of keypresses if it isn’t up-to-date. That means you’ll get a bit of focus-stealing, but only for a second or so after you stop typing.)

      The fire would have been the next thing, I guess, but it is only a demo!

      As for the responses, well, I didn’t bother to fix the default messages! And I just can’t write IF responses in second person any more, after doing 50,000-odd words on Klockwerk in first, second now feels too weird.

      • Didn’t mean to give you guff about the person (or the default messages) — I had actually remembered it as being in second person the first time I played it. Maybe because I got a lot more parser errors that time.

  5. Have you played the old Waterloo (by Peter Turcan)?

      • here’s a screenshot:

        The parser error correction is rather simple (highlighting the start of the error on return) but combined with some additional feedback would be a simpler and maybe more effective solution — if the author doesn’t implement certain words in the dictionary the game response isn’t that great (for example, try ‘help’ if there’s no help defined, you might get ‘hear’, etc.).

      • Interesting. But I think I’d rather give feedback to a player before they type return. There’s no reason why a modern computer shouldn’t be able to do that (and it’s what phones do, and increasingly, search engines and URL bars – basically, any typing-based interfaces.)

        Note that the suggestions are driven by the game’s dictionary, so if the author doesn’t implement a word it’ll never be suggested. But perhaps you meant, if the player types something that they expect to be implemented, but isn’t… is the current response (an incorrect suggestion) worse than a “That’s not a verb I recognise message?”. Maybe. But it would better than both for the author to include an “Understand as a mistake” rule to cover a player typing help (“Sorry, kid, you’re on your own.”) Or implement a help command.

        The interesting thing for me is that as soon as you start adding suggestions, they become “the way” to play the game, rather than an aside by the game intended to fix your spelling. That was my original goal with them (in fact, my original original goal was simply to colour words red on the fly if the game wasn’t go to like them. This works very smoothly indeed.)

  6. We started building a similar feature on the Windows Phone for Shadow where it would list known words as you typed…but I just sent the entire word list on a channel…it wasn’t polling the engine.

    I’m wondering how I can do this with Zifmia. I have it so the game engine is cached in a database, but I want to move that to memory. The latency through AJAX might be low enough to do this sort of thing.

    I don’t know how to poll words in FyreVM, but I’m sure it’s doable.

    By the way. This is a common and very productive behavior in most programming editors now. I almost never had to type in all of my code…most of it’s completed with tabs and enters because it just knows what I want.

    It would absolutely help newcomers to offer this sort of thing.

    David C

    • The difficulty with doing this well is that it’s firmly on the game/interpreter dividing line. A suggest feature that just polls the dictionary comes across as a little “dumb”; but a system (like this one) that uses the parser itself to decide what suggestions are good is firmly entrenched in its context, and I can’t see any way of sending enough raw data to the interpreter.

      What I’m doing here for suggestions (plus some optimisations) is polling the dictionary for likely words, then trying each of these through the parser to see if it makes sense.

      But I guess with the extension I’ve got here, you could make it print the suggestion and colour information out to FyreVM as a channel, and have FyreVM return the current input string to the game, and that should all just work — so long as you’ve got code set-up to do this on the game side.

      • I had thought to implement a pre-polling command channel. The idea is that I would take all of the common and not state changing verbs like examine and use them against all in-scope objects, compile the results into a big blob of xml and send it back on a channel. Then the client can hide the data until the user starts typing.

        But I really like your idea of character by character evaluation. I think with zifmia, this might be doable. Since I have the game state cached, I can do anything I want to it and not worry about altering the state of the game.

        I have to look at your extension, but I think it would have to be extensible game by game.

        David C.

  7. Yow. That’s pretty impressive.

    The one thing I find sort of borderline is the *complete* interception of my command – if, for instance, I type “motivate”, the game decides I want to “notify” instead, and that’s kind of weird. (I notice that it moves from deciding I want to “move” to “notify” to “move”, but then “notify” is the command sent – which seems a little odd.)

    Is there no way to send a “bad” command to the game? On the one hand, that’s kind of cool. On the other . . . I don’t know. I can’t exactly come up with a reason to change it other than “it makes me feel funny”.

    • The latest build lets you press Escape to avoid a suggestion. I went back and forth over this a bit, but figured that, in the end, the biggest use case is people typing quickly and making spelling mistakes, and in that instance, I’d rather not have to go back and retype.

      It’s modelled on what the iPhone does, although of course that does use a “dismiss” button to remove suggestions.

  8. A quick update: I’ve released a version 2 of the example game, which should run substantially faster. On Quixe I now get some flickering/missed key-strokes, but running the native blorb is pretty seamless.

    Let me know if you run into problems and please note, I still haven’t looked at how to handle disambiguation prompts!

    • Currently the glulx engine has two interfaces for input, KeyWanted and LineWanted. I’m wondering if we couldn’t extend the engine to also specify what sort of input it needs. Does it want a command? Does it want a Yes/No response? Does it need the user to choose one thing from a list of things?

      If the interpreter had this information and it had the item list for the multiple choice disambiguation question, it could style the input appropriately.

      Just thinking out loud.

      David C.

  9. Pingback: Interactive Parsing extension, version 1 | Fiction is a Three-Edged Sword

  10. Pingback: Interactive parsing update | Fiction is a Three-Edged Sword

  11. Pingback: Sand-Dancer Sans Keyboard: An Experiment with Hyperlink Input in IF « Glimmr

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s