Newsgroups: rec.arts.int-fiction
Path: gmd.de!xlink.net!howland.reston.ans.net!cs.utexas.edu!uunet!world!dmorin
From: dmorin@world.std.com (Duane D Morin)
Subject: Re: Some further thoughts on NPCs
Message-ID: <CMFM68.3uH@world.std.com>
Organization: The World Public Access UNIX, Brookline, MA
References: <D91FE.94Mar8003105@bengan.pt.hk-r.se> <grady.763085126@xcf.berkeley.edu> <CMCnAA.DM5@world.std.com> <2llqvb$fl@news.u.washington.edu>
Date: Thu, 10 Mar 1994 04:37:18 GMT
Lines: 92

In article <2llqvb$fl@news.u.washington.edu>,
The Grim Reaper <scythe@u.washington.edu> wrote:
>Or even use the game of Life idea.  Give the NPC rules to follow, not 
>specific situations to handle.  If the rules are good enough, the NPC
>should be able to create extremely complex actions from them.

[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
possible...
	(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...

	PLAYER you;
	NPC troll;

	you->eat(food);		// is the same thing as
	troll->eat(food);

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.

Duane


