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

[coder at ibm.net]

On 02/11/97 at 09:43 AM, Derrick Jones <gunther at online1.magnus1.com> said:

>On Sat, 1 Nov 1997 coder at ibm.net wrote:
>> On 29/10/97 at 11:02 PM, Derrick Jones <gunther at online1.magnus1.com> said:
>> >On Wed, 29 Oct 1997 coder at ibm.net wrote:

>> Yup, there are all sorts of logical conundrums under there.  I attempt to
>> side step most of them by defining that while the two locations now share
>> the same space, their coordinate systems are still logically continuous
>> with their original systems.  The result is that by default, event tho
>> there are objects from two different locations sharing the same space,
>> objects from different locations won't affect other objects from other
>> locations in the same space.
> 
>Okay..now I see it.  For some reason I pictured the exit area being
>superimposed upon the reality of the entrance.  The two places would then
>separate, taking with it the mage and some of the local 'flavor' of the
>entrance, (that's what I thought you meant by 'affinity') and leaving
>some of the exit's 'flavor' at the entrance location.  Thus my argument
>for Universal Affinity...Oh well.

Actually your "flavour" bit is almost exactly right, the bit about the
superimposition is off.

>> Hurm.  Another side piece I hadn't really thought of adding an explanation
>> for, is that the new affinity the two locations have for each other is
>> unique in character.  Its not a question of a generic affinity stat which
>> every location or location relation possesses to some extent, but that
>> there are uniquely coded affinity values between points which can be
>> detected on the basis of that affinity signature.  Helpfully, that
>> signature is partially a product of (flavoured by?) the creator of the
>> affinity (ie the one who teleported).

>Yes, in your system the affinity can be described as an arrow pointing to
>(or from) the other location.  

Its bi-directional.

>Just out of curiosity, how do you parse
>stepping across such a connection?  

For the caster it is atomic.  He initiates the teleport spell, the spaces
are meged, the emerge, and he's in the new location.  There's no
interaction required or even possible,

For others, its a little more interesting.  

>Mine is easy since there is a
>physical portal in the area, 'enter portal' works, or just 'enter' if the
>portal is the most/only obvious entrance.  

I don't have a portal, or any other concept of a localised, locatable,
isolatable entity which can be entered, avoided, etc.  Or to put it
simply, teleporting does not open a door which may then be traversed. 
Teleporting instead transports the teleporter with no other motion
required.  Push the button.  Blink!  You are somewhere else.  Push the
button again.  Blink!  You are somewhere else.

>With yours, it seems that you
>give travelling in a certain direction two possible outcomes(going north
>down road #1, or going north down road #2.).  Is there a special verb
>such as 'cross' to differentiate between the two?

There are really two parts here:

  A mage may teleport, which creates the relation, the mage elects to
belong to the other side of the merge, and the warp instantly deconstructs
leaving the mage on the other side.  The result is that nobody else can
follow thru the same "portal" (if I had such a concept), or even
participate in the process.  Its atomic.  For an outside watching a
teleporting mage, he just seems to vanish.  Pop!  There's no activity
involved in vanishing, he merely vanishes.

  A mage may create a more permanent warp/mapping, thru which others can
funnel or pass objects.  Again, this is not a portal type of construct. 
Instead it is more analagous to the Unix stdin/stdout file handle model. 
A character, or even an object has a defalt coordinate system which it is
a member of, and has a location within.  Given the presence of a warp, the
object may elect to swap its current coordinate system mapping for the
other one that shares his current location.  This is analagous to:

  fp = dup (stdin);
  close (stdin);
  open (new_location);  // occupies the stdin slot

done atomically.

Were the warp to be displayed graphically there would be the image of the
current location, and then overlaid on that, ghosted, would be the image
of the other location that is currently warped there.  The image with the
sharpest display would be the location in the current default coordinate
system.  The lesser images (presuming multiple warps, which are possible),
would be the other possible mappings from this point.

The character or object then merely elects which of the multiple
coordinate systems he wishes to be a member of.  He instantly vanishes
from his old location, and appears in the new.

At the command level I was going to use a "warp" command which iterated
thru the current set of possible coordinate systems.  I don't like this
solution, but it works for now.  I'd prefer some sort of preview method
which allowed the multiple possibilities to be scanned, viewed, and
causitively selected from.  Not sure how to do that tho.

Note:  There are expenses to teleporting or warping.  Consider the case of
two locations, one atop a cliff, and one at the bottom, which are then
warped together.  Were this to be left alone, and object warped to the top
wouldhave gained a massive amount of potential energy for no cost. 
Conversely, an object coming down would have lost the same without using
it.

As I run a resource based system I cabn't have this.  Thus I require that
the resource imbalance be made up in some way such that the balance is
maintained.  If you can't make up the difference, you can't teleport.  Its
part of the cost of teleporting.  

Thus a mage teleporting to a lower resource position might leave behind
him a very bright flash of light and heat as he expends the energy needed
to achieve the lower resource level.  To keep this simple however I've
just extended this into the mappings of particle type translations.  As
such a mage merely consumes of creates enough particles of the appropriate
type to balance the equation.

>> >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).
>> 
>> Precisely.  Bingo.
>
>Still, its going to be a tricky implimentation...probably take me a month
>to program the guards from scratch (although I'll get some cool reusable
>subroutines worked out in the process).  

Yeah, that's always the problem with neat and flexible systems.  They grow
on you, literally and figuratively, and in both senses.

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