[MUD-Dev] Magic as Metaphor

[J C Lawrence]

On Fri, 13 Mar 1998 21:05:01 PST8PDT 
Jon A Lambert<Jon.A.Lambert at ix.netcom.com> wrote:
> On 12 Mar 98 at 19:55, J C Lawrence wrote:
>> On Thu, 12 Mar 1998 16:07:50 PST8PDT J C Lawrence<claw> wrote:
>> 
>> > http://www.vuw.ac.nz/~jay/nephilim/metaphor.html
>> 
>> > Magic as Metaphor > An Alternative Magic System 
>> > by Jamie Norrish, 1995 

...deletia...

> I'm not familiar with the Nephilim magic system.  

Nor I.  Jaime alas is no longer on the list.

> I haven't posted
> much about magic systems other than on the threads related to
> alchemy and deity systems.

My magic design m (IP, I don't like the primitve set yet -- its too
low level and unorganised) is loosely based on Waving Hands, the
earlier discussion of a magical algebra, and my already well defined
particle resource economy model. If you haven't played Waving Hands
yet -- do.  Its fun and educational in rather surprising ways.

I have moved away from tieing the magical casting expression to the
fingers ala Waving Hands.  Instead I'm positing that the finger
motions are merely a mode of expression which is tied to the caster's
personal memnonics and not to the magical end at all (cf finger
positions in some branches of kinesiology).  Thus some mages may cast
via finger wiggles, others may dance, tap rhythms on a drum, sit
motionless, count beads on a rosary, or whatever else fits their
mental strictures/structures.  Mages who need no mechanical assitance
for their mental framings and place-tracking might cast potent spells
quite off-handedly without visibly affecting their other actions.

The underlieing reasoning for this abstraction is that I found it
awfully difficult to think of how to have either a swarm body, or an
amorphous blob play Waving Hands using the finger style.  Similar
considerations ruled against the two-handed strictures of Waving Hands 
as well.

That said, the visuals are easier to understand from a fingers
perspective.

There are a number of base primitives.  These are things like: energy,
motion, explosion, implosion, etc, modifers like direction, location,
sign-reversal, relatives which define an affinity of type, character
or location to another existant object, and finally there are also
termination primitives which are currently open, close, and release.

A spell is then an algebraic expression composed of these primitives.
Thus a typical fireball spell might be expressed in normal algebra as:

  open + energy + energy + energy + frame + particle 
  + type_affinity_to_fire + close 

Which expands to: Three energy units, in a single particle, with the
particle being like fire.  This would create a "spell object".  To do
this finger-style might be:

  Three fore-finger taps, a fore-finger thumb frame, a pinky-finger
thumb circle, a bent thumb down and fore-finger point at fire, with
flat hand to close.  

In a fight the mage would (algebraicly) then do:

  open <fireball_object> + direction_to_target + motion + motion 
  + close + release

With the result being a fireball flying from the caster to the target
with double speed (motion + motion).

Much more effective however would be:

  open <fireball_object> + location_affinity_to_target + close 
  + release

Which would cause a firey explosion at the target's location
where-ever he was without necessarily traversing the intervening
distance.  

>From a player perspective this comes out as, "yeah, some energy, and
more and more, lump it all together, make it like firem aim it at
Bubba, and SHOOT!".  It also quite nicely translates to a GUI
interface where all the primitive components are buttons etc.

Two points are notable:  Spell objects, and spell releases.  They are
seperate things.  A cast spell merely creates an unrealised potential
-- essentially a probability structure.  Releasing the spell attempts
to create the probability structure IRL.

Lots of other things come into play in these regards, making for
potentially incestuously intricate play:

Casting the spell of course consumes particles of various types and
signs (mana etc, see prior discussion on particle type conversion and
zero-sum totals).  If the particles are not available, then the
algebra fails.  By default these failures release the spell -- which
could be deadly if you're in the middle of building a *really* huge
fireball when Bubba walks up and arranges for all the local mana to go
elsewhere...  Such can be prtected against, but its expensive.

A cast spell creates a spell object.  Actually its created when the
spell is started, but it only starts pretending to be stable when the
spell is closed.  Spell objects are not physical objects, tho they can
be embedded in physical objects.  Like all objects they are consumers
and producers of various particle types, and will self-destruct or
release if starved (depends on spell type, circumstance, and
environment).  The result is that a competant mage may carry many
spell objects with him for use and release at a moment's notice.  The
reason not to carry such is that said spell objects are resource
consumers and may be deadly to the carrier (Ooops!  Stepped into a mana 
poor area and all my fireball spells just went BOOM!  (And a good reason to
carry mana attractors and producers)).

Additionally there are few to no securities on spell objects.  Thus a
rival mage could abscond with your spell objects, use them against
you, or corrupt them so as to alter their effect when used.  (This is
actually the reason there are spell algebra primitives which tie into
the MUD language, especially spoof/watcher model.  This allows spells 
to be "intelligent", with such intelligence equating to "daemonic" and 
thus expensive).

Spell release is simpler from a play perspective.  The probability
structure has been established and cannonised in the form of a spell
object: the release just lets it go. The problems are that the release
requires the resources (particles) to be available to satisfy the
algebra (that energy has to come from somewhere), and the various
relevant probability fields.  

This works out as follows:

  Bubba starts casting a spell.  This is difficult and goes thru the
normal probability field checks.  It either succeeds or fails.  Either 
way it is expensive.

  Every operation (spell primitive) is evaluated against the current
probability maps.  Essentially the operation either fails, flounders,
or succeeds.  Failure has no effect.  Flounder causes the spell to
release or possibly commit the operation with a reversed sign or other 
corruption.  Success commits the operation.

  Bubba closes the spell.  This is difficult, and is a primitive.  It 
goes thru the normal checks, and if it fails, releases the spell
(spell casting is *DANGEROUS*).

  Modification of a spell object works similarly (spells can be
compounded from other spell objects).

  Release of a spell object does two checks:

    Do the resources exist to realise this spell?  (ie enough mana,
energy, and other particle types?  Note: Such resources can be "bound" 
to a spell object by putting the spell object in a physical object
containing the necessary resources).  

    Does a probability check based on the person who released the
spell (and his environment) pass (ie encouraging the model where one
character may maintain a high probability field for manufacturing
spells, and another character for their release producer/consumer
style).

The challenge is to maintain the ambiguity level of Waving Hands.  The
big challenge in Waving Hands is to realise what the current finger
wave stack of your opponent is, and thus what spells are possible from
where he is now.  That single challenge (and poker-style prediction)
keys the entire addiction of Waving Hands.  However with the less
ambiguous algebra most of that dissappears.  <sob>  

To attempt to do this I've added the ability for spells to be
compounded of other spells, for spells to reference other spells, and
for the caster to target his current operation to a different spell
object (eg Mage A is crafting a spell, Mage B is too.  A is building a 
fireball, and B is building a flood spell.  B adds his water
component, originally intended for his own spell, to A's fireball
spell, thus, err, "ruining" it").  Bandwidth 

-------------------------------------------

While this probably all sounds a bit complex, from an interface
standpoint it need not be.  Consider a GUI world:

  <click on start spell button>

  <drag in energy object>  (three times)

  <drag in particle/ball object>

  <darg in fire_type object>  

  <Click on save spell button>  (object is created)

And for the release:

  <click on spell object>
  
  <drag motion object onto spell>  (repeat)

  <drag spell object onto target>

--
J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...