[MUD-Dev] Re: Nested Coordinate spaces.

[Michael Hohensee]

Elis Pomales wrote:
> 
> 
> I've been thinking of using a b-trees with morton coded keys for my objects
> (one tree per "area") and a quad tree (or several) for area information (again
> per "area"). Though the biggest problem I currently see, for this and for the
> R*-Tree is in how you store the actual players? I mean players move around,
> thus requiring a delete and an insert... Sooo is this ideal? Am I thinking
> along the wrong track? I like R*Trees but have yet to find enough info on em
> (am trying to get a good book and spatial representations.)

I'd recommend representing the world (i.e. the space that objects (like
players) move around in) with your tree, and then having each space have
a list (or tree) of what is inside it and where it is.  Each object is
represented in the spaces' lists (or trees) as a point to that object,
and a set of coordinates.  Then, have the space containing the objects
be responsible for the manipulation of objects' locations.

The net effect of this is that you can skip traversing all the way down
a big tree for most local effects (i.e. the ones which stay within the
space object containing them), and everything is stored in memory simply
as itself, and a set of coordinates.  (you don't have to worry so much
about having one lone player in the third quadrant cutting the mud's
performance by 2/3.)  

It's essentially what the "Nested domain" thread is all about, but if
you're not going to do anything really wierd, like space warps, you
shouldn't have any problem coding it.

--
Michael Hohensee       michael at mainstream.net
http://www.geocities.com/SiliconValley/Heights/9025/
      Finger me for my PGP Public Key, or use: 
http://sparta.mainstream.net/michael/pgpkey.txt