This is quite complicated and it will be hard to do if everything is automated. I think to help take the load off a bit it would be a good idea to introduce a conversation GUI to the game which will reduce the amount of predictability that you have to apply to the code. Instead the code will act as a series of rulesets that will only have to automate the NPC data but becuase the player is also putting in "more" data through the gui automatation will be easier to plan out.

One more time for the dumbies
ar+gu+ment n. A discussion in which reasons are put forward in support of and against a proposition, proposal, or case; debate.

I agree that a separate GUI will be required to cover the player input and translating the engine functions into text that looks like speech.

But the details of the behavior of the conversation would stay in the engine. The GUI will be dumb, serving only to translate. Because the engine will have to have a short term (1 node or so) memory, I''m thinking that the engine will need to tell the GUI when something was part of the previous statement. The GUI would have the responsibility of knowing when to provide pronouns.

But back to the mushy bits. How much autonomy to give the NPCs? Is trying to include some mood states getting too large? Should we design to have conversations that come up and then disappear without any long term effect on the NPC behavior (other than a change to their knowledge)?

This would mean that players could get consistent reactions from the NPCs, but it might be too consistent, as in ''I don''t like where this conversation is heading, so I leave and try again''

What else am I missing so far?

bishop_pass:
I just ran across Lambek Calculus. This is what you were referring to in the crunchy posts?

Replace the NPCs with some kind of SOMAD?

In reply to the mood thing you mention a couple of posts ago jswing. There''s an interesting way this was used in an Amiga game called nuclear war. You had 4 opponents and everyone was nuking each other. But each character/opponent had a liking to disliking of you depending on what you were doing. It wasn''t a complicated mood system, it was all based of simple diplomacy skills. You could even interact with their mood in more ways than one. The first way was as i said above (to nuke or not to nuke them) the other way was through a GUI icon. In the GUI it showed the faces of you opponent, stamped atop and left of your opponent faces was a little yellow smiley face. This little yellow smiley face had 5 settings you could change at any time:
1. Grrrr, i''m going to kill you
2. I don''t like you very much
3. I don''t know you
4. We''re pals
5. Kissy kissy kissy.

By changing these little yellow faces in the GUI your opponents "might" change how they felt about you depending also upon who you were nuking at the time. Do you catch what i''m saying? It used mood as an interactive tool-element. I havn''t seen it done since.

One more time for the dumbies
ar+gu+ment n. A discussion in which reasons are put forward in support of and against a proposition, proposal, or case; debate.

Here''s a very simple equation for using mood in a game

Your mood Z + NPC mood X = NPC mood Y
then
NPC mood y + Your question (or answer) = NPC reaction V

This probably should be tweaked. Oh yes, it should definity be tweaked But you never know.

You''d have to create each individual npc individually with an elaborate data structure for the moods for each npc but it could work.

One more time for the dumbies
ar+gu+ment n. A discussion in which reasons are put forward in support of and against a proposition, proposal, or case; debate.

quote: Original post by JSwing

bishop_pass:
I just ran across Lambek Calculus. This is what you were referring to in the crunchy posts?

Lambek Calculus? Never heard of it. I just did a search on it and didn't come up with a clear picture of what it is al about.

Now Predicate Calculus is a language capable of theoretically describing any type of knowledge, including existential knowledge. And any statement in Predicate Calculus can be converted to a set of disjunctions. Once converted, resolution theory can be used to determine if any new statement is in conflict with all existing statements in the knowledge base.

For example, we might have this existing knowledgebase:
-------------------------------------------------------
Terry ParentOf Bill

Chris ParentOf Bill

Chris FatherOf Bill

If (x FatherOf y) -> (x ParentOf y)

If (x FatherOf y) -> (x InstanceOf Male)

If (x MotherOf y) -> (x ParentOf y)

If (x MotherOf y) -> (x InstanceOf Female)

If (x InstanceOf Male) -> not (x InstanceOf Female)

If (x InstanceOf Female) -> not (x InstanceOf Male)

If (x ParentOf y) &
...(z ParentOf y) &
...(x InstanceOf Male) &
...not (x EqualTo y) ->
...(z MotherOf y)

Now if we were to attempt to assert this:
-----------------------------------------
(Terry InstanceOf Male)

the knowledgebase would automatically refute it and not put it into its knowledgebase. This is resolution theory at work. The problem is that as the knowledgebase gets large, the resolution process grows exponentially due to the way it searches.

Note that nowhere have we told it that Terry is the mother of Bill. Nor have we told it that Terry is female.



Edited by - bishop_pass on November 22, 2000 11:48:53 PM

Edited by - bishop_pass on November 22, 2000 11:49:30 PM

quote: Original post by bishop_pass

For example, we might have this existing knowledgebase:
-------------------------------------------------------
Terry ParentOf Bill

Chris ParentOf Bill

Chris FatherOf Bill

If (x FatherOf y) -> (x ParentOf y)

If (x FatherOf y) -> (x InstanceOf Male)

If (x MotherOf y) -> (x ParentOf y)

If (x MotherOf y) -> (x InstanceOf Female)

If (x InstanceOf Male) -> not (x InstanceOf Female)

If (x InstanceOf Female) -> not (x InstanceOf Male)

If (x ParentOf y) &
...(z ParentOf y) &
...(x InstanceOf Male) &
...not (x EqualTo y) ->
...(z MotherOf y)

Now if we were to attempt to assert this:
-----------------------------------------
(Terry InstanceOf Male)

What you describe is very similar to prolog, a language that is used widely in AI.

First you have a set of axioms:

mother(X,Y) :- parent(X,Y), female(X).
father(X,Y) :- parent(X,Y), male(X).
male(X) :- parent(X,Z), parent(Y,Z),female(Y).
female(X) :- parent(X,Z), parent(Y,Z),male(Y).

Then a set of known facts:

parent(terry, bill).
parent(chris,bill).
male(chris).

Then you can query the knowledgebase:

female(terry).

And it will say ''yes''. Why? It searches the KB for something that matches the query and finds the 4th axiom and binds X to the value ''terry''. To prove that it must prove all the subgoals:

1. that terry has a child. This comes from the first fact: Its bill.

2. that that child has another parent. This comes from the second fact: Its chris.

3. that that parent is male. This comes from the third fact.

Prolog is based on resolution theory. Imagine that. However, to make Prolog more efficient, it is not complete resolution. I can''t remember what aspect is missing in Prolog. I actually have never programmed in Prolog, but I have a book which discusses its foundation.

What I was looking at sounds similar, but rather than model logical understanding, the model only builds associations of words and phrases.

The good news is that this system can handle normal conversation very well, and the output sounds coherent. The bad news is that it doesn't understand the phrases that it's using, so the output may be vague or somewhat tangent to the original line of inquiry, and it's useless for deduction.

Since a word or phrase may be used in multiple contexts or have multiple meanings, the system can set up different personalities that tend to prefer one association over another.

At least, that's my laymen interpretation so far. Take a look:

http://www.forum2010.org:2010/


Such a system probably uses too much data to be that useful in a narrow application like a game. I envisioned something similar to what they describe but using a more limited set of data made from the backstory, information about each object, and phrases that added flavor.


Edited by - JSwing on November 24, 2000 2:02:20 AM