J C Lawrence wrote:
> On Sat, 27 May 2000 16:19:01 -0400
> Jon A Lambert <jlsysinc@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@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.*--