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

[clawrenc at cup.hp.com]

In <Pine.OSF.3.96.970905163356.4223B-100000 at saul4.u.washington.edu>,
on 09/05/97 
   at 04:49 PM, Dan Shiovitz <scythe at u.washington.edu> said:

>On Thu, 4 Sep 1997 clawrenc at cup.hp.com wrote:
>> In <199708312324.3515400 at bedford.net>, on 08/31/97 
>>    at 06:41 PM, "Brian Price" <blprice at bedford.net> said:
>[..]
>> 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".
>[..]
>>   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
>[..]
>> 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.  

>I've been thinking of something vaguely like Affects for my system.

>I'm still not precisely sure what to do with someone that wears
>cursed gauntlets of fumbling that make her miss all the time and
>wields the magic  spear Elsinore that always hits its target. 

The spear hits its target after the player drops it.

>I guess
>some sort of priority system would be the way to go here, yes. 

Uhh huh.

>Of
>course, I have no idea of a consistent way to do so ("yes, this one
>makes you always hit with level 40, whereas this one makes you miss
>10% more often with level 50 .. so you add them together, and get, uh
>.."). 

This is fairly relevant to the probability field thread that ran here
several months ago (I'll repost the key portion if requested). 
Instead of having the various objects create absolutes, instead have
them add weights to the probability field for that probability type. 
This won't of course do out-of-the-box thinking such as the above
(drop's the spear), but does do most of the general cases.

>I suppose that's not a terrible way to do things: if each
>affect is given some sort of power level as well as its actual
>effects, then when two affects contradict each other you could let
>the more powerful one take effect, either at full power or at the
>difference in power of the two .. so maybe in the above example you'd
>miss 1% more often instead of 10%.  Or maybe that's stupid, and if
>you're wearing always-hit shoes and a miss-10% belt, then you should
>always hit.  

My approach:

  Bubba has a probability weight for to-hit of X.

  Bubba is in an area which has a probability weight for to-hit of Y.

  Boffo (the one hit) has a probability weight for is-hit of Z.

  Bubba has various other objects which have various probability
weights for to-hit.

  All these values are summed as the current probability weight for a
single blow.  The roll is made on the blow, and it either succeeds or
fails.  Failures then fall into a cascading series of
fails-but-does-something-else cases.

>Or maybe I just shouldn't have any always- items in the
>game :)

I'd say this is a good suggestion.

>I'm not quite clear on why spoofs are a good idea, though. It seems
>like replacing the entire object just to modify its hitroll (or
>whatever) is a bit excessive; can't you just have a list of affects
>on the object and ask each of them if they modify its hitroll, and
>have queries about the object's hitroll receive a consolidation of
>all that information?

A spoof is expensive if all you are doing is touching up a hitroll. 
They are really built for more complex and object-incasive cases where
entire methods are replaced or altered, or the entire behaviour of the
object is transformed, such as:

  The Elven Forest/Sceptre/Castle Crak scenario oft discussed here. 
Much simplified: If the sceptre is in the elven forest, all magic
ceases to operate in Castle Krak.  Magic instantly resumes operating
when the scpetre leaves the Elven Forest.

or:

  The old Great God GooGoo and his holy relics scenario.  (I'll repost
on request).

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