Fiction is a Three-Edged Sword

Fiction, interactive fiction and narrative

Interactive Parsing, v2


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.)



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 “Interactive Parsing, v2

  1. Definitely impressive.

    A few nitpicks and one apparent bug, which should not in any way suggest that I’m other than really impressed you got this behavior to work in general.

    Sometimes it feels like I’m out-typing the thing; and it doesn’t cope with my instinctive habit (from other programs) of typing tab to accept an autocomplete suggestion. Also, thanks to the 9-letter dictionary knowledge, sometimes it will suggest things that are truncated versions of the real word, and that looks funny: I was trying to type SACRIFICE GOAT and the game suggested the command SUPERBRIE. Naturally I was fascinated by the promise of heroic dairy products until I realized that this was just the SUPERBRIEF command in truncated form.

    The bug is that eventually I got a Glk access out of bounds error and the game crashed entirely. The command I was trying to type at the time was PUT SHEET ON GOAT, but I suspect the problem was something cumulative rather than particular to that command.

    • Thanks for the feedback.

      The 9-letter issue is solvable, and fairly easily – I just need an I7 table or something to convert a dictionary word into a full-word. The author would then have to fill this in as they find them, but there’s nothing in the architecture to prevent this [that I can see].

      The tab thing is a weirdness: the code is set up to use Tab as a complete-key, but it doesn’t seem to work. It may be that the interpreter/OS is stealing the keypress, I don’t know. I agree, it would be natural to have it.

      The out-typing is the more serious, and you’re quite right, it does happen. The problem is that Glulx provides no way to check if a key has been pressed without pausing the game for at least 1millisecond – that’s not much, but it means I can’t have the game respond to keypresses while it’s thinking instantly; instead it checks periodically. These intervals are short, and if you press a key during one it will store it and use it; but if you type fast enough to press two keys in a process-window (and it’s not hard to do), then your second keystroke will get lost.

      I can make the process windows shorter, but then the actual business of getting a suggestion takes much longer, because the game has to keep dropping out of what it’s doing to check the keyboard. I may be able to write a better check-for-keypresses logic using the new glk profiling/timing calls, but I’ve not yet looked into that.

      The short of it is, really, the game and the interpreter should be working together more closely. With a bit more thought, I’m sure these issues could be improved.

      But look. Look. It was possible. It works. And doesn’t it feel nice to play?

      (Oh, and the crash: damn. I’ll have to look into it. I’ve got a few suspicions, but no solid idea. Fingers crossed.)

      • This is really great.

        The out-typing behavior doesn’t seem to happen in Gargoyle. If it’s not happening in Quixe, it may be a bug in Zoom rather than an issue with your code.

        Transcript triggering an out-of-bounds memory access:

        That’s not a verb I recognise.

        (to Anthuk)

        [** Programming error:
        *** fatal error: Out-of-bounds memory access ***

      • Excellent. A repro! I’ll get on it.

      • And fixed. Causes a random writing somewhere into memory error when a word of more than 20 letters was entered.

        That limit has now been lifted. 😉

  2. Hello!

    I’m really eager to try this out in my game, I’m including it along with the extensions listed below, however I get a Flexible Windows error at compiling…

    Do you know how I can fix whatever’s conflicting here?

    Dustin N.

    Include Interactive Parsing by Jon Ingold.
    Include Player Experience Upgrade by Aaron Reed.
    Include Plurality by Emily Short.
    Include Keyword Interface by Aaron Reed.
    Include Automap by Mark Tilford.
    Include Glimmr Automap by Erik Temple.
    Include Glimmr Automap Tileset by Erik Temple.
    Include Glimmr Bitmap Font by Erik Temple.
    Include Adaptive Hints by Eric Eve.
    Include Simple Graphical Window by Emily Short.
    Include Basic Screen Effects by Emily Short.

    In Chapter 5 – Writing to different windows, Section – Background colours in the extension Flexible Windows by Jon Ingold:

    Problem. You wrote ‘Table of Common Color Values (continued) glulx color value assigned number g-placenullcol 0 g-darkgreen 25600 g-green 32768 g-lime 65280 g-midnightblue 1644912 g-steelblue 4620980 g-terracotta 11674146 g-navy 128 g-mediumblue 205 g-blue 255 g-indigo 4915330 g-cornflowerblue 6591981 g-mediumslateblue 8087790 g-maroon 8388608 g-red 16711680 g-deeppink 16716947 g-brown 9127187 g-darkviolet 9699539 g-khaki 12433259 g-silver 12632256 g-crimson 14423100 g-orangered 16729344 g-gold 16766720 g-darkorange 16747520 g-lavender 16773365 g-yellow 16776960 g-pink 16761035’ : but this does not seem to be a continuation or amendment, since the name/number do not match any previously defined table. (Perhaps you’ve put the continuation or amendment before the original?)

    In the main source text:

    Problem. The table name ‘Common Color Values’ will have to be disallowed as it is already the name of an existing table (of which it is not a continuation).


    Problem. The table Common Color Values was said to be a continuation or amendment, but it contains columns not found in the original.

    • Hey –

      The issue here is between Simple Graphical Window, and Flexible Windows, both of which include the extension Glulx Text Effects.

      Try changing the order in which these extensions are included and see if that helps.

      I’m not honestly sure you need SGW with FW, though; I think it would be better to leave SGW out and keep FW in, as it gives you the same functionality + more. (But I’ve not checked in detail.)

  3. I still think you’re looking for trouble by re-implementing line input yourself.

    Emily, surely for Glulx there must be a way to move past dictionary length limits?

    • Quite possibly, but I just don’t see any other way to do it.

      Line input events can’t respond to the individual values of keypresses – as far as I can make out – so I can’t use space/tab/whatever to autocomplete.

      To be honest, though; I’m don’t think this extension – or any extension – is the real way to do this. It’s all we can do at the moment, but my point is more that:this kind of predictive/parser-led real-time feedback is both achievable and desirable. Now let’s get the opcodes and the interpreter/game functionality that let’s us do this properly and stop pretending that we’re getting all our output from a line feed printer. 😉

      • Fair enough! If you can figure out exactly what new opcodes/Glk functions are needed I’m sure we can make that happen.

        What I would do in something like Javascript would be to have the regular line input, but then also register handlers for specific key combinations. So rather than requesting a single key and checking if it’s what we want, we’d let the interpreter check and only run the handler if it does. Key combinations would be good for this too, I don’t think they’re really detectable in Glk currently.

  4. I tried plugging this into the edgiest of edge-cases — a demo I’d written that runs entirely on keyword input, disabling every other command (you can see it and its source code here). It wasn’t too surprising that the interactive parser didn’t do anything with ‘Understand “[any theme]” as keywording.’ — it doesn’t recognize “attic” as valid input even though “attic” is understood as a theme — but it continues to suggest “attack” even though there’s no place for attacking in this game. (In fact, I’m using Juhana’s code for disabling the standard grammar.)

    Will there be an easy way to have the parser not suggest things that aren’t particularly useful; say, to have it not suggest “attack” if attacking isn’t in fact implemented? Also, how does it handle commands that use topics?

    • (I realize that may complaint may be “This doesn’t turn out to be completely magical.”)

      • Yeah, that’s the gist. 😉

        Essentially, the system is optimised to look for verbs at command one (It probably doesn’t handle, BUNNY, HOP NORTH very gracefully either). But it should be an easy fix.

        If you open up the extension and search for SuggestVerb(, you’ll find the block:

        if (next_token_type == EX_VERB || wordnum == 1)
        SuggestVerb(analysed_word_buffer, run_to_halt);
        } else

        If you change that first if statement to something like

        if (1 == 0 && (next_token_type == EX_VERB || wordnum == 1))

        then – and I’m not sure about this – but it might just work. (Though it might be kinda slow; there’s a few other optimisations that assume the usual grammar.) Let me know how you go, and if this doesn’t work.

      • OK, I’ll try that. (I’m very much not conversant with I6 — reading it makes me feel like I’m playing Bad Machine — so I probably won’t be able to do anything besides copy-pasting that exact string.)

        I was thinking about exactly what kind of magic I do want, and it’s this: it’d be nice if the parser were highlighting/suggesting any custom verbs that were implemented by hand, which I think is already happening. That’s how the example game is able to suggest “cover,” isn’t it?

        And it would be especially nice if the programmer were able to type things like “The action of attacking, the action of swearing mildly, the action of swearing obscenely, the action of jumping, and the action of kissing are not implemented.” Then the parser wouldn’t suggest or highlight verbs leading to those actions — the parser still might produce “Violence isn’t the answer to this one” or some custom message, but it wouldn’t be suggested.

        (BTW, if you look at my source code, I commented out the I6 inclusion in order to make it compatible with your extension.)

      • it’d be nice if the parser were highlighting/suggesting any custom verbs that were implemented by hand

        This will happen automatically. The only reason it didn’t in your case, is that the the parser stores verbs in a particular way, so the system generally looks for verb-type-words on word 1. So if you use a keyword system, the game won’t hit on your words (but try that fix I mentioned above).

        And it would be especially nice if the programmer were able to type things like “The action of attacking, the action of swearing mildly, the action of swearing obscenely, the action of jumping, and the action of kissing are not implemented.”

        Hmm. I mean, you can strip the grammar from Inform completely (Understand the command “attack” as something new), but that takes a while. What you’re suggesting is more like a “black-list” of verbs (or words in general).

        That’s definitely possible – the extension pre-processes the entire dictionary, so you’d just need to tell it to skip out words listed by the author in a table or something (it already does this to leave out “untypeable” words like “comma,”, which the parser uses.)

        I’ll put it on the list, but no promises of a quick fix…

      • you can strip the grammar from Inform completely (Understand the command “attack” as something new), but that takes a while.

        I don’t think that’s doing what I want, though. Even after I explicitly add the “Understand the command ‘attack’ as something new” line, I’m still getting the autosuggestion of ‘attack’ when I type ‘a’. It disappears when I type the first ‘t’ in ‘attic’, though.

        I forgot to mention that in my game every command is always green as you type it — which is probably as it should be when I have a wildcard token as a verb. (Actually I couldn’t remember which color was good and which bad.) Also, this is all without the modification to Interactive Parsing that you suggested; I’ll try yours when you have a little more time.

        In “Orkney,” I noticed that as I type “attack” it suggests “attack” after the “a,” “ask” after the first “t,” then “attach” after the second “t” all the way to the “k.”

      • Oh, right, yes. If you read the bit in the documentation about the Table of Single-Letter Verb associations, that’s what causing the “attack” verb to still be suggested.

        But now you mention it, ASK is possibly a better default for a single-letter A anyway.

        But if you do the hack, you shouldn’t need to worry about this any more.

  5. With your hack it seems to be suggesting very short words, alas. (“Am,” “on,” “to,” etc.) Oh well. (I hadn’t really planned to use Interactive Parsing with projects of this type anyway.)

    I hadn’t noticed the Single-Letter table — I think I’d probably map “h” to “hit” (or maybe “help”), which is how I usually attack things, and I wonder whether “kick” is helpful at all. Still, these are things the programmer can change easily. I do wonder whether it might sometimes be misleading to have a unique suggestion at any time — maybe “attack” and “attach” could both be useful when “att” has been typed — and “ask” for “at” still seems weird.

    Not to take anything away from what you’re doing; it’s very nice.

    • Ah, tricky. It’s not easy to distinguish between nouns and prepositions. You could do it, but it’d be more than a one-line change, I’m afraid.

      The “ask” for “at” problem has been fixed in the latest, though; the game was putting way to much emphasis on word-length. That’s been dialled back to just a differentiator if everything else is the same (so TABLE matches TA before TABLETOP, instead of preferring TOME).

      This *may* also fix the library suggesting short-words for keywords – I’d be interested to know if it does – but I’m not convinced that it will.

  6. Pingback: “Flaws”: an interactive story for Kindle | Fiction is a Three-Edged Sword

  7. I’m really impressed with the example as presented. However, it does present a problem that whenever I write “anthuk”, then a comma, then a space, the autocorrect will render it as “anthukattack.”

    The experience of actually using this enhancement to the interface is so smooth and fluid that I actually feel somewhat bad for complaining, but there it is.

  8. I just found your interactive parsing – very cool. I had a similar idea myself at one point: I had been wondering if I could achieve something similar in inform7 … still trying to work out what language inform7 extensions are written in 🙂

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s