[MUD-Dev] Modeling spells/skills as collections of affects

[clawrenc at cup.hp.com]

In <199708312324.3515400 at bedford.net>, on 08/31/97 
   at 06:41 PM, "Brian Price" <blprice at bedford.net> said:

>In the codebases I've seen thus far, spells and skills are largely
>hardcoded.  I would like to implement a system where they were
>instead parameterized and stored in the mud's database.  

I don't recall if you joined before the thread on Bartle's Waving
Hands magic system.  Its worth looking at.

>One approach
>to this would be to describe spells and skills as a collection of
>event-dependant affects.  To implement this, the definition of
>affects would need to be expanded a bit, for example, a mud object's
>location would be an affectable state.  Also, there would need to be
>a system of events which would trigger the various affects.  

This is slightly ambigious.  On the one hand are event driven or
reactionary systems as suggested by your referencing to "triggering"
of affects, and is that of some form of standarised and flexible model
for applying temporary or layered macro-modifications to an object.

The two areas are fairly tightly coupled, but remain distinct.  To
date the model side has gotten the most interest/traffic.  Handling
the layering concerns, as mentioned below, ended up wandering off into
the bushes and diesing.

The model topic was debated and discussed heavily in this list in the
early parts of last year (AlexO, Wout, ChrisG, and myself as I
recall).  Several competing models were proposed and championed,
variously named "affects", "Affects", and "spoofs and watchers".

The following is what I recall of the definitions.  If there's
sufficient interest I'll dig up the original messages and correct as
needed as I'm a little sloppy on the affect vs Affect bit:

  affect -- Wout's proposal taken from Merc?  A named set of attribute
weightings applied to a player object.  An affect simply added its
attribute values to the matching attribute values of the original
object.  As such an affect might increase a players max_strength by 5
while costing them 20hps for the pleasure.

  Affect -- AlexO's contribution?  A named set of attribute weightings
and full function bodies (weak OO model) which could be applied to a
player or other object.  An Affect added its attribute weightings to
the matching attribute values on the object.  Functions opaquely
overlaid any prior methods of that name.  A later extension had
Affects functions instead creating little function lists as they were
applied.  Thus prior versions of the function could be called from a
given Affect's version of the function.

  Spoofs and Watchers -- My contribution.  A spoof is an object that
replaces another object (assumes the other object's ObjectID), while
retaining a copy of the original object under a different (temporary)
ObjectID.  The intent of a spoof is that all messages sent to the
original object would instead be intercepted by the spoof object.  The
spoof object could then process the messages however it wished,
passing them on as necessary, edited or not, to the original object. 
Mechanically a spoof object is indistinguishable from the original
object it is replacing, in this manner a spoof essentially acts as a
hidden filter between the message sender and the original object,
where the filter intercepts all messages and may kill, rewrite,
divert, or otherwise edit them.

  Watchers on the other hand are a two part affair consisting of a
"Watch" and a "Watcher".  A Watch is an entry made against an object
(and stored with the object) that notes that upon any state changes to
that object an I_HAVE_CHANGED message is to be sent to a specified
second object known as the Watcher.  Thus there is one object that
changes, and another object (the Watcher) which watches the first
object and reacts to its changes.

A point to note is the model difference in their concept of a ctor and
dtor.  affects are trivially simplistic, merely adding the values on
ction, and subtracting them on dtion.  Affects actually "popped" off
their objects, much like a stack machine.  Spoofs generally have
simplistic ctors and dtors which merely restore the original ObjectID
to the spoofed object.

A weakness which impacts all these models is the concept of implicit
ordering and detection of side-effects between multiple applied
affects/Affects/spoofs (can he be a near FireGod _and_ a water sprite
_and_ terribly sleepy?).  I do not recall that any decent solution was
arrived at.  My current partial solution is to use priority values for
spoofs.  Spoofs then attempt to order themselves via insertion at
install time on an object in priority order such that any message to
the object goes to the lowest priority object first, then the next
highest etc until the true original object is reached.  

>Has such a system been implemented elsewhere?  If not, any thoughts
>on how such a system could/should be implemented?

In the general case, just the above.  I'd recommend digging up the
original threads surrounding the Great God GooGoo/Castle Krak/Elven
Forest scenario which is what I used to benchtest and excercise my
spoof model.  If requested I can repost key bits here.  I recall (?
dream?) that AlexO used to maintain slightly threaded archives during
that period of the list.  He might also be a useful resource.

--
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...