[MUD-Dev] New topic: AI and NPCs

clawrenc at cup.hp.com clawrenc at cup.hp.com
Fri Sep 5 12:59:36 New Zealand Standard Time 1997

In <199709011753.RAA122216 at out1.ibm.net>, on 09/01/97 
   at 10:54 AM, coder at ibm.net said:

>If there is interest I will re-describe my Combat Package and Combat
>Script architecture.  Essentially it allows for combat intelligence
>to be rendered as a component which can be traded among characters,
>and which in turn generates suggested tactics during combat.

<<There is interest>>

Note that this is a model I'm moving away from due to its round based
combat ties.  I've found that round based combat has problems when the
combatants may be variously close together or widely seperated , and
whre other commands, not combat related, may seriously affect a
combat's process.

However, the system:

Combat is round based.  

Upon a combat being initiated, a Combat Object (CO) is created.  The
CO is responsible for enforcing the rounds, and for resolving the
combat actions at the end of each round (what blows are delivered

The process of a round from the CO's PoV:

  1) The various combatant's (the CO has a list), submit Combat
Scripts (CS) for that round.

  2) At the end of the round the CO resolves all the Combat Scripts
against each other and makes a final determination on what actually
happens (what blows are attempted, which made, which ones cause
damage, etc).

  3) The CO sends messages to all the combatantants and other affected
objects on what happened during that round.

  4) Repeat fom #1.

The resolution of the Combat Scripts is interesting.  Internally the
scripts can be quite complex (see below), with internal conditionals
etc.  Each combatant has a combat skill value.  This is a simple
integer which increases slowly with good play.

The combat object resolves the various submitted scripts by iterating
across them, again and again, with the total number of iterations for
any one script controlled by the Combat Script submitter's combat
stat.  This multiple-pass arrangement allows for a CS to react to the
actions of another combatant's CS:

  eg CS1 attacks with X, CS2 reacts to X with defense Y, CS1 reacts to
defense Y with attack Z, CS2 reacts to attack Z with attack Q, CS
reacts to attack Q with feint R and attack S...etc.

As such the number of passes the CO makes over a given CS on behalf of
a combatant can severely affect how well it can react, and thereby
appropriately adapt, to its environment.  Combatants with higher
combat stats have their scripts evaluated more than combatants with
lower combat stats, and so have a better chance of their scripts
making the final, and possibly best, determination of what to do in a
given round.  Thus a very low skilled player would get his script only
evaluated the once whereas a very highly skilled fighter may get
evaluated four or five or a dozen times before the final resolution is

Note: Combat Scripts on one-time, throw-away items.  They are
generated by the combatant's Combat Packages, used for that one round
of combat, and then deleted.  The next round has a whole new fresh set
of scripts.

A combat script is composed of the following components:

--  Attacks, where blows are any of magic, physical, mental, or
aggressive defenses.

--  Defenses, where defenses are any of magic, physical, mental, or
defensive attacks.

-- Feints, where a feint can be an illusory attack or defense.

-- Sequences, where a sequence is any ordered set of attacks,
defenses, and feints (including a sequence of one member).

-- Reactions, where a reaction is a defined sequence to be used in
response to a stated sequence or sequence characteristic from a
defined or undefined opponent.

Additionally, each of these primitives is scaled by three values, the
level of commitment behind the blow be it attack, defence, feint, or
sequence (ie how important is it that the blow succeed exaclty as
defined), the force of the blow (maximum physical dedication for
success), and how much attention is reserved for things other than the
blow (ability to react, change course, detect other actions).

These together form Combat Scripts:

-- Scripts, where a script is a statement of the various sequences and
reactions to attempt during a combat round.

The design is for every combatant to submit a script (as above) to the
controlling Combat Object for the fight for each round.  At the end of
the round, the combat object resolves the scripts against each other
(feedback loops between reactions), and sets the sequences attempted
by each combatant.  These resolutions are then sent back to the
combatants, they do them, the relevant damages are levied (this is all
automatic), and the next round starts. 

My definition of a combat script is a one-shot statement of the combat
actions to attempt in a specific combat round.  It is dynamically
generated, possibly edited by the user, and thrown away as soon as the
round is over.  It is purely a statement of action.  A trivial example
(in english) would be:

  Stab Bubba in the chest with the sword.

It is specific and peculiar to the combat round in question.  It has
no relevance to any other combat round.  It also has no intelligence. 
Any inteliigence embedded in a script via reactions (conditionals) is
purely reactive.  It has no computatioal power.  It is an unthinking,
autonomous, and stupid push-button affair.  An example with reactions
would be:

  Stab Bubba in the chest with the sword.
  If Bubba attacks my head then block with the shield and stab him 
    in the leg with the sword.

If Bubba does *ANYTHING* but attack you in the head, you will try to
stab him in the chest.  Only if he attacks your head will you block
with the sheild and try to stab his leg.

Like I said -- they are dumb, very deliberately dumb.

Scripts are generated by Combat Packages which are installed on the
character.  There may be more than one combat package installed on a
particular character.  When in a combat state, each of the Combat
Packages installed on a character propost Combat Scripts to the user
for that combat round.  

Note: The reason that a combat package is called a package is because
it is a user-authored (Yes!  Users write the combat packages!)
discrete unit which can be installed, removed, bought, sold, traded,
re-writen, extended, etc as if it were a distinct object.  In many
ways it can well be thought of as a cybernetic bolt-on.

>From the user's once he starts a combat, as each round starts he is
then presented with a selection of possible Combat Scripts to use on
that round as poposed by his Combat Packages (bought, stolen, traded
with other players, or self-written).  He selects the one he wants,
sees what happens, and repeats.  From his PoV the script is a one-off
affair tailored for the exact current situation.  The script language
defines particular blows to be delivered with particular weapons to a
specified location on the opponent, or particular reactions (equally
detailed) to make against a specific attempted blow or defense by an
opponent.  This is then all overlaid with feints which disguise real

None of this is long-term predictive.  There's no setting up things
like wimpy factors, default reactions to all XXX attacks for all
combat scripts etc.  To do that sort of thing you need to tailor the
combat package directly.  (Actually I shouldn't say "NO" above, if the
combat package author adds that support, then yes, you could have a
"parry heavy blows" type configuration).

Now the Combat Packages are user witten.  They are essentially like
any other object in the game.  They can be bought, soold, traded,
given, stolen, clones, copied, or otherwise manipulated like any other
object.  A character may have many CP's installed, or just one or two. 
Particularly nasty mobiles might note that they are losing a fight,
and steal/copy their attacker's Combat Package to use against him.  

J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...

More information about the MUD-Dev mailing list