[MUD-Dev] Re: Nested coorindate space model

Jason Goodwin wgoodwin at iquest.net
Sat Jun 6 12:20:23 New Zealand Standard Time 1998


At 06:40 PM 6/5/98 -0400, Michael Hohensee wrote:

>I think there's a slight conceptual barrier here.  There are two kinds
>of distances: Absolute distance, and Percieved distance.  The absolute
>distance is what you get if you calculate the distance based on
>coordinates alone.  When we look at the picture above, we are looking at
>it in terms of its absolute coordinates.

But what happens when things get very close to the translation layer?
For instance, let's assume Y is internally 100 by 100 units, and X
considers Y 1 by 1 units (thus a warping factor of 100, nothing like huge
numbers to test a system :)

A person is standing in Y, approximately 1 of Y's units from the border,
directly in the middle.  Now, let's say a stick 1 unit long is resting
directly adjacent to the border of Y in X such that the distance can be
considered 0.  To the observer, the stick is going to be extremely long
considering it stretches from one border to the next.  I can't see any
possible way around this using a scaled approach.  Things would just have
to suddenly shrink and expand upon crossing over as well as having a
distortion field at the border (Hmm, I _think_ it might be similar to
looking through one of those mirrors at a fun house.)

Actually, there is a way to get things to work slightly better if you
instead slowly change the warp factor from one region to the other,
thus the sudden distortion would go away (becoming slight distortion
amortized by distance :)  Only problem I can see is if the difference
in warp factors is great, and the region is small in the outer realm,
then the sudden changes in size are un-avoidable.

An example of this would be the realm of Sung Chiang from AD&D. At its
border, all you can see is a huge courtyard, with a small temple at its
center with brightly colored leaves surrounding it.  As you get closer,
the larger the temple becomes until you realize it's the size of a small
mountain, and the leaves surrounding it is a massive bazaar.  To properly
model it, the warp factor would have to slowly change as you approach its
center.


[JCL]
>> The other approach is to define constant sized translation
>> interfaces, the base concept being that a translation interface must
>> occupy the same dimensional units in both coordinate systems.

This would be the approach I think would work best if it's required that
the domains' scale is fixed across the domain.   Actually, this could
lead into two different types of interior domains.

Type 1, Scaled Spaces.  These would be as above.  The coordinate systems
would be scaled differently, and thus things would appear to shrink or
expand to an observer as it traveled between different spaces.  (whether
the scaling is gradual or sudden wouldn't matter too much.)  Sung Chiang's
realm and the dimension distortion spell from AD&D would best be modeled by
this system.

Type 2, Pocket Dimensions (lack of better term.)  These would use the same
coordinate scale as the outer domain, but would have different measurements.
On the outside, it's a 2.5 x 2.5 x 6 unit box, on the inside, it's a condo.
Access would have to be through portal's that take up the same units on
each side.  The Tardis and those pesky bags of holding would best be modeled
by this system. 

In both system's, it is up to the domain to define where the person is located
in the global units, as well as telling how far away something is percieved
across a boundary.  Of course, the calculations involved are reversed for both
spaces, in a scaled space, the person's absolute units are already known while
you have to calculate the perceived distance.  The inverse would be true of the
pocket dimension.  Personally, I see no conflict in providing both types of
spaces.

>> Except for the case when an object lies just other side of a
>> translation layer.
 
>Not if you've got the right formula! (which I don't, yet.. :)

But ye cannot defy the laws of physics :)





More information about the MUD-Dev mailing list