Re: AI scripting language, was Re: CF: More roleplaying

[David Andrew Michael Noelle <dave@Straylight.org>]

> Date: Wed, 22 Sep 1999 22:38:06 -0700
> From: Ian Main <imain@netidea.com>
> 
> On Wed, Sep 22, 1999 at 09:04:31PM -0700, Mark Wedel wrote:
> > 
> >  I think one thing that needs to be examined is what features are
> > needed in a scripting language.  I can take a quick look at perl,
> > and for crossfire, maybe it would need about 10% of the functions
> > it has to offer (the regex stuff is nice, as is the general
> > control structure, but pretty much all the standard functions
> > should not be used, and even many of the more simple things (like
> > arrays and hashes) have to be carefully done, otherwise you could
> > have a buggy perl AI consuming tons of memory as it keeps
> > allocating stuff but doesn't deallocate it.

Exactly what I was thinking.  The regex stuff can be handled by the
standard C regex library and the control structures are easy enough.
I think we'd be better off with our own light-weight scripting system.


> The callbacks are the way to go.. for instance, I would imagine that
> anything anything is said in the room with the npc, a callback could be made
> (that would be associated with that npc.. held in its struct or what have
> you) so the perl script can parse (probly using regex) the string and figure
> out what it wants to do..  Other events might include movement,
> dropping/giving, picking things up etc.  

I would suggest that this should be done by placing script objects in
the NPC's inventory which respond to external events.  The map can
keep a list of all the script objects that respond to different types
of events and check the appropriate list when an event of that type
occurs.

For example, to make an NPC respond to speech, give it a "hear speech"
script object containing the specific phrases or words it should
listen for (as regex's) and whatever actions you want it to perform.
When the map loads, a pointer to that script object is appended to the
map's "hear speech" list.  When anyone says something on that map, all
the scripts on the "hear speech" list are checked and the ones that
match are applied.

Similar archetypes of SCRIPT objects could exist for being given an
object, seeing an object dropped on the floor, seeing another creature
with a specific marker (or lack thereof), being attacked, or just
detecting changes in user-defined variables.

User variables could also be objects.  If a script has a reference to
a variable, it recursively checks its environment for VARIABLE objects
with that name, starting with the creature or object whose inventory
the script itself is in.  If it gets all the way out to the map, the
map would have a stack of VARIABLE objects that apply to the whole map
and are saved with it when it is swapped out.  If the variable still
isn't found, there might even be a list of global variables so that
values can be carried across maps.

Actions could similarly be implemented as objects, by placing them in
the inventory of the SCRIPT object that would activate them.  Or they
could be written into the SCRIPT object's message field and fed into a
lex/yacc interpreter when activated, which would probably work better
and conserve memory, since commonly reused scripts would use the same
shared strings.


> What you can do in perl is define a seperate namespace associated
> with each instance of the npc, so you can keep state (if necessary)
> in whatever variables you wish and there will be no namespace
> collisions.  (this is done using 'package' keyword.. just stick it
> at the top of the perl code you're going to eval).  I'm pretty sure
> I saw a thing to wipe out all memory associated with a namespace
> too, so it'll do good garbage collecting for you and you don't need
> to worry about memory leaks so much.

The method described above is object-oriented, so every creature on a
map might have its own copy of the same variable, and each creature's
scripts would automatically use that creature's variable.  It may not
be as powerful as callbacks to a full-featured programming language,
like PERL, but it would get the job done, and would probably be much
easier to implement than an embedded PERL interpreter.



-- 
            -Dave Noelle,                 dave@Straylight.org
            -the Villa Straylight,  http://www.straylight.org
Coalition Against Unsolicited Commercial Email  ==  http://www.cauce.com

Quote of the Day:
"This passion for verbing nouns really fingernails my blackboard."
  - Mark P. Nelson
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]