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

Derrick Jones gunther at online1.magnus1.com
Thu Oct 30 01:56:55 CET 1997


On Wed, 29 Oct 1997 coder at ibm.net wrote:

> 
> 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:
[snip good description of a worm-hole]
> 
> 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.  

My definition is that the two places aren't one, but infinitely close;
separated by the portal (worm-hole if you will) which the mage steps
through.  The difference being that temperature, luminosity, and (most
interestingly) pressure gradients go off the scale (opening a portal into
a much lower pressure (air into vacuum or underwater into air) creates all
sorts of fun).  But being that they are definitions, discussing the
validity of each will quickly become circular.
Also, having the portal remain between both places allows each location to
retain its 'uniqueness', so that objects don't spontaneously switch from
one place to another during the duration of the spell.  This doesn't mean
the things can't be 'pushed' through the portal (or dragged by a pressure
gradient), or that the caster can't enter under his/her(English needs a
neuter pronoun other than 'it') own power.

Yet the problem of tracability remains.  The protals themselves can be
detected, as they exist (for Trekish worm-holes its the quantum
fluctuations), but the pursuers can't link entrance and exit portals as
the path between them is non-existant. Should there be a distinction?  If
portals are one-way, then I guess the 'in' and 'out' have their own unique
signatures, but a two-way portal (eww nasty spell) would by necessity be
identical.  Although if you gear magic to absorb from its surroundings,
then one end of the portal (enter) would most likely show the drop in
ambient energies.

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

Wouldn't this lead to Universal affinity, providing that teleporting
becomes a fairly common practice?  If large, different areas begin to mesh
to be in 'affinity' with each other, then you will quickly get the
majority of he popular spots being a soup of each others identity.  For
example, say a swamp and desert were 'linked' by a spell, then the swamp
with a snowy mountaincap.  The mountaincap would gain some affinity with
the desert, even though they were never directly connected.  Thus, after a
few hundred jumps, it would become impossible to tell the original source
of an introduced affinity.  However, if some mage teleports into town from
his/her secret hideaway (assumed to be 'off the beaten path' and therefore
retaining much of its orignal location signature), the entire town may be
able to detect the shift created by the portal.  (There is danger in the
air.)

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

As does, mine, provided that you are quick enough to follow the mage
through the portal before it closes.  This isn't an easy task, as the
spell its most personal form (teleport self) negates itself when the
caster passes through it.  We're then back to looking for signatures left
by exit portals, which are all identical to each other (Being that they
dissipate fully in a few minutes, there are in most probability only a few
exit portal signatures at any given time.)

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

Nifty.  The same logic could be used in my system.  Th mage hires a few
accomplices to teleport about randomly as the mage is committing the
crime.  When it comes time to escape, the guards have an unusally large
number of portals to investigate, thus spreading their forces thin to the
point where they can be ambushed, or eluded easily.  Also,  the
accomplices can stick around the exit-portals and give faulty information
to the guards, or even make it seem that the mage did in fact use the
wrong portal (dropping a hat simular to the one worn by the mage, etc).

> >> >The guards have to be able to react quick enough to prevent
> >> >the mage from casting, else the mage can get away.
To correct this, the guards have to prevent the mage from casting, then
stepping into the protal...This does give them a _little_ more time to
react, although not much, as the portal may appear directly in front of
the mage.

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

This is more feasible once I added the time for the mage to step into the
protal.  The guards will recognize a portal, and know that the mage is
most likely going to try to disappear into it, fire/throw a tracer at the
mage, and wala, they know where the mage is going.  In a post-modern
setting, guards could throw grenade-like objects through the portal, then
the mage steps through, the portal closes, and BOOM!  Tracing the mage
would be as easy as following the explosions, although it probably won't
be all that fruitful as the mage was blown to bits once the portal closed.
 
> > 
> >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?
> 
Mostly because the players would be dying in droves right from the start.
Mainly at each others hands for the sake of killing each other.  I'm
aiming to make PK a little more difficult to disourage rampant
player-killing.  That's the whole point of the 'safe' zones. I can't see
players handing such devices responsively if they are introduced at the
start.  Perhaps once the mud is established and I want to add a little
fire to the game I could introduce them...

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

Yes we are.  And I'm getting one hell of a head start.

Gunther




More information about the mud-dev-archive mailing list