NPC Thoughts for comment
David Whitten
I would post here too.
I've been thinking about a hierarchy of behaviour for NPC's
(Non-Player-Characters)
Input Methods NPC's can have:
1) Telling them something
Example: say "hello" to fred
2) Prodding them
Example: pull on fred's tie
3) Sensing
Example: they noticed you saying something to someone else,
they noticed you picking up a rock.
One kind of NPC behaviour would be Reaction
ie: they heard you say something, the NPC looks up what you said in
an internal table and says whatever the table says to say.
a more general form of this would be to have 'fill in the blank' forms
that the NPC looks up in an internal table and then has the list of
blanks that you filled in and can use those to fill in the blanks in
the sentence it found in its table. Eliza does this.
eg: I hate my ----. => Why do you hate your --- ?
an alternate way of reacting would be to look up in a table to find
a program or list of things to DO when something is said. This
is similar to a command language for a computer
and of course this can be generalized to having 'fill in the blank' forms
as well.
The NPC behaviour of SCHEDULING is different.
In this, there is a list of actions or things to say, which are
listed in a queue for the NPC. At a certain time, the NPC needs
to do this, then at the next time, it needs to do this next thing, etc.
Notice this simply a lot of timers that go off at various times,
and have actions associated with them.
The next most general case would be to have the actions be conditional
in how or what they do.
The next case might be to allow the entire list of actions to be changed.
Each list of actions is still statically defined, but the 'active' list
for an NPC can be changed.
The next case might be to allow the contents of a list of actions to be
dynamically changed. This allows new tasks to be added, and old ones to
be deleted.
And of course, what actions you allow to be scheduled will affect how
smart the NPC appears to be.
Another NPC behaviour is to have a GOALS list, and the ability to PLAN.
This would require knowledge of what the NPC likes and dislikes.
It will also require a database of how-to methods linking goals to actions
so that it can look at goals and create a schedule of actions to attain
them.
I guess this is pretty old AI.
The simplest case would be that the goals tell how fulfill them.
the next simplest case would be that the goals list subgoals that when
fulfilled, will fulfill the main goal.
A more complex case would have lists of alternates so that the goal
may be fulfilled if one of the several alternate lists of subgoals
are fulfilled
This would require a DECISION ability to choose between the lists,
or some list of conditions qualifying when each alternate is preferable.
Also you need to have some component of your NPC that
could take these lists of actions and schedule them so they actually
would be done.
The Decision ability would probably be involved in interaction with the
scheduler too.
Well, I'm sure there are more aspects to this, I've typed a while,
now maybe someone else can do so.
David (whi...@netcom.com) (214) 437-5255
Felix Lee
non-directed actions. NPC actions tend to be:
- direct response to directed actions like "fred, hello" or "kill
fred" or "give egg to fred".
- internally-generated action, like doing cartwheels or randomly
wandering around.
- action based on static state, like picking things up from the ground.
What's missing is reaction to dynamic acts:
>say hello
Sam ignores you. Chris says, "Hi." Fido wags his tail.
>x bed
It's an ordinary bed.
>search bed
You don't find anything.
>look under bed
There's nothing there. Attracted by your interest in the bed, Fido
noses through the covers.
>get in bed
Okay. Sam says, "You're wasting your time," and leaves the room.
Fido tries to climb in with you, but Chris stops him.
>give ball to fido
Fido happily chews on the ball. Chris says, "You shouldn't encourage
him."
>jump
You bounce on the bed. Chris looks unhappy but doesn't say anything.
Fido barks excitedly.
>show cookie to Chris
Chris asks, "What about it?" Fido evades Chris, jumps on the bed, and
tries to take the cookie. Chris says, "Forget it," and leaves the
room.
>sleep
You close your eyes, but Fido's antics keep you from falling asleep.
Probably not quite implementable, but NPCs could become more reactive
in simple ways. For every action, generate the message: [actor action
objects] that gets sent to every actor in range. This is rather like
the structure of MUDs.
If NPCs will react to other NPCs, then you have the problem of
cascading events. Type one command, and get back seven pages of NPCs
just reacting to each other's actions. This is actually a scheduling
problem, and can probably be handled by attaching reactions to short
fuses. A better way might be to change the way time is modelled, but
that's another topic.
--
Felix Lee
>one aspect of NPCs that I haven't seen explored much is reacting to
>non-directed actions.
found one example. Unnkulia One-Half, the gambler reacts to a few of
your actions, like "sweep floor". Offhand, I'd guess it's implemented
as a room attribute, rather than an NPC attribute, but I don't know
much about TADS.
umm, is there a technical term for "a routine that's attached to a
particular object or location that can override the default behavior
for an action"? trap routine? intervention routine?
--
S.P.Harvey
: umm, is there a technical term for "a routine that's attached to a
: particular object or location that can override the default behavior
: for an action"? trap routine? intervention routine?
: --
In Inform, the routines are referred to as "before" and "after" routines;
routines which run 'before' or 'after' the parser has considered their
appropriateness. For example, I have a live electrical wire lying on the
floor. If I didn't code a "before" routine, the parser would allow the
player to pick up the live wire. Not what I had in mind. Instead, I
trap the "Take" action with a "before" routine that says something like
"as you stretch out a tentative hand, the air around your fingers
crackles with live electricity." and disallows the taking of the wire.
Does that answer your question? I at least hope I didn't create more
questions.
Can't speak for any other languages, though. I assume there's something
similar.
Scott
--
----------------------| S.P. Harvey |--------------------------
"Christianity taught that humanity is worthless and vile but that if we
agree to hate ourselves, God will forgive us." - Garrison Keillor
----------------------| sha...@interaccess.com |--------------------------
Felix Lee
>In Inform, the routines are referred to as "before" and "after" routines;
>routines which run 'before' or 'after' the parser has considered their
>appropriateness.
right track, but not quite what I had in mind.
I'm thinking more of something like this:
The routine for a character to transfer an object from one place to
another calls the routine
can-move? ACTOR SOURCE OBJECT DESTINATION
which verifies that all the things involved are in the same scope.
If you want to make something immovable or partly movable, you can
define overriding instances, like
define can-move? {A S immovable D} {
return "[The $immovable] can't be moved."
}
define can-move? {amoeba S X D} {
return "[The $amoeba] tries to move [the $X] but fails."
}
define can-move? {A S dog container} {
if [has $container water] {
return "[The $dog] refuses to take a bath."
} else {
punt
}
}
and when a particular "can-move?" expression is evaluated, the most
specific instance matching the arguments is used.
"can-move?" is kind of like a method, but it's not attached to any
particular object or class.
I think TADS has something similar, but you have to use a series of
methods, and I find this structure confusing. Inform is confusing in
a different way. Or maybe I'm just not used to it.
I thought I'd play with this structure, since I'm implementing a
prototype game system from scratch anyway. (using Tcl/Tk, so I can
play with user-interface ideas.)
--
Felix Lee
>All these run in at the same time (in a set order) and therefore the
>statements you suggest can be achieved in a more object orientated
>fashion (with much less code).
That was just one example. What I'm doing is slightly more general
than that. It's a way of overriding any relationship without
explicitly naming a series of methods for every object involved.
The flaw of object-oriented programming is the assumption that there's
a primary object. It's a useful assumption, but the model doesn't
always fit. "3 < 4" is true; is this truth a property of "3", of "4",
or of "<"? What if you want to modify the "4" object so that "x < 4"
is always yellow? That's what I'm trying to do.
I guess it's mostly a notational convenience. Internally, it's going
to be implemented as a series of methods anyway, unless I figure out
something more efficient.
--
Mark Phillips
player give and object to someone who is not present (or come to that
pick up an absent object). BUT you can
1) Change the scope on the fly (ie. an object has a function called
which tells the parser if it is in scope at the moment).
2) Catch things like drop on an object and then test where it is being droped.
3) Catch the drop on the player doing the drop (ie. useing the "life"
property disallow the amobea droping/taking things).
All these run in at the same time (in a set order) and therefore the
statements you suggest can be achieved in a more object orientated
fashion (with much less code).
I suggest you get a copy of the inform manual (designers manual) and
read it - it has lots of good ideas in it even if you are not going to
use inform.
Good Luck
Mark Phillips
Felix Lee
>The difficulty I got stuck on was that often the
>interrelationships between the conditions for different
>versions of an action are such that it's critical to
>test the conditions in the right order. Whenever you
>add a new alternative, you have to consider where
>abouts in the sequence to insert it.
right. if I remember my Prolog, the rules are tried in the order that
they're defined, and this isn't the right thing to do if you want
modular adventure code.
but I think I can make it so that rules are naturally checked in the
right order, mainly by ensuring that more "specific" rules are checked
before more general rules. I'll have to see if it works out..
--
Greg Ewing
In article <FLEE.94Oc...@snobol.cse.psu.edu>, fl...@cse.psu.edu (Felix Lee) writes:
|>
|> The flaw of object-oriented programming is the assumption that there's
|> a primary object. It's a useful assumption, but the model doesn't
|> always fit. "3 < 4" is true; is this truth a property of "3", of "4",
|> or of "<"? What if you want to modify the "4" object so that "x < 4"
|> is always yellow? That's what I'm trying to do.
I've had similar thoughts. A while ago I thought about
using Prolog as a model for an IF language. In Prolog
the usual way of expressing things is very similar to
what you suggest.
The difficulty I got stuck on was that often the
interrelationships between the conditions for different
versions of an action are such that it's critical to
test the conditions in the right order. Whenever you
add a new alternative, you have to consider where
abouts in the sequence to insert it.
That means you really have to group all the alternatives
for a particular action together. That makes it
difficult to write modularised code, and in particular
to write reusable libraries that you can add to
without intimate knowledge of their internals.
It may be possible, but it seems to replace one set
of problems by another...
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of Japan Inc.|
gr...@cosc.canterbury.ac.nz +--------------------------------------+
Michael Van Biesbrouck
>Greg Ewing:
>>The difficulty I got stuck on was that often the
>>interrelationships between the conditions for different
>>versions of an action are such that it's critical to
>>test the conditions in the right order. Whenever you
>>add a new alternative, you have to consider where
>>abouts in the sequence to insert it.
>
>right. if I remember my Prolog, the rules are tried in the order that
>they're defined, and this isn't the right thing to do if you want
>modular adventure code.
(Parenthetically, this is not necessarily the case. It is typical of
most Prolog implementations, however. Prolog variants that do not have
this procedural extension tend to go by different names. Parlog will
test rules in parallel, completely bypassing any sort of order.)
>but I think I can make it so that rules are naturally checked in the
>right order, mainly by ensuring that more "specific" rules are checked
>before more general rules. I'll have to see if it works out..
I have previously considered this sort of problem, and my decision was
to modularize programs so that object definitions consist of properties
and rules that correspond to common verbs (also intended to be reused).
Verb definitions would mostly cover the different grammatical forms. In
the case of verbs that exist for one game only, object properties
associated with the verb are best placed with the verb.
Special cases for objects are placed according to where they take
effect. Data sources would be combined something like this:
include main-loop
include parser
include locations
(also contains the rule for lighting matches in gas filled rooms)
include verbs
include local-verbs
(defines new verbs, also pun-action special cases in ``Nord and
Bert'')
include usual-verbs
include objects
include local-objects
(with verb information)
include usual-objects
This sketch hierarchy assumes that verbs check properties of objects.
Reasonable coding allows an OO-like programming approach. (The stool is
of class Chair, so you can sit on it; the oil is liquid but not potable,
so drink has the response ``You cringe at the thought of drinking that.'',
etc.)
The ordering of rules shown above should allow special cases to be added
without modifying pre-packaged definitions.
--
"You're obviously on drugs, Michael Van Biesbrouck
but not the right ones." Oook! UW CSC Librarian
-- bwross about mlvanbie http://csclub.uwaterloo.ca/u/mlvanbie/