Disambiguation in Conversation

Authoring Dialog
1

There is a strange tweak in the library of Dialog (or maybe it’s the intention of making the game more user-friendly) but however, if the player types an incomplete input which would lead to a [topic] grammar then the game prints out every topic you have implemented in the game. Okay, it might be rare that players type the input below in this form because it doesn’t make any sense in terms of grammar but it happened that one of my testers tried it so it’s not too unlikely I guess.

e.g.

ask man about
Did you want to ask the man about the weather, the sky, the rain, the sun, the neighbours, the murderer, the police, the shotgun, the jacket, the jewel, the statue, or the grue?

This might be a good idea for players who don’t have a clue what to ask, but my game is about getting knowledge of names and locations so it’s quite counterproductive.

I just wanted to ask if someone here might have had the same problem and might have already found a solution for it, because it means digging deep into the library’s core functions like “sieve action candidates…” etc.

2

One option would be to make a topic conditional:

#weather
(name *) weather
(topic *) (weather is active)

or

(topic *) (#umbrella is #heldby #man)

this could get unwieldy as the number of topics increase.

Another option is to intercept the players input:

(parse action $words)
	{
	($words = [ask man about])
	(or)
	($words = [ask the man about])
	}
	The man has no idea what you're on about.

or

(parse action [ask man about]) (man text)
(parse action [ask the man about]) (man text)
(man text) The man has no idea what you're on about.
3

I have a couple of ideas, not extensively tested.

  1. Introduce some logic that makes topics available only on certain conditions.
#lab
(room *)
(name *) Lab
(look *) A testing lab.

#earth
(name *)
    earth
(proper topic *)

#wind
(name *)
    wind
(proper topic *)    

#fire
(name *)
    fire
(proper topic *)
    (#earth is discussed)

#fork
(item *)
(name *)
    fork
(* is #in #lab)

#reggie
(male *)
(animate *)
(name *) Reg
(proper *)
(dict *) Reggie
(descr *) A knowledgeable guy.
(appearance *) Reggie is standing around waiting to answer questions.
(* is #in #lab)

(perform [talk to * about #earth])
    "What do you know about earth, Reggie?"
    (par)
    "I know nothing about that, but I do know about fire!"
    (now)(#earth is discussed)

(perform [talk to * about #fire])
    "What do you know about fire, then, Reggie?"
    (par)
    "I know a great deal, but I am not going to tell you about it."

(perform [talk to * about #wind])
    "So, Reggie," you say, "wind?"
    (par)
    "Wind is blowing air!"    

(perform [talk to * about #fork])
    "What are your opinions on this fine fork?"
    (par)
    "I have no view on the matter!"    

(current player #nameless)

(#nameless is #in #lab)

And then:

Lab
A testing lab.

Reggie is standing around waiting to answer questions.

> ask reggie about
Did you want to ask Reg about earth or wind?

> wind
"So, Reggie," you say, "wind?"

"Wind is blowing air!"

> ask reggie about
Did you want to ask Reg about earth or wind?

> earth
"What do you know about earth, Reggie?"

"I know nothing about that, but I do know about fire!"

> ask reggie about
Did you want to ask Reg about earth, fire, or wind?

(Incidentally, I find it odd that the fork (an object that can be discussed) never makes it to the list, but that’s a different issue.)

  1. Define a new command to pick up unspecific asking.
(grammar [ask [animate] about] for [lawnmower $])

(refuse [lawnmower $Someone])
    You need to be more specific about what you want to ask (The $Someone) about.

(unlikely [ask $ about $])

Lab
A testing lab.

Reggie is standing around waiting to answer questions.

> ask reggie about
You need to be more specific about what you want to ask Reg about.

> ask reggie about earth
"What do you know about earth, Reggie?"

"I know nothing about that, but I do know about fire!"

You will need to play around more with both ideas. The first has some side effects which may or may not be desirable (e.g., when a topic is not available it produces “no reply”). The second may have side-effects that I haven’t anticipated – and I think you would also need to add unlikely rules to deal with synonyms for ask about, such as talk to about.

ETA: The post immediately above this was added while I was writing this and does the same thing as my first idea, but better.

1 Like
4

Your both proposals are suitable and I thought about that too. It might be a good starting point making topics about locations only “valid” when they are “visited” but I think it’s rather a matter of the library’s design. The game does respond to incomplete input in

take
I only understood you so far as wanting to take something.

So the appropriate answer with topics should be

ask man about
I only understood you so far as wanting to talk to the man about something.

So I think it would be worth digging into the depths of the system.
But thanks for your proposals I now have a quick solution if I don’t come up with something more complicated.

5

I’ve found it.
In the line 5529 of stdlib.dg you must add

(nonempty $Filtered)

This checks for a nonempty list of topic words in the

(understand $Words as topic $Obj) trait which otherwise will treat every input (also a blank input) as a valid topic matching against all topics known.

4 Likes