Disambiguation without unnecessary questions?

Authoring General Design Discussions
21

I’m now working on the no-such-thing object that Zarf mentioned. During testing it came out that I need this.

Here’s test output for the ‘drop cube’ command when you’re not holding any, but they are all on the floor. In that case the parser will ask which one you mean and next the interpreter will tell you you’re not holding the object.

[code]XVAN transcript for: test ambiguities
version: 1.0
Room

look
Room

There’s a red man with a mission here.
There’s a blue man with a mission here.
There’s a green man with a mission here.
There’s a red bowl here.
There’s a green bowl here.
There’s a blue bowl here.
There’s an orange bowl here.
There’s a red cube here.
There’s a green cube here.
There’s a blue cube here.
There’s an orange cube here.
There’s a purple cube here.

i
You are carrying:
Nothing, you are empty-handed.

drop cube
Which cube do you mean?
The red cube, the green cube, the blue cube, the orange cube or the purple cube?

red
One must hold something before it can be dropped…

transcript
Turning off transcript mode.[/code]

Of course it shouldn’t ask which cube, but should say something like you’re not holding a cube or similar message.

I think this is where the no-such-thing object can help out:

  • in step 1 when generating all possible action records, generate 1 extra with no-such-thing.
  • the no-such-thing record gets a default score of 1, the others get 0.
  • now with ‘drop cube’ when not holding any, after applying the disambiguation rules, the no-such-thing record will have won because nobody got their score updated. The rules will assign points when the object is being held.
  • next, the interpreter will get the no-such-thing record from the parser. It should check on this particular value and then print something like ‘you have no such thing to drop’.

I’m building it right now and I’m pretty sure this will work for user input with 1 noun, like get . But what if there are 2 nouns, like attach to and you need to be holding them both?

22

Why not have the “no such thing”-“no such thing” option start at 1 and then that would win because the other options don’t get updated?

Would this even work where, say, you have to be holding two things and you only are holding one? So if you have the red cube and you “attach cube to cube” then the only option that gets a score above 1 is “attach red cube to no such thing,” which would allow for a message like “You don’t have anything to attach that to.”

23

Getting it to work for 1 noun was rather easy. 2 nouns was a bit more complicated. Suppose you have noun1 and noun2 and noun2 has 2 hits where noun1 gets no-such-thing. At that point there’s no use asking disambiguation questions about noun2 because we know there will be an upcoming no-such-thing message from noun1.

On the other hand, if noun2 has 1 unique hit and noun1 has no-such-thing, we may want to include noun2 in the error message because the player mentioned it.

So what I did was the following, I have 1 no-such-thing action record with fields for actor, subject and specifier. All 3 fields are initialized with a no-such-thing keyword. When the no-such-thing record is the winner after running the disambiguation rules I check actor, subject and specifier and whenever one has 1 unique hit, I copy that value to the no-such-thing record. So the n-s-t record will have 1, 2 or 3 n-s-t objects when it wins. It does require some additional code in the verb, because it has to check 3 possible n-s-t values to print the most accurate complaint message.

Here’s an output ecample:

[code]> look
Room

There’s a red man with a mission here.
There’s a blue man with a mission here.
There’s a green man with a mission here.
There’s a red bowl here.
There’s a green bowl here.
There’s a blue bowl here.
There’s an orange bowl here.
There’s a red cube here.
There’s a green cube here.
There’s a blue cube here.
There’s an orange cube here.
There’s a purple cube here.

drop cube
You are holding no such thing that can be dropped.

red man, drop cube
The red man with a mission is holding no such thing that can be dropped.

man, drop red cube
No one is holding the red cube.

man, drop cube
No one is holding any such thing.

transcript
Turning off transcript mode.[/code]

And this is what the verb would look like. It checks for 2 no-such-thing values (actor and subject).

[code]VERB drop
“drop”
# code for drop
printcr(“What do you want to drop?”)
getsubject()

“%o_actor, drop %o_subject”
“drop %o_subject”
DISAMBIGUATION_RULES
if owns(o_actor, o_subject) then score(5) endif
END_RULES
# code for drop subject
# nst is no-such-thing object
if equal(o_actor, o_nst) then
print(“No one is holding “)
if equal(o_subject, o_nst) then
print(o_nst.d_any) # any such thing
else
print(”%the %o_subject”)
endif
printcr(“.”)
else
if equal(o_subject, o_nst) then
print(“%the %o_actor “)
print(o_actor.r_to_be)
print(” holding “)
print(o_nst.d_no) # no such thing
printcr(” that can be dropped.”)
else
if (owns(o_actor, o_subject)) then
clearflag(o_subject.f_bypass)
move(o_subject, owner(owner(o_subject)))
print(“%the %o_actor”)
if equal(o_actor, o_player) then
print(" drop “)
else
print(” drops “)
endif
printcr(”%the %o_subject.“)
else
print(”%the %o_actor “)
print(o_actor.r_to_be)
printcr(” not holding the %o_subject.")

DEFAULT
printcr(“I only understood you as far as willing to drop something.”)
ENDVERB[/code]

If we also want to handle input like , put in then there would be a third check on no-such-thing. The verb code grows because of the disambiguation checks, but all verbs are in a separate file that can be re-used for different stories.

24

I agree with this. I have always thought that the need for disambiguation in a game is a UI shortcoming that indicates a suboptimal design decision, and should be fixed in the way you describe.

Someone might say: “but if in the room that I am imagining there is a red box and a green box, which are otherwise identical, why wouldn’t I have them in the game? Why should I impose such limitations on my creation?” The answer is for the same reason that in a point-and-click adventure game, you wouldn’t generally place an important clickable object behind another so that it’s invisible from the player’s viewpoint. Or for the same reason that you don’t typically get movies whose three main characters are called John, John and John and interact with people that just refer to them as John (unless if this is done specifically for comedic reasons). Because it is pointless to confuse the player, or the viewer, unnecessarily.

Of course, there may be exceptions, you might really need the objects to be similar for expressive reasons - a version of “The Matrix” wouldn’t really click with a red pill and a blue syrup bottle. But even in those cases, I think giving priority to an author-specified object, or just choosing an arbitrary object, is a better solution than asking in the overwhelming majority of the cases. If I am seeing a red box and a blue box and my reaction is to type “open box”, probably I just want to open any of them because any will do, or I plan to open the other one later anyway. If I really wanted to open the red box, I would have typed “open the red box” from the get go.

In fact, I struggle to remember any situation where I found a disambiguation question actually helpful as a player. Normally I just find them due to some serious design problem (e.g. the descriptions mention only one box, but there are actually two, and you find about the second one from the disambiguation question) and I find them to be an annoyance.

25

No, I disagree.

You can put in a number of rules to trigger auto-selection – a bias against scenery, a bias towards carried objects (or non-carried objects for a TAKE command). But those cannot cover all situations. Adventure games are prone to have similar categories of objects; that’s not suboptimal, it’s design. We design games that support learning and inference from one situation to another. That means you frequently put in more than one key, more than one crystal sphere, more than one knife.

The usual case is where the player has lost track of which object is where, and doesn’t realize there’s more than one key (etc) in scope. In that case, auto-selection has a good chance of being wrong – the player didn’t intend to take any key, they meant the red one and got the blue one. Parser disambig diagnoses that situation and also gives the player a shortcut to get the right outcome.

If you want to vary your nouns to reduce how often this happens – great! Talk about the “red ball” and the “green sphere”, as McTavish suggested. But if the player considers “ball” and “sphere” to be synonyms (and they probably do), then you still have to implement disambiguation.

26

Yes–getting too fancy with this will lead to situations like:

which does no one any good.

27

I suppose this is a generalization of the programming-language attitude towards error reporting. You should absolutely design your language to help users avoid mistakes. But you still have to implement robust error reporting for when they make mistakes anyway!

28

The examples with the colored cubes are really far-fetched and I doubt they will ever make it in a game.

In a testgame I have this dial puzzle:

[code]Dial room
This is a room with exits leading west, southwest and northeast.
On the wall are three colored dials: red, green and blue. Below the dials are three buttons in matching colors. The buttons are engraved.There is also a black button here, with an engraving.

In the south wall is a door.[/code]
Upon further examination the player finds that each dial has a similar colored hand that points to a number 0 - 9 with number 8 highlighted. They will also find that the black button resets all hands to 0 and that pressing the red/green/blue buttons starts (but not stops) moving the hand on the dial with the same color. Each hand moves at a different speed. And finally, the door has an 8 painted on it.

It’s obvious that the 3 hands must be started at different moments so they will all point to the 8 at the same moment and the door will open. What makes it difficult is that each hand travels at different speed.

This puzzle can be challenging for the mathematically not so literate player, meaning they will do a lot of button pressing. Therefore, I want the command to be as short as possible, i.e. 'press ’ should do it.
What I want to avoid is:

> press green What do you mean? The green hand, the green dial or the green button?
It should go like:

> press green You press the green button and the green had starts moving 3 steps at a time.
I made a rule for the parser that says “if you get multiple hits with the ‘press/push’ verb then disregard things that are not a button”.
Instead of using disambiguation rules, I could for example give each button a different shape to avoid ambiguity but I think that will distract the player as they have to remember the shapes as well.

Hope this is a better example.

29

Or teach players to use the exact same language you did. This is not the approach most single-player games take, and it will get you frowned at in IFComp, but I’ve seen it work very effectively in a MUD context.

30

These discussions always remind me of SHRDLU: hci.stanford.edu/winograd/shrdlu/

Asking questions about and executing commands in a simulated world where things are distinguished by color. It seems to me all IF parsers should be at least this sophisticated nowadays.