Fiction is a Three-Edged Sword

Fiction, interactive fiction and narrative

Interactive Parsing, v4


It sometimes feels like I’m releasing a new version of this every two days, but Interactive Parsing is now up to Version 4. The new version is substantially faster, especially if what you’re typing makes sense. Running on my MacBook, it now feels like a normal command line. And on Quixe, well, it’s not too bad.

Here’s the changelog:

  • Minor bug-fixes, including one error which would cause AGAIN to follow under certain circumstances.
  • Blank input lines are now once more silently rejected.
  • Providing customised parser errors no longer causes infinite loop (*facepalm*).
  • Optimised the calculation of scope by caching results of scope searches and matches against scope.
  • Changed the way scores are calculated so that it’s easier for words to be maximal, so the loop can drop out earlier.
  • Changed the logic for word length. The system now preferences words which are longer than what the player’s typed over words that are shorter.
  • Changed the order in which words are considered, so the most recent suggestion is checked first, making it more likely that the loops will drop out earlier.

…and the greatest of these is the last one, which means basically means that when game and player are in agreement over what’s happening, the analysis system mostly drops away completely.

There’s still some skittishness in the UI of suggestions on narrow screens that I’d like to fix, and I wouldn’t be surprised if the game can still be crashed in some baroque fashion. But broadly, I’m quite pleased with progress.

In particular, I’ve been using it in my Glulx port of Make it Good (and that’s driven a lot of the optimisations), and it’s now working at a pretty respectable speed. (Here’s an online version up and running. Curiously, it’s really all the stuff after the parsing that’s slow. One for another day, maybe.)

Usual link-block follows.


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.

7 thoughts on “Interactive Parsing, v4

  1. It would be nice if the logic could be abstracted away from Glk and made to be an internal library first, then have the Glk parts consume the internal library.

    • It would, and it mostly is: there’s only two places that use glk calls; the key-input routine and the CheckForExit routine that interrupts processing if a new key has been pressed. The worst offender is the input routine but that kinda has to be glk-heavy because of the threading of typing and processing. It could probably be broken up a little more.

      The other glk calls in the source are commented out debugging prints. Oh, and the actual routines for printing characters to the screen.

      But my feeling is still that a chunk of what it’s doing should be done at the interpreter level – higher up, rather than lower down. For instance, the author could supply a font information set for the line the player’s typing in so it can be re-rendered as the player types as more results come in.

      • I only reviewed the first version. What I’d like to see is a new async command that sends a set of characters into the engine and receives a list of commands. Or, use a pub sub model, where there’s a listener that catches an ever changing list of possible commands. But I’d also like to tweak the whole thing from the terp side. So limit the objects to review, limit verbs, etc. Then I’d make a terp like tool that would create new engines on the fly, execute each command, store the result, andvoffer this to the author as a tool for game development.

  2. Performance on Quixe is interesting (Firefox 4 and Chrome 10 on a MacBook running 10.6). When I try either the example game or Make It Good, I’m seeing a very quick response time for the hard stuff (key capture and printing, autosuggest, replacement, coloring). But there is a long delay, of at least one second, complete with spinning beachball, after pressing return. I may be misremembering, but doesn’t this reverse the response time dynamics of earlier versions? I recall them being slow during input, but processing input as quickly as the average Quixe response time…

    (The delay is even longer, I’d guess 5 seconds, for Make It Good, but of course that may be partially due to other issues.)

    • Yeah, I seem to have got the hard stuff down to picoseconds but at a cost somewhere else in the code. (Part of me was wondering if this was Quixe being non-optimised, but the chances are it’s my fault).

      I’m going to look into seeing whereabouts the time is going and if I can speed it up. There really shouldn’t be that much done between turns, though.

  3. I may have found a bug or at least odd behavior. When you include the v4 extension, the “it” pronoun is set to north (the direction), irregardless of whether there’s something in that direction or not.

    • Thanks for the report. You’re not the only person to have found this behaviour, but I’m having trouble replicating it with my version of the file. Could you send me an example source to demonstrate this?

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