problems with disambiguation

15 views
Skip to first unread message

GV

unread,
Oct 4, 2001, 8:37:22 AM10/4/01
to
I'm working on a parser in C++ and I've stumbled upon a problem. I want the
parser to make 'intelligent presumtions'. When I type 'open door' and there
are two doors of which one is closed and the other is open the parser will
presume I'm referring to the closed door. The problem I'm having is when
both doors are open. Since 'open door' means 'open a door that is closed'
the parser finds no object matching 'open door' and responds 'You see no
such thing.'. How does Inform or TADS solve this?

Alexander Deubelbeiss

unread,
Oct 4, 2001, 9:18:47 AM10/4/01
to
I suspect you should first look for doors. Return "You see no such
thing" if there aren't any (or only hidden doors). If there are
doors and exactly one is closed, open it. If more than one door is
closed, ask for disambiguation. If all obvious doors are open, say
"You don't see a closed door here."

Neil Cerutti

unread,
Oct 4, 2001, 9:22:04 AM10/4/01
to
GV posted:

If there's no sensible object, either any non-sensible object
will do (pick a closed door at random. In an extreme case, typing
"UNLOCK DOOR" in Inform, when there is no other object in scope
but the player, causes: "(with the door) (first taking the door)
That's fixed in place."), or refuse with an error message (in
Inform, "TAKE ALL", when there is nothing to take, results in:
"There are none at all available.").

It's up to you, but *I* don't feel it's worth a lot of effort to
make nonsense commands cause sensible error messages. As long as
what happens as a result of a nonsense command is not misleading,
it's OK with me.

--
Neil Cerutti <cer...@trans-video.net>

Magnus Olsson

unread,
Oct 4, 2001, 12:57:19 PM10/4/01
to
In article <slrn9rooqt...@fiad06.norwich.edu>,

Neil Cerutti <cer...@trans-video.net> wrote:
>GV posted:
>>I'm working on a parser in C++ and I've stumbled upon a problem.
>>I want the parser to make 'intelligent presumtions'. When I type
>>'open door' and there are two doors of which one is closed and
>>the other is open the parser will presume I'm referring to the
>>closed door. The problem I'm having is when both doors are open.
>>Since 'open door' means 'open a door that is closed' the parser
>>finds no object matching 'open door' and responds 'You see no
>>such thing.'. How does Inform or TADS solve this?
>
>If there's no sensible object, either any non-sensible object
>will do (pick a closed door at random.

I assume you mean "open door"?

I think that in this case, what you should do is one of two things:

1) First look for open doors. If there are more than one open door,
ask for disambiguation among them ("which door do you mean, the blue
door or the red door?"). If there are no open doors, look for any
door, and if there are more than one, disambiguate among them.

2) Find all doors, and assign them priorities according to whether
they're open or not (or other properties for other verbs). Then
either one door has the highest priority (if there's only one
open door) and you choose that one, or you have to ask a question
about whihc of the top-priority doors the user meant.

The Inform parser uses both these methods in different cases.
The first method corresponds to when you have grammar rules
like

eat * held -> EatSub;
eat * noun -> EatSub;

which will first look only at held objects, and only if the first
rule fails will the parser continue with the second rule (which
will eat any noun matching the input).

>In an extreme case, typing
>"UNLOCK DOOR" in Inform, when there is no other object in scope
>but the player, causes: "(with the door) (first taking the door)
>That's fixed in place.")

That's a different thing, actually: here the player has left out
part of the command ("with key") and the parser is trying to make
a reasonable assumption. IMHO the Inform parser isn't always very
good at this...

>It's up to you, but *I* don't feel it's worth a lot of effort to
>make nonsense commands cause sensible error messages.

But surely "open door" is not a nonsense command if there are
doors present?

--
Magnus Olsson (m...@df.lth.se, m...@pobox.com)
------ http://www.pobox.com/~mol ------

Neil Cerutti

unread,
Oct 4, 2001, 1:05:01 PM10/4/01
to
Magnus Olsson posted:

You're right, nonsense is too strong. But it does create a
situation in which the parser and world-model cannot together
create a sensible response.

--
Neil Cerutti <cer...@trans-video.net>

Magnus Olsson

unread,
Oct 4, 2001, 1:21:36 PM10/4/01
to
In article <slrn9rp5sq...@fiad06.norwich.edu>,

Neil Cerutti <cer...@trans-video.net> wrote:
>Magnus Olsson posted:
>>In article <slrn9rooqt...@fiad06.norwich.edu>,
>>Neil Cerutti <cer...@trans-video.net> wrote:
>>>It's up to you, but *I* don't feel it's worth a lot of effort to
>>>make nonsense commands cause sensible error messages.
>>
>>But surely "open door" is not a nonsense command if there are
>>doors present?
>
>You're right, nonsense is too strong. But it does create a
>situation in which the parser and world-model cannot together
>create a sensible response.

Well, I think that in this particular case, the following transcript
would be quite sensible:

> open door
Which door do you mean, the big door or the small door?

> small
But it's already open!

And this is how Inform and TADS normally behave in this kind
of situation.

Of course, it would perhaps be more convenient to get the
response:

> open door
But there are no doors here that you can open!

But that opens up quite a lot of cans of worms if you start to
think about it.

Daniel Barkalow

unread,
Oct 4, 2001, 4:28:49 PM10/4/01
to

1) Find all objects that fit what the player said.
1a) If there is only one, choose it.
1b) If there are none, say so.
2) Rank the objects by likelihood of being right (action would be
sensible, e.g.)
2a) If there is a single object which is better than all others, choose
it.
3) Otherwise, require the player to further specify.

In your case, for "open" closed doors would rank higher than open
doors. So the parser would ask if there are multiple closed doors, or if
there are multiple open doors and no closed ones, since in the former
case, there would be a tie for the higher rank, and in the second, there
would be a tie for the lower rank.

Of course, getting all of the details of the ranking system to fit player
and author expectations, including allowing the author to override the
library when the library doesn't know about an important factor, requires
a lot of tuning.

-Iabervon
*This .sig unintentionally changed*

Ricardo Dague

unread,
Oct 4, 2001, 7:24:58 PM10/4/01
to
"GV" <gosta_va...@hotmail.com> wrote in message news:<6KYu7.5571$aM.5...@newsc.telia.net>...

I think Inform fills an array with all the objects matching the word
'door', and gives each object an integer rank. Then it pares away all
but the highest ranking objects.

-- Ricardo
trikiw at mailandnews dot com

As a child he dreamed of WINGLESS FLIGHT and liked to jump from roofs.
One jump was from too great a height and resulted in a SPINAL INJURY.

Mike Roberts

unread,
Oct 4, 2001, 8:41:31 PM10/4/01
to
Neil Cerutti <cer...@trans-video.net> wrote:
> Magnus Olsson posted:
> >Neil Cerutti <cer...@trans-video.net> wrote:
> >>It's up to you, but *I* don't feel it's worth a lot of effort to
> >>make nonsense commands cause sensible error messages.
> >
> >But surely "open door" is not a nonsense command if there are
> >doors present?
>
> You're right, nonsense is too strong. But it does create a
> situation in which the parser and world-model cannot together
> create a sensible response.

There is a sensible response, though: "All of the doors you see are already
open." As a practical matter, it's difficult to code this kind of response
in general ("All of the <plural of noun phrase> you see are already <in the
state the verb puts things in>"), so it would be reasonable either to ask
for clarification ("which door do you mean?"), or arbitrarily pick one and
try the command anyway ("(the wooden door) / It's already open").

I agree with your position in general that it's not very important for a
game to understand nonsensical input, but I would limit this to *actually*
nonsensical input. In other words, I think it's useful to distinguish a
command whose meaning can be understood but is nonetheless not possible to
execute - such as "open door" on an already open door - from one whose
meaning the parser cannot understand. In actual practice, it's quite common
for a player to type "open door" when all the doors present are already
open, for any number of reasons - the player might not have read the room's
description carefully enough, or the description might be vague on the
status of the doors, or the player might have just returned to the room
after being elsewhere for a while and doesn't correctly remember the status
of the doors.

--Mike

Magnus Olsson

unread,
Oct 5, 2001, 7:33:46 AM10/5/01
to
In article <Eo7v7.68$78.1...@inet16.us.oracle.com>,

Mike Roberts <mjr-S...@hotmail.com> wrote:
>There is a sensible response, though: "All of the doors you see are already
>open." As a practical matter, it's difficult to code this kind of response
>in general

And, as I wrote in another message, it opens up a whole sixpack of
cans of worms.

Suppose, for example, that the command in question is "unlock door"
rather than "open door". Is it sensible to reply "All of the doors
you can see are already unlocked"? Perhaps, but only if it's really
obvious by looking at a door if it can be unlocked or not - and
that's usually not the case. And what if there's a puzzle involved -
for example, you can only reach the lock of one door if you're
carrying the Magic Crystal of Foo (yes, I know, it's an awfully
hackeneyed puzzle)?

But this is difficult. In most cases, it does make sense to limit
disambiguation of, say, "open red" to objects that can actually be
opened. But what if part of a puzzle is for the player to realize
that, say, the red jewel *can* actually be opened? I'm thinking of
the following situation:

You are in a generic room. A red door leads to the west. You can
see a red box, a red jewel, a red bed, a red leaf and a red herring
here.

>open red

Now, what does the game respond?

1) Which red do you mean, the red door or the red box?
(listing only obviously openable objects)

2) Which red do you mean, the red door, the red box, or the red
jewel?
(Giving away the puzzle)

3) Which red do you mean, the red door, the red box, the red jewel,
the red bed, the red leaf, or the red herring?
(Listing all red objects)

>I agree with your position in general that it's not very important for a
>game to understand nonsensical input, but I would limit this to *actually*
>nonsensical input. In other words, I think it's useful to distinguish a
>command whose meaning can be understood but is nonetheless not possible to
>execute - such as "open door" on an already open door - from one whose
>meaning the parser cannot understand. In actual practice, it's quite common
>for a player to type "open door" when all the doors present are already
>open, for any number of reasons - the player might not have read the room's
>description carefully enough, or the description might be vague on the
>status of the doors, or the player might have just returned to the room
>after being elsewhere for a while and doesn't correctly remember the status
>of the doors.

What he said.

Mike Roberts

unread,
Oct 5, 2001, 3:32:24 PM10/5/01
to
Magnus Olsson <m...@df.lth.se> wrote:
> >There is a sensible response, though: "All of the doors you see are
already
> >open." As a practical matter, it's difficult to code this kind of
response
> >in general
>
> Suppose, for example, that the command in question is "unlock door"
> rather than "open door". Is it sensible to reply "All of the doors
> you can see are already unlocked"? Perhaps, but only if it's really
> obvious by looking at a door if it can be unlocked or not - and
> that's usually not the case. And what if there's a puzzle involved -
> for example, you can only reach the lock of one door if you're
> carrying the Magic Crystal of Foo?

This sort of thing is much on my mind lately, since I've been revisiting
this topic in depth in the course of the tads 3 library implementation. The
theoretical framework (if that's no too grandiose a term for it) that I've
developed in my own mind, and which I've tried to build into the new
library, is that disambiguation (and object defaulting, which is related)
hinges on what the player character perceives to be obvious. For the
purposes of choosing which door is meant in "unlock door," it doesn't matter
whether or not you can actually unlock a door; all that matters is whether
the player character ought to perceive that a door is unlockable.

So, if one door plainly has a locking mechanism and the other doesn't, we'd
assume the player meant the one with the lock. If one door plainly were
locked and the other unlocked, we'd assume the player meant the locked one.
But if the locking status isn't clear just looking at the doors, we couldn't
make any assumption and would have to ask for clarification.

PC knowledge could enter in other ways. For example, suppose the item being
disambiguated is the key in "unlock door with key" - there's one door here
but you're carrying five keys. The first time through, you might have to
try several keys to find the right one (ideally the PC would do this
automatically, but this is not disambiguation in the normal sense - there
could be a cost involved, such as time, that wouldn't be involved in normal
disambiguation - so you wouldn't want to do it while fleeing the Evil Ogre
of Foo). Once you've identified the key, though, the parser ought to pick
it out for you automatically henceforth. (Credit where it's due: this is
Sean T. Barrett's idea, not my own.)

> But this is difficult. In most cases, it does make sense to limit
> disambiguation of, say, "open red" to objects that can actually be
> opened. But what if part of a puzzle is for the player to realize
> that, say, the red jewel *can* actually be opened? I'm thinking of
> the following situation:
>
> You are in a generic room. A red door leads to the west. You can
> see a red box, a red jewel, a red bed, a red leaf and a red herring
> here.
>
> >open red
>
> Now, what does the game respond?
>
> 1) Which red do you mean, the red door or the red box?
> (listing only obviously openable objects)
>
> 2) Which red do you mean, the red door, the red box, or the red
> jewel?
> (Giving away the puzzle)
>
> 3) Which red do you mean, the red door, the red box, the red jewel,
> the red bed, the red leaf, or the red herring?
> (Listing all red objects)

Nice example. In my framework, (1) would be the right choice, assuming the
player character doesn't have reason to believe the red jewel is openable.
Now, if the PC had previously had a conversation with an NPC who told the PC
that the red jewel is actually the Magic Crystal of Foo and that opening it
would confer mystical powers upon its posessor, *then* the jewel ought to be
included in the list of choices, as the PC knows the thing is openable. Am
I on the right track here?

To put this in concrete implementation terms, the tads 3 library expands
upon tads 2's binary logical/illogical verification with gradations of
logicalness and illogicalness. For this example, the red door and red box
would be fully logical, because it should be obvious to the PC that they're
openable items; the bed, leaf, and herring would be illogical because
they're obviously not openable things. The jewel would be a "logical but
highly unlikely" choice - if the player were to open it explicitly, the
action is allowed, hence it is logical; but given any ambiguity, the red
jewel would be an unlikely choice. Once the PC had heard about the Magic
Crystal business, the unlikeliness would be removed and it would be a choice
equally as likely as the box and door.

--Mike
mjr underscore at hotmail dot com

Sean T Barrett

unread,
Oct 7, 2001, 12:11:25 AM10/7/01
to
Mike Roberts <mjr-S...@hotmail.com> wrote:
>PC knowledge could enter in other ways. For example, suppose the item being
>disambiguated is the key in "unlock door with key" - there's one door here
>but you're carrying five keys. The first time through, you might have to
>try several keys to find the right one (ideally the PC would do this
>automatically, but this is not disambiguation in the normal sense - there
>could be a cost involved, such as time, that wouldn't be involved in normal
>disambiguation - so you wouldn't want to do it while fleeing the Evil Ogre
>of Foo). Once you've identified the key, though, the parser ought to pick
>it out for you automatically henceforth. (Credit where it's due: this is
>Sean T. Barrett's idea, not my own.)

Generally when I talk about this topic I focus on the idea
that the parser should model *player* knowledge, not player-*character*
knowledge. In practice, it depends on the game; you might WANT
the player to get pulled along by the player-character's inherent
knowledge of which key is correct without the player knowing.

But in general I agree with dfan; the parser lies in between
the *player* and the game, not the player character and the game,
and the model should focus on player knowledge, probably intersected
with player-character knowledge (or scoping, but 'knowledge' is
more accurate--if you turn out the light, you still know the light
switch is there, you just can't see it anymore).

SeanB

Mike Roberts

unread,
Oct 7, 2001, 2:30:27 PM10/7/01
to

"Sean T Barrett" <buz...@world.std.com> wrote in message
news:GKtIB...@world.std.com...
>> [on my comments that disambiguation should be tied to
>> the player character's knowledge]
> Generally when I talk about this topic [disambiguation] I focus

> on the idea that the parser should model *player* knowledge,
> not player-*character* knowledge.

I agree - I didn't quite manage to articulate my thoughts correctly. The
player's knowledge is what's important because the parser is the user
interface, and its design should thus prioritize user interface
transparency. The goal is to figure out what the player meant with the
command, which doesn't necessarily have anything to do with the PC's frame
of mind.

I was making the mistake of conflating the PC's knowledge with the player's,
because when I think about this from an implementation point of view, I
think in terms of state information that is stored more or less with the
object representing the PC: has a room been "seen" in the course of the
game, has an object been seen, has a key to unlock a given door been
successfully identified. Despite being attached in some way to the PC in
implementation terms, these types of information conceptually have nothing
to do with the PC - in particular, the game's author would never go through
the back story and set the "seen" attributes of objects the PC knows about
prior to the start of the game.

It makes me wonder if it might be worthwhile to introduce a "player" object,
formally separating state related to the player from that of the PC. I had
actually toyed with the idea of keeping separate "seen" flags per object per
actor at one point, on the notion that a game with a shifting player
character might care to distinguish who had seen what, but nixed the idea
because (a) it would be too cumbersome and expensive and (b) I didn't think
it was the right information to keep in the first place. Now I'm thinking
that (b) is exactly the case because the information really belongs in a
player object.

Magnus Olsson

unread,
Oct 11, 2001, 1:17:27 PM10/11/01
to
In article <7b1w7.802$903.30...@newssvr13.news.prodigy.com>,

Mike Roberts <mjr-und...@hotmail.com> wrote:
>
>"Sean T Barrett" <buz...@world.std.com> wrote in message
>news:GKtIB...@world.std.com...
>>> [on my comments that disambiguation should be tied to
>>> the player character's knowledge]
>> Generally when I talk about this topic [disambiguation] I focus
>> on the idea that the parser should model *player* knowledge,
>> not player-*character* knowledge.
>
>I agree - I didn't quite manage to articulate my thoughts correctly. The
>player's knowledge is what's important because the parser is the user
>interface, and its design should thus prioritize user interface
>transparency. The goal is to figure out what the player meant with the
>command, which doesn't necessarily have anything to do with the PC's frame
>of mind.

I agree. Disambiguation is on the player's side of the user interface,
not in the game world - which, I think, is why the original poster's
suggestion that the game print some text about the PC not being able
to choose between the doors seems disturbing.

>It makes me wonder if it might be worthwhile to introduce a "player" object,
>formally separating state related to the player from that of the PC.

The problem with this - and with the game trying to keep track of
the player's knowledge in general - is of course that if the player
restarts the game, game state is lost, but the player's memory isn't
erased.

Of course, one could consider ideas like saving the "player state"
to a file, but then what if the player switches computers?

The problem is of course unsolvable, but one should aim to make
things as easy as possible for the player.

Another case where this problem arises is the following: suppose that
you have a puzzle where the solution is known to belong to some small
set of possibilities (say, the player needs to know the name of a
demon, which he/she knows is one on a list in a book, as in "The
Dungeon of Dunjin").

To avoid the player's solving this puzzle by brute force (save, guess,
restore until success), the game keeps track of whether the player has
performed the action needed to find out the name. If he/she hasn't,
the demon refuses to respond to his name: "You're only guessing".

The problem here is that if the player has restarted the game, the
game doesn't know that he's already solved the puzzle. But I think
this case is acceptable to most players. I don't know how people would
react to similar behaviour when it comes to disambiguation.

Reply all
Reply to author
Forward
0 new messages