So... how good does a parser have to be these days?

Authoring General Design Discussions
1

I grew up playing a lot of “two word” parsers in the early 80’s and yeah, Zork I was a bit of a breath of fresh air.

But seeing some various discussions across different categories here, I’m wondering how good a parser really needs to be?

(In particular, I understand that there is a common set of verbs that should work in any game, and if your game supports a “weird” verb it should either be in the intro text or make it clear in a description. I also like the idea that any noun referenced in a description should probably be understood by the game, even if it’s a default “You don’t need to worry about the (whatever) to play this game” message)

So, ATTACK TROLL WITH SWORD should work. LOOK UNDER THE BED should work. Meaning, a parser should at least understand an actor, a verb, a direct object, and a preposition and an indirect object.

Likewise PICK UP THE CHALICE might give you a prompt like DO YOU MEAN THE SILVER CHALICE OR THE GOLD CHALICE?.

But how often do people really need PICK UP ALL THE CHALICES EXCEPT THE SILVER ONE OR THE GOLD ONE to work properly? I mean, GET ALL and DROP ALL are handy. I guess that DROP EVERYTHING BUT THE LAMP is useful too, but it seems like a slipperly slope.

I guess my question is, how much of a typical parser codebase is dealing with weird corner cases and can “we” live without them?

7 Likes
Booktasy:
2

That’s the approach i took in designing my parser for Strand. Basically, the assumption was that, if people are going to use a game parser, it doesn’t really need to be super-duper, only good enough. Since many people will switch it off and use choices instead.

I actually had a much more powerful parser that i wrote a while back, but i didn’t use it. Instead opted for one that was simple to implement and flexible to add new features if I wanted them.

I agree with you on the basic coverage. verb + nouns + prep + indirect object is mostly sufficient. I treat adjectives different from parsers like Inform. But otherwise there’s a lot of similarity.

A few wibbles are usually needed, such as “pick up X” and “pick X up” and “give X the Y”. Also some pronouns.

I didn’t bother with “all except” this time, as it’s hardly used.

I tend to implement possessives, which are not normally implemented. So if you “give coin to beggar”, you can say “steal beggar’s coin”. etc. Also “cat’s fur” is “fur of cat” etc.

To answer your question of edge cases. My current parser has a number of “gaps”. These are bits i designed but didn’t implement. The idea would be to implement them if i suddenly find them needed. My guess is that they won’t be.

8 Likes
3

A parser needs to be only as good as the game requires and manages to make clear to the player. I mean, ‘ATTACK TROLL WITH SWORD’ doesn’t need to work if the game relies exclusively on verb-noun phrases and manages to make sure the player knows this. The problem with something like a Scott Adams game is usually not that the parser is too primitive, but that it is too particular about what gets accepted, and that the messages you get in case of failure are not responsive enough. ‘ATTACK TROLL WITH SWORD’ in a game that accepts only verb-noun phrases should not generate ‘I don’t understand’ but ‘I only understood you as far as attacking the troll’ – or some such.

That said, I myself like it when parsers allow abbreviations and pronouns. I use a lot of ‘it’ and ‘him’ and ‘her’. It saves typing. I can’t remember ever having used ‘except’ or ‘everything but’.

8 Likes
4

Ah… that’s a good thing to add to the list… pronouns. And relatively easy to implement (lots of setIt / setHim / setHer sort of calls throughout the parser code).

Of course that raises a question for the ages… what is the value of “it” after ATTACK TROLL WITH SWORD?

(Ignoring whether trolls have a gender or not, my guess is that it should default to the direct object, not the indirect object)

1 Like
5

I’m fairly certain that Inform, for instance, would set ‘it’ to the troll, yes (if the troll was neuter). That’s what I would expect. BUT you want the author to be able to set this by hand too!

> ATTACK TROLL WITH SWORD

You brandish the runed sword, and the troll quickly flees. In her haste, she drops the key you were after.

> TAKE IT

You pocket the key. Now nothing stands between you and poor old Granny Jones’s meagre life savings!

7 Likes
6

The first version of Zork (mainframe one) only understood verb, direct noun and indirect noun. It simply ignored articles and prepositions. KILL THE TROLL WITH THE SWORD worked just ad well as KILL TROLL SWORD. I’m not even sure the order of the nouns mattered, so KILL SWORD TROLL might have worked too.

2 Likes
7

In my case, “it” always tracks the (first) direct object. I also have “that” which tracks the (first) indirect object.

3 Likes
8

Yeah, it’s important to separate out three considerations:

  • How good is the parser interface for a given game; where are the pain points, how well does it handle nonstandard input, how well does it handle specific nonstandard commands the game requires
  • What the possibility space is that the parser enables. More sophisticated parsers allow for some designs that aren’t possible with simpler ones; eg, PUT THE STATUE’S HEAD ON THE STATUE’S BODY WITH THE FORKLIFT or ASK THE GUARD POLITELY TO BE LET IN. This is important if you want to mess around with stuff that’s nonstandard in the world of ‘medium-sized dry goods’!
  • How much does the system allow authors to adjust the parser’s default behavior in specific cases in order to more likely do what you mean. Setting pronoun objects to custom values after certain actions is a common case, as is things like Inform’s Does the player mean… rules.

I do generally think that basic pronoun support is a baseline QoL feature for a parser interface; if EXAMINE THE LEAFLET then TAKE IT doesn’t work, I do view that as a problem.

6 Likes
9

I can’t think of many, with the exception of going up the chimney in Zork I, where “DROP ALL BUT LAMP” is handy.

6 Likes
10

I think allowing simplified command ms and precise commands is more important than complex ones.

So, for instance, repeating commands by hitting the up arrow or G is good; abbreviations like X or I; using IT like was said before and also understanding adjectives as nouns (so if you have a big plate and a small plate you can just type PUT SMALL ON BIG).

For precision, the main thing that is helpful is having two objects available per command (so you can say unlock red door with iron key). Three objects is rare but can be useful if tying on me object to another using a third.

4 Likes
11

Personally, I would say there are two main criteria a new parser needs to meet.

One, it needs to support the world model of the game. If you have a world model that involves objects being in different places within a room, for example, you need to support PUT X IN/ON Y; if the world model involves multiple similar objects, like a red button and a blue button, you need to support disambiguation. On the other hand, unless your world model cares about doing things “quickly” vs “carefully”, you don’t need to support adverbs.

Two, it needs to support conveniences players use. Back in the olden days, this was OOPS. Nowadays, it’s X and G and THEN, and typos not using a turn, and responsive error messages that explain what’s gone wrong when a command doesn’t work. I don’t think anyone has ever really used EXCEPT X OR Y; it was just implemented to show off a clever idea for the parser implementation.

8 Likes
12

You may be amused to learn that the main purpose of my parser is to support the author and not specifically the player.

One purpose of a parser is as part of authoring. Now, i don’t think other systems work this way, but what i do is implement verbs and classes of objects, in terms of other commands sent to the parser.

So all operations on my world are really a pyramid of parser commands on top of two primitives “put” and “set”. And therefore the many canonical IF types such as; containers, doors, portables, garments etc are not primitives, but actually implemented within the story itself.

Let’s take an example. We want a base type called GARMENT. Things in upper case are part of the syntax.

I’ll add comments starting with “//” on a line.
Anything starting with “>” is sent to the parser and executed.

GARMENT@ GETTABLE     // define GARMENT to be a subtype of GETTABLE
* take off it         // type of phrase
> remove it           // directed to "remove".
* remove it           // handler for remove.
REMOVEGARMENT         // name of handler
* put on it           // similar logic for wear...
> wear it
* wear it
WEARGARMENT

WEARGARMENT > put it on me           // WEARGARMENT runs command "put it on me"
* ok                                 // did it work?
You put on IT.                       // ok, generate output
*                                    // catch all
You can't wear that.                 // output for didn't work

                                     // define handler for remove 
REMOVEGARMENT > is it on me          // run parser query "is it on me" ?
* yes                                   
REMOVEGARMENT2                       // run second part of logic
*
You are not wearing IT.              // otherwise not wearing it.

                                     // part2 because removing a garment
                                     // results in it being carried
REMOVEGARMENT2 > put it in me
* ok
You take off IT.
*
You can't remove that.
2 Likes
13

(The only parser engine I’m familiar with in detail is Inform 7’s, so I’ll be referring to what features it, in particular, does and doesn’t have.)

Some things I think many people don’t know about and few people would miss if they were gone:

  • oops
  • you can stack qualifications, e.g., take all but containers except the box
  • giving multiple commands on one line with . or then or ,

(There would be at least some pushback on that last on the grounds that there have sometimes been puzzles reliant on multiple commands.)

A thing we need and don’t have that’s a glaring omission and obvious pain point in the modern world is support for freely customizable pronouns.

Some other things we don’t have that people sometimes wish for:

  • automatic (or at least much easier) support for a's or ' suffix to indicate possession or association
  • commands with two nouns without a requirement that at least one must be a thing
  • commands with three nouns (@Draconis’ Third Noun extension allows such, but the third noun must be a thing beyond the aforementioned requirement that of the first two nouns at least one must be a thing)
  • with a command verb expecting exactly two nouns, the option to use “and” to separate the nouns (currently, the compiler accepts Understand "foo [thing] and [thing]" as fooing without complaint but if the player tries it, the parsers balks with “You can’t use multiple objects with that verb.”)
  • better control over when inference does and doesn’t happen (okay, that an unqualified unlock command could result in an attempt to unlock Alice with Alice if Alice were the only other thing present seems to drive me, personally, more nuts than it does anyone else)
  • support for instructing an NPC in a different location to act on the things in the NPC’s location without nightmarish scope and reachability issues
  • for the main character’s knowledge to inform parsing (satisfying this one would require a bunch of infrastructure outside the parser, of course)

Occasionally, there’s some frustration that American English-style abbreviated titles like “Dr.” don’t Just Work… but there’s such a straightforward work-around that it’s not really a pain point.

There’s also interest sometimes in a parser that colors way outside the lines, like offering tab-completion… or that’s part of a hybrid interface in which, say, disambiguation pops up a menu from which the player selects a choice. But this remains very fuzzy… it’s easy to imagine advantages from hybridization in the abstract, but exactly what to implement and how for them to notably improve players’ experience in the real world to a degree that would be worth all the effort it would take? That’s harder.

10 Likes
14

Personally I use . and then a lot, so I’d miss those. But yes, the rest I’ve never really needed.

5 Likes
15

FWIW the parser I’m working on handles arbitrary pronouns. A game instance has a game.settings.person with out-of-the-box values for first, second, plural, male, female, nonbinary, or nonhuman, but is configurable.

Then for instance an author could write an error message like:

`{We} {don't} know how to do that. `

…and the print function hits a lookup table with person:

game.dictionary.pronouns[game.settings.person]["we"]

The reason why “we” is the lookup key is because the plural set is the only one with every value unique. {don’t} is in there because the lookup table also stores a handful of common subject-verb agreements, just for use with arbitrary author strings. (The dictionary has its own method for setting subject-verb agreement for dictionary verbs.)

Anyhow the author doesn’t need to know most of this and can just do:

game.settings.person = "nonbinary";

All of the parser’s default messaging uses these, so the author doesn’t have to change anything. To add a new pronoun set:

game.settings.person = "foo";
game.dictionary.pronouns.foo = { we: "IFoo", us: "MeFoo", ... }
4 Likes
16

I use oops all the time (because I typo all the time), but agree it’s a bit arcane these days. I do think menu-based disambiguation should be standard; I ran into a “which do you mean, the mirror or the mirror table” type disambiguation issue the other day, and it’s really maddening as a player. The mirror is right there! Obviously this is always solvable by a reasonably attentive author, but alas authors, myself included, aren’t always attentive :slight_smile:

6 Likes
17

Inventory limits and puzzles where you can only carry one object into room X are rare these days, but there are plenty of classic examples where “DROP ALL EXCEPT X”, “GET ALL KEYS BUT Y” and similar are convenient.

6 Likes
18

Having solved for oops, then, , and . , and all but in my own work, I can say that there’s no real reason not to implement them (unless it’s an ideological design choice), because they’re not super complicated relative to the grand scheme of things. oops replaces an unrecognized word in the prior input so you just need to keep a record… then and . and , split the input into multiple phrases to be parsed in sequence… all builds an array of available items and butsplices an item out of it.

Possessives is a thing that never occurred to me. I will definitely have to give some thought to that.

Tele-controlling NPCs is an interesting idea. I think that could work pretty easily. I have dictionary verbs set up with a variety of NounMustBe properties, and NounMustBe.present is just a property, so it would be easy enough to allow tell to accept non-present direct objects depending on current circumstances.

for the main character’s knowledge to inform parsing - that’s totally reasonable. I’ve got a NounMustBe.known verb property, and character knowledge is also used to help with some points of disambiguation.

titles like “Dr.” - it’s funny you should say. One of my test characters that’s been sitting around forever is a Mrs. and I never fully implemented that and had considered removing support for handling the . because it causes complications with handling . as a sentence boundary, which is probably why it works poorly in other systems in the first place. I’ll have to rethink that. Sentence boundary checks occur before object checks because you want to queue your multiple phrases before parsing them, so It’ll probably mean doing some kind of pre-lookup before treating it as a boundary.

option to use “and” to separate the nouns - like "attach pen and cap” ? I got that. “You attach the pen cap to the red pen.”

I know these weren’t directed at me but these are all great suggestions. I’ve been working on my project in isolation for nearly six years and it’s nice to get some fresh perspectives.

2 Likes
19

I sort of agree about there being little reason not to implement multiple commands… so long as you come up with a design and implementation such that it’s reasonably clear to a player how to express their intent as commands and there aren’t frustrating surprises to be had in how they’re interpreted.

In Inform,. and then are equivalent, but commas aren’t. I think the way it works is that commas can be used as command separators for any number of single-word commands, but once a command is given a noun, commas cease to be eligible as command separators… until a of use . or then, whereupon they’re eligible for command separation again.

But if a command begins with the name of an in-scope person (well… an object matching CREATURE_TOKEN, which isn’t quite the same thing) followed by a comma, it’s parsed as a command telling that person to do what’s specified after the comma. But if you say alice, go north then drop wrench it’s acted upon as if you sequentially entered alice, go north and then alice, drop wrench so if Alice successfully goes north, you end up being told “You seem to want to talk to someone, but I can’t see whom.”

You can use commas in your instructions (per the same conditions noted above), but once you’ve started giving an NPC instructions, there isn’t a way to indicate you’re not giving the npc instructions anymore and you want to give a command for the player character to act upon.

I like person’s name followed by a comma as a means of giving instructions to NPCs.

But if we’re to have multiple commands on one line, I’d like to see command queues on a per actor basis such that by default you can tell Alice to go north and drop the wrench without disappointing results. And for the player to also be able to indicate that in the meanwhile they’re going south and dropping the hammer.

What exactly does that look like? I don’t think there’s an answer one could claim is intuitive, but something that’s easy to learn and remember is hopefully in reach. Maybe we say that commas and . are never command separators, that then is a command separator only when giving multiple commands as instructions to an NPC, and that ; is a command separator that also terminates instructions to an NPC. So if you have willing NPC assistants and need things to be dropped in three different places at the same time, you could say:

alice, go north then drop wrench; south; drop hammer; bob, go west then drop pliers

Or maybe something else. I’m not claiming to have the answer and I’m not attached to the details I just suggested. But if multiple commands on one line is an aspiration, I’d really like the options to include giving an NPC multiple commands (without breaking down as soon as they’re out of sight) while being able to specify commands for the player character to act upon, and for the syntax to be reasonably straightforward for the player to learn and remember.

7 Likes
20

Oh, that’s an interesting point. NPC behaviors is one of the few remaining big ticket items I still have to tackle. I have some bare bones stuff for them at the moment, you can ask, tell, show, and give simple instructions, and though I do support “Alice, go north”, I see that I’m not handling multiple NPC commands in one statement. At the moment, the second command is interpreted minus “Alice, “ and just gets queued as an ordinary player command. So that’s a good thing for me to think about.

3 Likes