# [MUD-Dev] Re: Nested coorindate space model

Ling K.L.Lo-94 at student.lboro.ac.uk
Sat May 30 16:37:37 New Zealand Standard Time 1998

```On Tue, 26 May 1998, J C Lawrence wrote:
> On Thu, 21 May 1998 18:03:03 +0100 (BST)
> Ling <K.L.Lo-94 at student.lboro.ac.uk> wrote:
>
> > Or perhaps something even more bizarre, like transformations to a Z
> > plane:
>
> >  > l
> >  There's a huge building 100m to the right.
> >  > turn right
> >  There's a huge building 100m infront of you.
> >  > walk
> >  [pause] There's a huge building 30m to your left.
> >  > walk towards building
> >  [pause]
> >  l
> >  There's a huge building 150m to your right.
>
> > A modern day maze.  (eek, bad game design!)
>
> It can certainly do things like the Blue Grass and Mobius Row, which
> are not entirely alien to your above concept.  Both are in essence
> directionally sensitive mazes and (in this system) reliant on careful
> placement of directionally sensitive invisible teleports to arrange
> the directional and motion order sensitivity.

I was thinking of something like a conformal transform which is
pretty much what you're intending:

Domain is perceived in the w plane.

w is defined by:  w = u + v
where:  u = x^2*y^2
v = 2xy

Substitute other formulae for u and v as you see fit.  Just avoid 1/xy
or anything else that would form a pole.

Players walk around in x, y as usual but when they do a look, they see
the w plane.  Alternative, players looking into the domain perceive the
w-plane.  [You see Bubba walking backwards into a building...]

> Defining a new coordinate system within the domain has proven
> exceptionally useful, tho the translations to the external world can
> be awkward.  While I haven't needed to make the definition yet, pretty
> soon I'm going to have decide if:
>
>   Given a domain with specified external dimensions of X (say 1x1x1),
> but which defines and internal coordinate system and thus has internal
> dimensions of Y (say 100x100x100), what happens at the translation
> points between the domains?  Is scaling employed such that objects
> effectively "shrink" to 1,000,000'th of their actual size when they
> enter the nested domain, or are matched scale "windows" defined which
> support the interface translations?
>
> The TARDIS would seem to indicate the latter.

I think so too, scaling would be horrid.  A builder wanting to mimick
Alice in Wonderland's scaling feats could stick in code for that kinda
thing...  Then again, given that there is an interface between domains
that converts objects, it oughta be pretty transparent to the players.
Bubba lobbing a stick into the TARDIS should still see a stick entering
the TARDIS, not a tree.  Conversely, Boffo inside the TARDIS shouldn't see
a twig coming in turning into a stick.

> > How are overlapping domains resolved?
>
> Its transparent and utterly ignorable.  A domain defines a private
> coordinate space.  If you don't epxressly define a new coordinate
> system it merely defaults to inheriting its parent's.  Overlapping
> domains thus don't actually overlap -- they don't overlap in the
> coordinate space defined __within__ the domain.  They may however
> overlap in their mappings to their parent's domain.
>
> As those mappings are only every of concern for the translation points
> (where the domains can be exited or entered), that *really* doesn't
> matter any more.  As long as they're consistent within their internal
> system, and as long as the parent system is consistent within it self
> (but not counting its child domains), everything works.

Cool, deadly confusing.  When I visit Murkle, I shall build myself a
cubby hole and hide.

|    Ling Lo of Remora (Top Banana)
_O_O_  Elec Eng Dept, Loughborough University, UK.     kllo at iee.org

```