down the rabbit hole of parsing

I've been wanting to write an update post just to assure those that care that I have been working on Roodylib stuff, but it's been hard to pull the trigger as I imagine parsing quirks isn't very interesting to most people.  Then again, if I knew of some blog that was one author's exploration of parser theory or battles against an existing parser, I'd probably read it.  Just the same, anyone who doesn't care can skip down to the "In other news" section below.

So, what with the release of HugoJS, I really want the next version of Roodylib to be as flawless as possible, both for the possible re-release of older games (so they operate best in all kinds of interpreters and make use of Roodylib's accessibility options) and for future games.  To this end, I've been making "recordings" (*) of games with available source and testing the playback against both the original and Roodylib-compiled version and then checking for errors.

( * In several IF systems, typing "RECORD" in a game will begin a transcript that only writes commands to a file.  Then, the next time you play the game, typing "PLAYBACK" will allow you to select the file.  At this point, the game plays all of the commands from the recorded file,  This is a great way to see how the same set of commands affects different versions of the same game.)

Luckily, several of the games have available walkthroughs to make this easier, but it's still slow going; many of the games have random elements so I "normalize" the random number generator to make them predictable.  Several of the games use a conversation system that handles choice entry through GetInput which isn't caught by recording/playback so I wrote a modification to the conversation system to allow making choices from the regular prompt.

I had finished going through a couple games (and, in the process, found a couple Roodylib bugs) when I caught a conversation where Jesse McGew speculated about optimal ZIL behavior when it comes to disambiguation questions within multiple-command inputs.

Say you have a command like this:

>EXAMINE BOX. GET IT. DROP IT.

The issue was, if the game responds with "Which box did you mean, the cardboard box or the glass box?" and the player chooses one, should it then proceed to process the rest of the command?  Inform does proceed, but making the player re-type the rest could be seen as a viable approach, as it is an error of sorts and every IF language is allowed its own expectations of how to handle such situations.

This got me curious about how Hugo/Roodylib currently handled it.  I found that if the player used the disambiguation system added by Roodylib (using "1", "former","2", "latter" and such to refer to listed options), it cleanly stopped processing the rest of the command, but if the player used the engine-based disambiguation system (typing in "glass" or "cardboard"), the rest of the word array got mangled and resulted in a "I didn't understand that." response.

First, I added some hacky code so the engine-based disambiguation also exited cleanly, but then I decided that I preferred the "KEEP ON PROCESSIN'" behavior and modified both versions to do that.

Unfortunately, this opened up another can of worms as I then noticed that the "G"/"AGAIN" code was somewhat broken.   Fixing this took quite a while as I had to re-acquaint myself with all of the parsing code.

Now, everything works again and, in fact, works better than it did before I started.  The old code, borrowed from the original Hugo library, only restored the last command when "AGAIN" is used, so a multiple command input like >SHAKE CAN. G.. OPEN IT.  would lose track of the rest of the command before it got to "OPEN IT". As in, when AGAIN is called, the entirety of the word array was replaced with just "SHAKE CAN".  Now successive commands are not lost and are properly parsed.

Now that I have it working, I plan to clean up the code a bit and maybe put in some hooks so authors can easily put in optional behavior.  For instance, if an NPC is given a command that is an xverb ("save","undo","restore"), Roodylib intentionally gives the error "That doesn't make any sense."  The previous Hugo behavior was just parsing it like all is well, likely leading to a "So-and-so ignores you." response.  So, I'm sort of considering putting in some kind of hook so authors can re-direct it to some kind of "So-and-so says, 'Do what now?'" response if they'd like.

As soon as I'm done with that, it's back to testing games, followed by more general code clean-up and documentation updates.  Given that real life has been fairly hectic and will be for the foreseeable future, this will be a multiple month process.

In Other News

Hugor's Nikos Chantziaras is credited on the development team for a new TADS 3 game by Bob Bates (of Infocom and Legend Entertainment fame).  "Thaumistry: In Charm's Way" is currently being funded on Kickstarter.  I was lucky enough to be in its first wave of alpha testers and found it to be quite a fun romp.  I've been watching the kickstarter progress obsessively and am really looking forward to the finished product.  I'm sure almost all readers of this blog have seen an announcement for it somewhere else, but I just wanted to throw my personal recommendation out there!