[MUD-Dev] Thoughts about smarter Sims

[Jon A. Lambert]

J C Lawrence wrote:
> On Sat, 27 May 2000 16:19:01 -0400 
> Jon A Lambert <jlsysinc at ix.netcom.com> wrote:
> 
> > Wouldn't it be marvellous if a mud server could analyze those
> > discreet inputs in a wider contextual window in order to develop
> > the tactics, strategy, story and language for its own projections?
> 
> Such as?
>

Well here are a few examples...

Tactics ... 
Assume NPC dragons are highly intelligent beings (some games hold other
assumptions on dragons).  NPC dragons as a class log player activity 
against themselves that is both successful and unsuccessful.  Tactics 
are chosen based on a dragons perception of the make-up of an attacking 
party and the species memory (class memory).  Survival tactics may 
generate short term goals or plans to aquire spells or items to increase 
power or fight, flee and surrender behavior.  Players share information 
and rumor about the best way to kill dragons.  Perhaps dragons share 
information and rumor on players.  By wider contextual window, I mean 
aquiring accumulated historical data and using it in tactical activity.
And by tactics, I don't mean to limit it to combat.  NPC merchants would
engage in tactical trades based on rumor and local price flunctuations.
Typically merchants really do not compete with players economically.
Suppose one had an auction channel.  Why shouldn't NPC merchants monitor
and even bid on items they know are undervalued?  

Strategies... 
NPC dragons have both long term plans or goals and short term goals.  There 
are species plans common to all dragons, like acquiring gold and gems, maidens, 
etc.  Goals that are intrinsic to dragons.  There are individualized plans 
or short term goals that arise from local conditions.  Not enough gold or 
maidens available locally and a dragon will abandon its lair and take up 
residence elsewhere.  Too many high-level parties about and partial defeats,
robberies, near-death experiences, and likewise a dragon will move elsewhere. 
Lots of nearby gold and gems, plump maidens, and absence of negative experiences
may attract more NPC dragons to an area.  It might affect their reproduction
rate, etc.  The bottom line here is that NPCs don't just exist in a room
aquire and use information merely from those discreet events that occur within
that room.  They have long term strategic goals, aquire information relating to
those goals and perform actions to attain those goals (procedural reasoning).

This sort of AI is quite common to other games.  Not so in most muds.
The key here is not just designing goals that "win" games for NPCs since
in a mud there is usually no "game-over" position for an NPC other than 
death.  But goals that attempt to maintain and extend a winning position for 
a given NPC.  

Also strategies that recognize parasitical relationships, or goals held in
common with other NPCs and players.  Influence and favors.  A highly intelligent
NPC dragon should be susceptible to bribery for favors.  Probably significantly
more difficult than the town watchman yet possible.  This requires memory of 
player behavior and the ability to analyze it and assign value to it.  We 
touched on this a little bit in discussing reputation systems.  NPCs that 
maintain +/- favorability ratings on individual players.  Creating feedback 
loops between players and the environment.
 
Story and Language...
These are related to the current topic and perhaps NLP.  A great many player 
events involve communication amongst themselves and public communications in
rooms.  NPCs should be able to monitor and parse this information and 
regurgitate it in rumor systems, or in goals.   Suppose players discuss robbing 
the local bank in the middle of the day in a busy town square.  They proceed
to the bank at some later point and find more town watch than usual in the area
the bank, and perhaps double or triple the guards inside the bank.  Why?
Maybe a thread that monitors public communications for that local area hit
upon certain predefined key words like "rob bank".  The plan/goals system for 
the bank was signalled with a attack likely event and then took actions in 
order to mitgate it.  Suppose the players decide to rob it and succeed anyway.
This is where story comes into play.  Events like this generate story elements
which are turned into published accounts in newspapers or town criers.  Which 
in turn become another source of information for local NPCs that monitor
local events.  Perhaps these events and public player conversation becomes the
main source for NPC banter.  Perhaps each story event is assigned an importance
value and logs are extracted monthly in order to generate web page town histories,
national histories, world histories depending in addition or supplemental to 
game master and player bard generated material.

Why shouldn't NPCs attempt goal-oriented communication with players?  For 
example perhaps a plate-armored character wanders into a smithy in a village
which is experiencing a severe shortage of steel.  Typically this is a
one-way interaction.  The player wants something.  Perhaps he wants a sword 
repaired.  The merchant either can do it or doesn't.  Now if merchants examined 
players for what the merchant has a compelling need, they might make use of 
language processing to make offers or suggest trades.  The mud characters seem
slightly more alive.  The Ultima series offered up conversation that was 
immediately relevant or leading to the player.  Maybe too leading.  Yet the
principle is the same.  Players might even visit shop owners specifically
shopping for information.  

Language processing outside of the command prompt is poor in most games.  
There's a lot of useful data that can be gathered from player communication and 
fed back into the game to make it seem "more alive". 
     
> > I've just finished implementing my mud language interface to a
> > procedural reasoning system for programming tactics and strategies
> > into mud objects.  I call it Apollo.  I have the ability to log
> > interesting events and track their effects on a given object's
> > predefined inputs.  
> 
> What sort of implied effect tracking are you doing?  
> 

A procedural reasoning module has a number of parts.  First there is
and environment definition.  This is basically a interface definition 
of all variables that will used by the module and the mud objects that 
provide the source.   It can be a relational of numeric expression also.

MODEL rat_model
cats = ithaca.cat.count
rats = ithaca.rat.count
critical_population = ithaca.rat.count < 50 
grain_stored = ithaca.grain.produced - ithaca.grain.sold
ENDMODEL

Listeners are installed on the variables defined in the interface.  When
a value is changed in a mud object variable that is defined as a source
in procedural reasoning model an evaluate() event is issued from the 
interface to all those procedural reasoning modules interested in that
model definition. 

There are RULES definitions which list goals/plans and priorities and the 
names of the plan definitions.  There are local rules variables that keep 
track of current status.  Similar to static variables.  The evaluate()
event processes the rules and selects the next plan.  PLAN definitions 
include a series of procedures that are invoked to accomplish a goal along 
with the context in which that plan is valid.  The RULES definition will not
select plans that are "out of context", however a plan procedure may set
the context value back to false of a previously accomplished plan.   Each 
plan definition is written in a procedural language that has the ability to 
execute other plan procedures or issue messages to mud objects (i.e. execution).  
This is similar to your typical Mob Programming Script, except this language has
the ability to set a plan result status, like ACHIEVED, CONTINUED, or FAILED.
Setting the context status of the current plan or causes evaluate() loop to
run on the RULES definition.  Note that CONTINUED is the same as temporarily
suspending execution of the current plan to engage in rules evaluation. 
(Thus NPC Bubba could suspend building the Panama canal in order to pause
reflect and dig for nose gold and then continue with his building).  
Rules definitions select plans based on context and current conditions, thus 
if Bubba is under attack the defense plans will be set at much higher priorities
than building the canal or digging for nose candy.   I should also mention
that the objects that have PRMs attached to them implicitly include their own 
data as part of MODEL definition.

I'm still working on the documentation.  :-( 

Nevertheless... 
This is a sample PLAN. 

PLAN rats_feed
  CONTEXT 
     this.hungry = true;  // Using variable deined on object
     this.attacked = false
  ENDCONTEXT
  BODY
     EXECUTE this.find_food();  // message to self
     if (this.hungry == false) 
       ACHIEVE rats_feed;
     else
       CONTINUE rats_feed;
     endif
  ENDBODY
ENDPLAN 

And a simple RULES definition

RULE rats_rule
  MODEL rat_model;
  INIT
    PLAN rats_feed PRIORITY 5;
    PLAN rats_reproduce PRIORITY 5;
    PLAN rats_flee PRIORITY 1;  
  ENDINIT
  EVAL 
    if (this.room.contains(objtype(cat)))  
      PLAN rats_flee PRIORITY +5;  
    endif 
    if (this.attack)
      PLAN rats_defend PRIORITY +5;
    endif
    if (critical_population)  // see rats_model
      PLAN rats_reproduce PRIORITY +2;
    endif  
  ENDEVAL
ENDRULE



--
--* Jon A. Lambert - TychoMUD        Email:jlsysinc at ix.netcom.com *--
--* Mud Server Developer's Page <http://tychomud.home.netcom.com> *--
--* If I had known it was harmless, I would have killed it myself.*--
 





_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev