Parser output preference question

So, this is a non-technical question about a technical feature, so I hope this is the right board to put this in.

Does anyone have an opinion about disambiguation in a text game parser regarding getting the exact thing vs being able to always disambiguate more easily?

For example, if there is a room with the person named “Red” and a “red apple” and a “red apple-orange” (unlikely, I know, but this is for example and debugging purposes) would you prefer that the parser pick the person “Red” if you enter “look red”, or would you like it to try to disambiguate all matches of “red”? The same question would apply if you typed “look red apple”… should it pick “red apple” or should it ask for disambiguation between “red apple” and “red apple-orange”.

Assume that there is a mechanism in place that will always ultimately let you pick exactly what you want in the end. Would you prefer to be able to type in “keywords” or “partial word matches” and always get a list of disambiguation choices up front, or would you prefer to have to type in the exact name of things? What do you think is better design?

In that particular example I would expect “red” to always refer to the person named Red because it’s a noun and for the other objects it’s an adjective.

In a more general case, if there’s for example a “red haired pirate” and a “red apple”, I’d expect commands that obviously apply to people (TALK TO RED, GREET RED) to automatically choose the person and commands that obviously apply to small edible objects (TAKE RED, EAT RED) choose the apple. In cases that could apply equally well to both (EXAMINE RED) it should trigger disambiguation.

Could you show an example? I can’t quite grasp what this means.

Well, let’s see… I know this room in the example below is a ridiculous room that should never happen in a real game, but I want to code in such a way as to account for all possibilities (the game I am making is very dynamic so I can’t predict exactly what collections of things might populate a room):

The Kitchen
You can see a red apple, a green apple, an orange apple, a yellow orange, an apple, an orange, a green apple, a red orange apple, a green apple-orange, a green red apple orange, Red, Mrs. Appleworth, Mr. Orange, Orange Mr. Apple, Blue Mr. Apple, Orange Mrs. Appleworth, Red Mrs. Appleworth, Mrs. Appleworth-Orange, Mr. Orange-Appleworth and Mr. Appleworth here.

In such an extreme example, do you still think that “look red” should automatically assume that you want to look at the person “Red” or comb through and find everything that matches the “keyword” red, as in:

>look red
What do you want to take: the 1) red apple, the 2) red orange apple, the 3) green red apple orange, 4) Red or 5) Red Mrs. Appleworth?

But, Red also has the property “male”, which none of the apples or Red Mrs. Appleworth do, so the way I currently have it coded:

>look red man
You see nothing special about Red.

Combining visible keywords in the printed name with a “category” via referencing a logical property associated with a thing furthers the auto-disambiguation potential.

I just still don’t know if it is more helpful or more annoying the way I have it right now.

If an object’s entire displayed name is “red”, then “x red” should always refer to it rather than going to disambiguation. Inform doesn’t support this, however.

Extending this policy to “Mr Red” is reasonable. I’m less enamored of relying on adjective/noun distinctions.

I agree with Juhana, but (unlike ZIL and others) Inform doesn’t by default distinguish between nouns and adjectives in parsing.

I’d be annoyed if I typed in the entire name of an object and still got a disambiguation prompt (like with Red and the red apple), so I’d recommend checking for that if you’re going to have objects in your game such that the name of one includes the full name of another.

@zarf regarding Inform not being able to distinguish: I am using Inform, but I don’t necessarily have to continue to do so. I think, for the time being, I will continue to, as I am continuing to make progress on “rewiring” Inform to my needs. I can get Inform to do this kind of disambiguation (or not). With enough programming, I think this is an engine-agnostic question, but yes, the examples I provided clearly do still carry enough Inform standard stuff to be recognizable as such… but I think Inform is besides the point for the question.

@everyone: so what I’m getting is that in general, typing exactly the name should return exactly the object, even if the object is only one word long and other objects may contain the full name of that object in their multi-word name… but that if it is possible to differentiate between a matched word being a noun or an adjective, that if the word is an adjective, allow disambiguation, and prefer noun associations of the word over adjectives?

So, if I have “a copy of A Clockwork Orange” and “an orange clock” in a room, and internally to the game the “orange” on “orange clock” is an adjective, typing “take orange” would result in automatically selecting the book, not the clock, because for the book, “Orange” is a part of the noun name. But if I have “a copy of A Clockwork Orange” and “an orange” in the room, typing “take orange” would always select the fruit, because it is the full name of the noun. Is this what everyone means?

I can’t answer for anyone else, but that sounds right to me.

In principle, or have you found it clunky in practice? (I don’t know about other non-Inform systems, but TADS 3 games treat a noun as a better match than an adjective.)

I haven’t written a game that used the adjective/noun system, but as an author it feels clunky to think that way. As a player (playing TADS games) it hasn’t ever thrilled me. (Although if a game is designed in such a system, using the system is the way you play.)

I guess I’ll give an example. A couple of days ago I wrote an object like this: (not an exact quote from my game)

The cigarette-lighter is a thing. The printed name is "cigarette lighter".
The description is "It's a ceramic oval the length of your little finger. When you squeeze it, a little flame shoots out of the end."
Understand "cigarette", "lighter", "ceramic", "oval" as the cigarette-lighter.
Understand "fire", "flame", "flaming", "burning" as the cigarette-lighter when the cigarette-lighter is alight.

Dividing up this word list into adjectives and nouns is not completely obvious. “Oval” is used as a noun in the description, but in another piece of text I could just as well have written “oval bit of ceramic”. Then maybe I have an object which is a “wooden oval”, except when it’s an “oval bit of wood”. What does the adjective/noun rule say now about “TAKE OVAL”?

Then there’s the “fire”, “flame”, “flaming”, “burning” set. Maybe the first two are nouns, but then maybe not; they’re kind of adjuncts to the lighter, not the lighter itself. If I was in a room with a bonfire, it would make more sense for “fire” to refer to that, and grammar doesn’t come into it.

The case that the adjective/noun rule is meant to handle is when you are also carrying a “cigarette”. Then you want “cigarette” by itself to not refer to the lighter. But in fact my game has no cigarettes! If it did, I would have described the lighter as a “Bippo” or “snap-lighter” or something to avoid that disambiguation rat-trap.

In I6 I could set up the object to respond to “cigarette” only when the word “lighter” is also used; otherwise it’s no match. However, this is not a great solution for this case. We want adjective-only references to work when they’re not ambiguous.

So, yeah, it’s messy. And to some extent it’s self-fulfilling; you build a game that’s playable in the system it’s built in. I think I like the idea of marking some words as more important – that is, the match is higher-quality if any of those words are used. Don’t tie it to “adjective”/“noun” categories, and make sure it’s per-object rather than per-word.