[MUD-Dev] Room-based vs. coordinate-based

[coder at ibm.net]

On 09/06/97 at 05:18 PM, "Brandon J. Rickman" <ashes at pc4.zennet.com>
said:

>To briefly cast aside the [more combat-oriented] concerns of
>coordinate systems...

>I think containers (or neighborhoods as my mathematical background
>would have me call them) are key to providing an interesting location
>oriented mud.  ...
 ...deletia...
>For any collection of N objects in space we want to create a
>collection of  <N neighborhoods each containing 1 to k (hmm,
>sqrt(N)?) objects.  ...
 ...deletia...

Absolutely bloomin' obvious.  Why didn't I see this?  Instead of
looking at the problem from the outside as a data management problem,
look at it from the inside as a locality problem.  

<bow>

Thanks.  I'll now go scrap a few thousand lines of proof-of-concept
code and head back to the deisgning board.  

<deeper bow>

I haven't had this much fun with this sorta junk since I last bit into
non-numerical systems and group theory.

The other really nice thing about this is that the set of localities
_can_ be viewed as a sort of inverse R*-Tree with the only real
difference being that with your hard max-content lists that you'll
have no groupings of localities.  Hurm.  maybe I'll save some of that
code.  

Lessee here.  Keep the base max size for a locality as defined by the
number of its contents.  Also allow a locality to contain other
localities.  Require that a locality contain nodes of only one type:
either base objects, or localities.  Define that the max dimensional
size of a locality is dependant on its "height" on the tree.  Voila! 
An instant tree structure built from the roots up to a single trunk
(with minor stretching of the proximity laws).

I like this.  It has all the flavour of my dynamic creation of R*-Tree
rectangles but is a lot more efficient.  

>This is where we break from
>the  very very very very very bad practice of MOO, where object
>containment was built into the server.  

Cool, ColdX, Interlude, and LP do this -- its probably the first thing
I changed as a design principle when I looked at them as models.

>(One might say that this
>allowed for a certain amount of optimization on the server's part,
>which hints that any new implementation might also benefit from being
>hard coded into the server.  I couldn't say if this would make any
>sense with a distributed database...)

Move from Tiny-*'s DB centric model to an LP-flavoured (if not style)
persistant store and the representation becomes almost native to the
data.  As for hard-coding it.  Its doable, and considering the
production rate of calculations, is probably worth it.

>So now we have <N neighborhoods scattered on a plane (or line, space,
>n-space, whatever).  An object propagating an event only has to
>propagate in its  neighborhoods (*) (which at worst would be _all_ of
>them).  

It would seem the rare case where an event would not be propagated to
all neighborhoods of an object.

>((*) It may also need to propagate in neighboring neighborhoods...)

Actually that level of removal could be many deep.  It may well need
to propagate to its neighbors' neighbor's neighbor's...neighborhoods. 
Consider the case of a long set of neighborhoods (a long passage
containing a line of many thousands of ants).  A message at one end of
the tube should likely propagate to the other end.  


>After trick #1:
>#1[Shoehorn, 1, 2, 3, 4, 5, 6, 7, 8, rabbit1] - #2[7, 8, 9, 10, 11,
>12]

>Only the folks in Shoehorn's group see the next three tricks...

Which means that 7 and 8 see the trick despite being at the corner
with 9, thru 12 who don't see the trick.  There's a non-implicit data
loss there.

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