[MUD-Dev] Re: Stack-Based NPC AI

Mik Clarke mikclrk at ibm.net
Mon Dec 7 22:40:46 New Zealand Daylight Time 1998


Richard Woolcock wrote:
>=20
> Eli Stevens (KiZurich) wrote:
> >
> > [Emil Eifrem, Re: Spell components, chemistry and the like...]
> > > I've never played on a mud that has an AI worth mentioning. :(
> >
> > This statement (which was made some time ago, I should add) got me th=
inking
> > on ways to design a simple, yet powerful "tasking" (for lack of a bet=
ter
> > word) system for a MUD=92s mobs.  I had read on the web about using a=
 stack to
> > simulate a mob=92s priorities, and was wondering if anyone here had a=
ttempted
> > (successfully or not) to design/implement anything like what I descri=
be below.
>
> The only advantage a stack-based system has over a state-based
> system is that the former method allows mobs to 'remember'
> situations they were previously doing and go back to them at a
> later point - but for animal-level intelligence, I don't think
> that would be necessary.

I'm not so sure that's much of an advantage.  Obsinately trying to
continue with whatever action it was attempting an hour or two ago is
quite likely to be 'wrong' in terms of the current situation, espeially
if it is meant to tie in with some other event (like the shops being
open).  Having the mob refigure what it is meant to be doing can be
useful at times.

> If you're planning immitation of human-level intelligence, your
> greatest problem is going to be mob speech.  You could also
> store the 'memory' as a list rather than a stack, so that things
> can be inserted - thus allowing mobs to plan things ahead (next
> week, Bubba has to go and pay his Council Tax).
>=20
> KaVir.

Hmmm. I've currently got a scripting system where mobs can schedule
actions in advance (in fact, all mob actions are schedulded).  This
allows for actions that have long delays and for other actions to be
inserted before them. Each action has a 'command set id' attached to it,
allowing for the selective purging of sets of actions (under the mobs
control).

The action driven can be a normal command or a command to schedule
another script or, eventually, to generate an 'introspection' event,
which will let the mob consider what it should be doing.  This event
will go through the mobs triggers and, by interacting with the mobs
memory and the status of the world, can selectively pick the script to
schedule next.  I'll probably allow for a player from the mobs memory to
be inserted into the event as the victim, effectively allowing the mob
to think about a specific player.  This would let the conditions in the
trigger checks look at information about that player in working out what
the mob is going to do.  I'll probably use a simple MPREMEM command to
let the mob remember a particular player.

If I can get it running well enough I'll look at a 'thinking' mob - one
which receives an introspection event every two or three seconds,
allowing it to frequently reevaluate its goals and what it should be
doing to acheive them.  This needs a very efficient implementation of
the trigger/event comparison mechanism though. (And a somewhat more
sophisticated mob memory/quest mechanism than I have at the moment.)

I do like some of the ideas about prioritized goals (or even mini-quests
for a mob).

Mik
--=20
http://www.geocities.com/SoHo/Cafe/2260




More information about the MUD-Dev mailing list