Right. Mentioning "Turing Test" will often ruffle the feathers of many
who hear you, who will then make it their sole ambition to prove that
your NPC doesn't even come close to the real Turing Test. So, best not
to even compare. Or, better, define a more appropriate test. This
is hard in the typical standalone PC, however, because you KNOW that
everyone you meet is an NPC. Little different on a MUD...
>For this reason, I think the appropriate way to deal with NPCs is
>to describe the NPC with a large enough set of characteristics to
>cause emergent behavior,
Exactly! You beat me to this one. I like the idea of having characters
that are changing internally as the game progresses, so that even if
you try to recreate an environment exactly, you can't duplicate the
state that the NPC was in at the time. Therefore, you could potentially
have a different result.
>Another feature of emergent behavior is that (presuming the personality
>engine interacts with the environment) it may do different things in
>different situations. Even a small set of characterstics may produce
>a fairly wide range of behavior if placed in a varied enough environment.
It's also to do different things in the *same* environment. Take the
The troll eyes you hungrily. He begins drooling on your leg.
>give toaster to troll
The troll snatches up the kitchen appliance and pops it into his mouth.
"Blech!" he growls, and spits it out.
>take toaster and give toaster to troll
The troll isn't falling for that twice.
(Simple, but the point is there.)
>(This is pure theory, folks. I hope this is true, but have no
>experience trying to implement such a critter..) Furthermore, even
>if the NPC is so simple that the player can determine the NPC's actions
>in any given circumstance, at least this might actually be interesting
>to the player -- perhaps there are problems to solve which involve
>manipulating an NPC in the appropriate way. This would be much
>more interesting than having a character who usually acts randomly
>following you around all the time.
I would never want to have a character acting randomly. At the very
least, instead of "move in a random direction", give the character some
sort of internal map that tells him if he's been somewhere before, and
not to repeat himself. Small price to pay to make the character look
better. Actually, I've got a maze algorithm that I'd love to implement
so that you could tell a character "Go to the library!" and it would
then invoke a script to find the library, from wherever this NPC
happened to be at the time.
>Finally, I want to point at that the operative term in NP_C_ is
>Character. Monsters, robots, etc that don't pretend to have
>intelligence don't need to act in an interesting manner. The
>repetitive stupidity of the monsters in Alone In The Dark is
>fine, probably even contributing to the atmosphere. The issue
>is that of expectation -- if the player sees a creature which
>looks like it's intelligent (e.g. Gandalf), it better act
>more intelligently than the frog hopping nearby.
This is a good reason why you don't often meet intelligent characters in
adventures. I outlined simple behavior for a few characters earlier
in the thread, like:
If it's food, eat it.
If it breaks, break it.
If it's shiny, steal it.
If it moves, shoot it. <-- typical arcade game NPC. :-)
And so on.
I guess what I'm trying to say is that this would be even _more_ fun
if Gandalf and the rest of the bunch could do more things _and_ do
them in a more intelligent way.
Perhaps my original question was poorly formulated. Suppose that an
NPC is extremely intelligent within the limits given by the situation.
For instance, it will be able to learn if a given object is edible or
not and it will always be able to find the way back to where it's
been before. These two actions, in spite of being quite intelligent
(as normal NPCs go) will hardly be enough to cause a staying interest
from the player. How about trying to impelement NPCs who are having
quests of their own (perhaps competing with the player) in addition
to the gnome that smashes everything in sight? A number of different
NPCs, one or two very complicated and a dozen or so rather simple,
ought to be able to create very interesting situations, but I don't
believe that simply limited intelligence is enough; a multitude of
personality is also needed in order to make an interesting game.
Hmm... hope I don't sound too confused. :-)
Steven Grady also says that designing an intelligent actor is "non-trivial",
and I agree. However, I would like to remind everyone that we really don't
know how playable and interesting a halfway good NPC actor would make a
game, because _there aren't any games that have them_! Correct me if I'm
wrong, but in all the IF I can think of, no-one's really tried to make
actors go much beyond Gandalf in The Hobbit, or the thief in Zork. I say
let's try to make some reasonable actors and then decide if the results are
worth the thousands of line of code 8).
Jason Noble |
National Centre for HIV Social Research | jno...@bunyip.bhs.mq.edu.au
Macquarie University, Sydney, Australia |
[Remember that the game of Life's behavior is based on the fact that each
cell alters the behavior of each other cell...]
>Learning is quite tricky to program. Would we make a list of all the things
>the troll has tried to eat, so we can remember? Or mark each item as to
>whether the troll has tried to eat it or not?
<shrug> Depends on preference to the programmer, I guess. I tend to think
in lisp, where funky, non-structured knowledge frames would be quite
(actor troll (knows (object toaster (has-attrib (not edible)))
(object rabbit (has-attrib (edible)))))
And so on. Knowledge that can be "attribute"-ified seems like it could
be easy to code. And, sure, how else would the troll know what's edible
and what's not unless he's eaten it? We could set up a knowledge frame
and know things like (living-things (have-attrib edible))
(rabbit (is-a living-things))
But that would come after getting the first part up and rolling.
>Okay. NPCs should all have a purpose in the game. Most of them should
>be natives to the area, too. This means they should know where all the
>locations are, where all the objects are (or, more accurately, where they
>last saw them), and should have some sort of point to being here. No
>real person just walks around randomly. Perhaps the ogre wanders the
>area looking for children to eat. Fine, so he should use some sort of
>search pattern, whatever it might be.
Just today, I started sketching out an adventurer who would wander around
the game, remembering rooms, and keeping a map in his head (we'll have to
assume, here, that he can keep a perfect recollection in there). When
he'd discover objects, he'd also internally log their location in a
knowledge base as well. Ideally, I'd want it so that if he stumbled
across a need for a particular object (like, say, another NPC that
demanded gold), and he had seen gold, he could retrace his steps, get
the gold, and come back. (Of course, if I were modelling the typical
adventurer, he'd just be picking up everything as he found it, after
he all'd it).
I suppose, now that I threw the obligatory "all rock" joke in there (for
those that have been following along!) we could implement something
like that for our NPC. When he stumbles across an object, he begins
trying to manipulate it. Each success or failure would be stored in
the knowledge frame...
(object rock (can throw) (can-not eat) (can take)...)
Of course, there are problems with this (like ruining an object by
eating it, or something). Wow, how about an NPC that knew about
save/restore game??? :) As long as I'm dreaming, I'd like a pony. :)
>Hmm. Not bad, actually. Of course, these "simple" actions require a whole
>bunch of smaller actions. Recognizing if it is food, trying to get the
>food, seeing if you're hungry or not, and finally trying to eat it.
Lesse...if it's food: no problem, just include an "attribute" with objects
that can include the value EDIBLE
...trying to get the food: don't waste time with it. Attempt to do
a GET x, and if it fails, leave it.
...seeing if you're hungry: the troll I've described would simply
always be hungry. Or, eat himself to death if you prefer. THere
are creatures that do that.
...trying to eat it: I like to have all computer characters have
access to the same functions as the player, so:
class PLAYER : class ACTOR ...
class NPC : class ACTOR...
you->eat(food); // is the same thing as
The NPC actor would perform the same internal maintenance.
No offense meant to TADS, but people earlier asked me why I wanted to
reinvent the wheel. Honestly, I don't know whether or not I can do the
things that I want to do with TADS. I do know, however, that I can do
them in C (C++, LisP, whatever..) Therefore, I'll put up with throwing
together a parser in C so that I can get on to doing some more interesting
stuff with NPCs.
Think as a player, not a designer. The player won't *know* whether or
not you've thrown in an extraneous character, and they'll spend their
times going nuts trying to figure out what they need to say to this
character to get the magic widget. People have been discussing the fact
that most puzzles are simply of the "all all" variety, and here's a
variation where the user can do that all day and still not get anywhere.
Maybe the user will learn that it ain't gonna work, and start paying
attention to what's going on. [Bringing in the idea of time, we can
allow for racing between characters...don't spend too much time on
one object, or another character might pick up somethng else and take
Or, succinctly: NPCs should all have a purpose in the game, even if that
purpose is simply to add variety to what the player encounters.
>Most of them should be natives to the area, too.
<shrug> Why? I think the idea of stumbling across another adventurer,
on the same quest that you are, is kind of neat. Or what about an NPC
that you run across in town, who's probably never been in the caves at
the base of the mountain?
>This means they should know where all the
>locations are, where all the objects are (or, more accurately, where they
>last saw them),
I'll agree that, if we're talking about townspeople, then sure, we can
give them a map to get going. Other than that, though, let them figure
it out right along with the player.
>and should have some sort of point to being here. No
>real person just walks around randomly.
Making a stable script for NPCs would be tough, but I don't think impossible.
The earlier example was given of a character who was told to open door,
go through door, and get sick [or something like that]. But, if he
opened the door, and then you closed it on him, the script went all flooey.
Maybe something more the equivalent of:
if (opened(door)) then go_through(door);
Seems like it would do a little bit better of a job checking to make sure
that the environment hasn't changed unacceptably.
>Perhaps the ogre wanders the
>area looking for children to eat. Fine, so he should use some sort of
>search pattern, whatever it might be.
Ogre? search pattern? Ogre goes where ogre wants to go.
>Just today, I started sketching out an adventurer who would wander around
>the game, remembering rooms, and keeping a map in his head (we'll have to
>assume, here, that he can keep a perfect recollection in there). When
>he'd discover objects, he'd also internally log their location in a
>knowledge base as well. Ideally, I'd want it so that if he stumbled
>across a need for a particular object (like, say, another NPC that
>demanded gold), and he had seen gold, he could retrace his steps, get
>the gold, and come back. (Of course, if I were modelling the typical
>adventurer, he'd just be picking up everything as he found it, after
>he all'd it).
Actually, I think NPCs that learn about the world are reasonably common
in the MUD world (which in the more interesting MUD worlds provides a
very good opportunity for NPC design and testing -- the NPC, by playing
over the same interface as the PCs, is a nicely separate program, and
it has to deal with the same level of information that players do.
People with ideas about NPCs might want to go that route, especially as
they can avoid implementing the rest of the environment). In many MUDs
in particular, it's important to have something that learns the
environment (and can provide the fastest path between locations)
because they tend to change, with even low-level players being
able to add new rooms.
There are "robot" people, dogs, etc that wander around the MUD,
learning places, objects, locations of people, etc, and who can respond
to questions about all the information they have gathered. (The last
time I looked at these was about 3 years ago. The first one I saw was
implemented by Miahcael Mauldin, of Rogomatic fame. Someone who knows
about the current state of the art might want to comment.)
Unfortunately, they tend to function mainly as active information
repositories (sometimes providing money, or random actions as well). I
never saw one which had a more interesting goal than "keep traveling
and learning about new locations". Again, they weren't Characters --
they were robots.
>I suppose, now that I threw the obligatory "all rock" joke in there (for
>those that have been following along!) we could implement something
>like that for our NPC. When he stumbles across an object, he begins
>trying to manipulate it. Each success or failure would be stored in
>the knowledge frame...
> (object rock (can throw) (can-not eat) (can take)...)
Uh oh, now we're getting into the old Knowledge Representation area
of AI. I don't know a lot about it myself, but I have learned one thing --
it's a much harder problem than it seems (which is why it's still in
the realm of AI). Careful, this discussion can get pretty hairy
rather quickly -- those interested might want to read up on the
Arriving home, they learned that Glenn and Edna Catwomb had been
slain by maniacs.
Not all characters are there to give you an object or ask you a riddle.
Perhaps the innkeeper is there just to run the inn.
>that most puzzles are simply of the "all all" variety, and here's a
>variation where the user can do that all day and still not get anywhere.
>Maybe the user will learn that it ain't gonna work, and start paying
>attention to what's going on. [Bringing in the idea of time, we can
>allow for racing between characters...don't spend too much time on
>one object, or another character might pick up somethng else and take
Perhaps. But the NPCs (usually) shouldn't be *trying* to race you to the
object, especially if they shouldn't know it's there. If a troll comes
across the sandwich, it'll eat the sandwich. But it shouldn't specifically
go running for the sandwich, to beat you to it [unless it knows the
sandwich is there, and knows you want to get it].
>Or, succinctly: NPCs should all have a purpose in the game, even if that
>purpose is simply to add variety to what the player encounters.
Well, I would put it like this: NPCs should have a reason for all their
actions, which is consistent with their role in the game, and in the world.
>>Most of them should be natives to the area, too.
><shrug> Why? I think the idea of stumbling across another adventurer,
>on the same quest that you are, is kind of neat. Or what about an NPC
>that you run across in town, who's probably never been in the caves at
>the base of the mountain?
Okay, sure. But then, this sort of NPC isn't likely to be found in the
caves, is he/she? But wandering around the game, most of the NPCs will
live in and around the places you find them. This is simply common sense.
If they didn't live there, why would they be there? (Unless it's just
on vacation ;P)
>>This means they should know where all the
>>locations are, where all the objects are (or, more accurately, where they
>>last saw them),
>I'll agree that, if we're talking about townspeople, then sure, we can
>give them a map to get going. Other than that, though, let them figure
>it out right along with the player.
I suppose. It depends on the creature.
>>and should have some sort of point to being here. No
>>real person just walks around randomly.
>Making a stable script for NPCs would be tough, but I don't think impossible.
>The earlier example was given of a character who was told to open door,
>go through door, and get sick [or something like that]. But, if he
>opened the door, and then you closed it on him, the script went all flooey.
>Maybe something more the equivalent of:
> WHILE in_room(1)
> if (opened(door)) then go_through(door);
>Seems like it would do a little bit better of a job checking to make sure
>that the environment hasn't changed unacceptably.
This would be good. But what I'd really like to see is each NPC being given
some goals, be it "guard the bank" or "find food to eat." The NPC would
examine its current situation, and decide on actions to achieve the goal.
Then scripts would be unnecessary, and action would be more realistic.
>>Perhaps the ogre wanders the
>>area looking for children to eat. Fine, so he should use some sort of
>>search pattern, whatever it might be.
>Ogre? search pattern? Ogre goes where ogre wants to go.
Well, okay. But even dumb ogre won't wander completely at random.
It might sniff for children, and then follow the tracks. Or something.
But it's not just going to toss dice to see where to go (unless it's lost
in a maze, in which case it just might)
| One .sig to rule them all, one .sig to find them... |
| One .sig to bring them all and in the darkness bind them |
| The Grim Reaper (Reaper of Souls, Stealer of .sigs) |
| scy...@u.washington.edu |
Well, it depends. Most NPCs won't have solving the game as their objective.
They'll be trying to guard the bank, or get food to eat, or whatever.
*IF* they're trying to retrieve the jade statuette of Bob, or whatever
you happen to be searching for, the game gets much more complex.
>How can you define "interesting" behaviour of a "non-player" character in a
They don't always have to be interesting. Maybe all the guard does
is pace back and forth. But it's important to the game to have him do this.
>The problem is, imho, that mixing the requirements of "game" (where the player
>must "solve" pre-canned problems) and "fiction" (where the player should be
>creating their own problems) is muddying the waters considerably and making the
Not unsolvable, I hope, but just more difficult ;P
>Interesting characters are vital to "fiction" since nothing happens otherwise.
>Purely reactive characters are acceptable in "games" but the more variety the
>Looks like Bob might take quite a while dying - don't you wish you had a
> I've been lurking awhile waiting for some more discussion on this topic of
> realistic characters or NPCs. I can only say go for it folks; as I've noted
> before, I'm a novelist hungry for programs that'll let me involve my reader
> in deciding (for example) what's to become of the people in a troubled
> family. Not only do I think this will make great reading, it'll be a
> $$$-making educational and therapeutic tool for those of you who come up
> with it. From my time watching I've come to understand a little of the
> enormous complexity involved, and am trying with one of your group to work
> out some computer-friendly ways to create characters...it ain't trivial, as
> the man said. But think of the possibilities, and keep on
> Joanne Omang
As another writer, I second all of the above. My experience in
film/television has taught me the value and necessity of collaboration.
The methods I've developed as an actor/writer to create character may
(or may not) be transferable to IF, but only a cooperative effort can
explore such potential. Personally, I am quite sure that the rewards
for tackling the tough AI issues are worth the effort, and I expect
that many of the AI wheels already invented will prove quite adaptable
to IF (especially Knowledge Based Systems and Case Based Reasoning,
maybe even Simulated Neural Nets).
My rules of thumb in this quixotic search for the next generation IF:
1) the illusion of intelligence within role constraints;
2) collaboration between multiple engines of different types;
3) allowance for emergent patterns through agency interaction;
4) provision of an easy interface for writers offering lots of
5) the final experience for the player being a human-computer
in story improvisation.
That's five thumbs, making me all-thumbs on one hand, yes. I am not a
programmer. On the other hand, the one that holds the pen, fumblers
like me may have something adroit to contribute. We all have our
talents and it takes many kinds of abilities to put on a show.