Promises that parsers can keep

So at our PAX freeplay room, we had this older gamer named Tom wander in. Tom wore a T-shirt from a triple-A zombie game, carried a newly purchased boardgame adaptation of D&D’s Castle Ravenloft campaign setting, and sought us out merely on the strength of our flyers. Clearly, Tom is a renaissance geek: steeped in many traditions, and always learning more. We dutifully got him going on one of the freeplay machines, and he spent about an hour with Alabaster, with only occasional help.

Once when I went to check in on him, I discovered he’d migrated from Alabaster to… the sample game we’d made especially for PAX?! The sample game’s purpose was to illustrate Inform 7 source code, to give the ordinary gamer a taste of computer programming and specifically that of I-F programming. Tom was actually playing the game, and floundering around, trying to EAT JELLYBEANS and DRINK A COKE because these things were in the real room, but not of course in the sample game.

But while scanning his transcript something else caught my eye. In the game, I had changed the command prompt from the > to "You decide to " partly to show that the prompt could be changed, and partly as a way to flag what input was accepted. Tom had entered something like ASK FOR INFORMATION and got a parser question in response – ask who? Unfortunately, then the command prompt appeared beneath, YOU DECIDE TO, and that threw him off, and he was unable to complete the “simple” game for the lack of a noun between ASK and FOR.

Later I grumbled in private that questions that the parser tosses up shouldn’t print my prompt at all. Heck, they should be the prompt. And then it occurred to me that maybe I could make that so. It took all of five minutes. Here’s the resulting transcript, with the code beneath…

“Prompting Plus” by Ron Newcomb

Include Default Messages by Ron Newcomb.

The billiards hall is a room. “You’re nursing a Scotch in the corner of the billards hall. It seems a game of snooker over yonder got a bit rowdy. The players search the floor for missing balls.” A red ball and a green ball are in the billiards hall.

Table of custom library messages (continued)
library-action library-message-id library-message-text
– 49 “[blank command prompt][bold type]Which will you [library message verb]?[ignore library line break][run paragraph on]”
– 46 “[blank command prompt][bold type]Which do you mean, [ignore library line break]”
– 57 “?[roman type][ignore library line break][run paragraph on]”

When play begins, now the command prompt is "[bold type]You decide to ".

Command prompt cold storage is some text that varies.

To say blank command prompt:
if command prompt cold storage is “”:
now command prompt cold storage is the command prompt;
now the command prompt is " ".

After reading a command when the command prompt cold storage is not “”:
now the command prompt is the command prompt cold storage;
now the command prompt cold storage is “”.

Every turn when the command prompt cold storage is not “”:
now the command prompt is the command prompt cold storage;
now the command prompt cold storage is “”.

Test me with “take the ball/red / examine yourself / drop the ball / take the ball/asdf / check yourself / take/red / drop it / take ball / both”.

The room description heading rule is not listed in any rulebook. [bold is for prompts; the room description informs the reader of the setting ][/code]

My purpose in bringing this up is this: though parsers cannot deliver on the promise that they understand whatever you type, merely changing the > minimalistic default prompt, after which nearly anything from HI MOM to WHAT’S UP to WHAT DID YOU SAY TO ME all seem equally likely to work, to a prompt which is either a direct question or an unfinished statement, gives a very strong indicator as to what is expected. This is especially true for the expected part of speech, such as the root form of a verb with or without nouns, or a single adjective like RED.

And that seems like a good way to help the parser keep its promises.

I like this as an extension to the “You decide to” prompt style. It’s pretty much necessary, as you observed.

Small concern: the player can break out of a disambig prompt and type a complete new command. I don’t think the prompt style needs to change because of this, but it’s worth putting in the documentation. Or maybe reminding the player once?

I think it ok the disambig prompt quietly understands more than it says it does. It’s the opposite situation which causes problems. I personally wouldn’t tell the player anything along the lines of, “but you can ignore what it’s asking and enter whatever you’d like” because it sets bad precedent.

(I’m curious now how to make setting different parser modes and setting different prompts a single operation. For example, a prompt that only wants “male/female”, or only wants one topic from a list of them a la dialogue tree. Typically it’s a two-step operation: write whatever rules & code to make the prompt only understand what you need, then write rules to change, and later un-change, the command prompt to the necessary text. A lot of the code in the example I gave deals with un-setting the prompt in various situations (answer given, parser error) and that’s messy to do for each case. Even ensuring a CYOA matching typed numbers to what the menu shows can be a pain when only parts of the game are CYOA. Hm. Maybe a valid command prompts as a kind-of-value, and all parser-altering rules key off of the “current command prompt” rather than the scene or variable or whatever they’d normally watch for? Hm.)

Speaking of, zarf, how is that CSS/Glk/Glulx or whatever proposal coming along, if I may ask? (I’ve totally forgotten the name for it.) You know, the one where the game would be able to tell the interpreter to avoid echoing the Enter key the player presses at the end of the command, so the game could stitch together several prompts and text into a single paragraph? I’m still very excited about that tiny feature.

I sent the Glk stylesheet proposal off to Graham in April, knowing that he’d be too busy to look at it until the new I7 release was done. I figured that his schedule would clear up at the beginning of May… obviously, it didn’t work out that way.

He hasn’t given me an opinion on it, but Emily has recently said that they want to get back to that stuff soon.

I want to spend September working on game design rather than infrastructure. (August was floating-point month.) So hopefully I’ll be back on the infrastructure track later in the fall.

I realize that’s not much of an answer (or rather, it’s the same answer I gave last year). And the input-echo proposal is orthogonal to the stylesheet work – I’m not blocked on it. It’s just not happening this month.

Thanks zarf. (And to the dev team too.)

I was replaying forbidden castle, a 1980’s IF game.

What it seems to do is understand keywords in the text.

For example.

Getting is an action applying to some text. Understand “take [text]” as getting.

Check getting:
if the topic understood includes “sword”, try taking the sword instead.

This allows:




This seems to apply to almost all verbs. What’s more, if an NPC is present, any command it doesn’t understand, it tries to interpret as speech to the NPC, and has the NPC respond.

The innkeeper is here. A sword is here.

Innkeeper: Boy, I don’t understand a thing you’re saying!


Innkeeper: Man that sure is a mighty nice sword you have there…

I wonder if there’s a way to parse things through a “get [text]” command as an alternate as a “get [something]”.

On the one hand I’m all for keywords, on the other hand I think it’s a recipe for disaster to encourage players to type words that will be disregarded. For all we know, those words may provide a context that means the game does exactly the opposite of what the player intended.

You kiss the frog and it turns into a handsome prince!

Depends on the keywords.

You might tag words like refuse, not, no, etc as words that create an opposite effect.

This same game gave forced yes/no choices, by the way.

Fairy: You must kiss the frog. Will you?
You kiss the frog and turn it into a prince.

Not necessarily recommended, but could be a work around.

You’d be guaranteed to miss something, though, along the lines of “TURN SMOOTH DUCK DOWN.” (From Stephen Granade’s Walkthrough-Comp winner.)