[MUD-Dev] To catch a mage (was fear of magic)

coder at ibm.net coder at ibm.net
Tue Oct 28 21:51:37 CET 1997


On 27/10/97 at 08:32 AM, Derrick Jones <gunther at online1.magnus1.com> said:
>On Sun, 26 Oct 1997 coder at ibm.net wrote:
>> On 26/10/97 at 10:10 AM, Derrick Jones <gunther at online1.magnus1.com> said:
>> >On Mon, 20 Oct 1997, Marian Griffith wrote:
>> >> On Wed 15 Oct, Michael Hohensee wrote:
>> >> > > On Tue, 14 Oct 1997 coder at ibm.net wrote:

>> >The problem here is twofold.  1.)  Magical travel is instanteous and
>> >doesn't leave tracks...
>> 
>> Why doesn't it leave tracks?

>Well, after some thought, I guess it could...

My base reaction for a teleport spell would be that it operates by
creating an n-dimensional fold in space-time, such taht very briefly that
section of space which the character occupies is simultaneously located in
two descrete points within the continuum (ie where he is, is in two places
at once).  Then, at the endo the spell, the fold relaxes, and space
becomes more or less euclidian, with our spell casting friend electing to
stay one "the other side" of the now torn-down fold.

To visualise:

  Take a sheet of paper -- that is the universe (2D, but hey)

  Draw a dot with a pencil -- our hero.

  Fold the paper in half -- space folds.

  Draw another dot where the folder paper overlays the original dot -- our
hero in two places at once.  

  Unfold the paper -- space unfolds.

  Erase the original dot -- our hero deciding which of the two spaces,
which were briefly one space, to now elect to occupy.

Given this sort of model (to which you can add all sorts of Nathan-esque
resource and physical mechanics to (which I have done)), I define that the
two locations which were once one, now have a base level of "affinity" for
each other, and that that affinity can be detected, and that it and the
two spaces which have that affinity can be manipulated as a form of
mechanical harmony.  

The degree to which they can be manipulated is then dependant on how
strong the affinity is.  This is a multi-part equation.  The closer the
physical proximity of the locations, the greater their "natural affinity",
and the slower any artificially induced affinity decays, and visa versa. 
Locations from different coordinate domains have less natural affinity,
and artificial affinity will decary more quickly, than for locations from
the same coordinate domains.  Within a domain, locations from the same
"area" or grouping/class object will tend to have a greater affinity, etc.

The higher the affinity of two locations, the easier it is to fold them
together.

At the lowest levels of affinity, a location can be made to "sing".  The
result is that the other, paired location also sings, and that fact can be
detected and located with great accuracy 9and some expense).  For a
location that has never been teleported from, the result is that the whole
local area then starts to sing, slightly.  

At higher affinity levels, the area of the matching other side can be
detected to various levels of precision.

At high levels of affinity the link can be re-established (ie, space
refolded etc) duplicating the original teleport.

This structure makes it trivially easy to follow a teleporting mage, as
long as you follow him closely, close enough that you can see the location
he teleports from at every hop (otherwise its somewhat difficult to
determine from where he teleported, and thus where the affinity
co-location is (a side benefit of time travel skills)).

This also reveals a standard ploy to prevent such tracing.  The mage first
drops a robot.  The robot is a trail hider.  The mage then teleports away
first, and very shortly afterward the robot teleports away to somewhere
(far) different.  The result is that the trail is more or less hidden. The
record of the later teleport is much stronger and tends to swamp the
mage's trace.  Really nasty cases drop multiple robots, and teleport
multiple times, each time dropping robots.  By the time the work is
expended to track them, the trail is cold.

>A movement spell affects two
>locations, the start and end points.  I suppose there is no harm in
>leaving some detectable trace magic at both ends...Now being able to tell
>which endpoint matches this particular startpoint may take some doing (on
>the part of the NPC), but at least their seach would be narrowed... You'd
>also get the interesting side effect of having guards portal into each
>recent exit-portal (all those areas targeted by a portal spell within the
>last 5 min or so), search the immediate surroundings, then portal back
>out until the correct portal is found...Maybe even have the guards
>interrogate whomever happened to be nearby.

Recursive tree search?  Echoes of The Wizardry Compiled here...

>> > Would it make sense for the guards to have magic-nullifying devices?

>Smack me.  

<SMACK!>

Actually, this is rather tough for me.  What I do is to flood the area
with suitably charaded particles of the appropriate class.  The result is
that they attract and destroy all the particles of the opposite sign --
making any behaviour (such as magic) needing those resources impossible. 
Of course creating that particle flood is expensive...

I also have a base field spell which actually is just a set of probability
field weights which lowers the probability of certain actions to damn near
zero for a localised area.  This can make certain forms of magic etc, let
alone combat, near impossible to do.

>I already have a spell that shields _items_ from magical
>radiation (really does a number cast on a magic sword because the shield
>is two-way).  It really wouldn't be too much of a stretch to encase a
>larger area (with probably some sort of weaker shield, with maybe some
>way to punch a 'hole' in it...).  The mages guild would probably create
>the spell even if it wasn't pre-made.  I'd imagine that guards would have
>a portable field generator of some sort as standard issue, especially if
>mages were concidered a threat in the area and local monies could easily
>support such a project...

Bingo.

>> >The guards have to be able to react quick enough to prevent
>> >the mage from casting, else the mage can get away.
>> 
>> Or they must be able to place a tracer on the mage so that their mages can
>> follow him.  Probably cheaper, hearder to detech (by the fleeing mage) and
>> provides for more interesting chases.
> 
>Ooh...I think this little item would be just a little to dangerous in
>PC's hands.  If the Mage had figured out the tracer method, he would be
>sure to remove it the next time (after earning himself another body most
>likely), and place it on his intended victim...unless the actual guard
>who witnessed the crime is the first to catch up with the victim (who has
>no reason to be running from the guards), the guards would just pounce on
>the victim, and finish the mages original crime.

Precisely.  All sorts of fun can result.  Tracers, multiple tracers, false
tracers, red herrings, anti-tracers, tracer deveivers, etc.  All the
wonderful glory of an arms race...  Fun stuff.  Why avoid it?

>> >Basically, I'd have to create a near-omniscient, near-omnipresent, and
>> >near-omnipotent police force protecting this anti-violence zone, but such
>> >a force would by its nature overrun and control the entire mud-world to
>> >impose its doctrine of non-violence everywhere.  While this could be an
>> >interesting twist to the mud's theme, its not what I'm looking for.
>> 
>> You can create in-game artificial limits to their scope.  First thought:
>> 
>>   The militia are omni-* as long as they and the event all occured within
>> XXX distance of a holy relic of the Great God GooGoo...
>> 
>And this relic would be the gods magic (security) blanket, no doubt.

Ohh, I dunno.  The Great Good GooGoo is already a pretty baroque chap (he
was the foundation of the original spoof/watcher model scenario).  He
hardly needs more colour.  Perhaps a pacifier?  Or a collection of toe
cheese?

>Wow...thanks for the ideas...you really got the juices flowing.  

Welcome.

>It looks
>like it'll boil down to whether or not I (as the guard coder) can stay a
>step ahead of the players.  But isn't that why we started down this road
>in the first place?

Yeppirs.  But we're having more fun with it now.

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




More information about the mud-dev-archive mailing list