[MUD-Dev] Neighborhood watch

[clawrenc at cup.hp.com]

In <Pine.GSO.3.95q.970628202750.401B-100000 at uhunix2>, on 06/29/97 
   at 04:44 PM, Nathan Yospe <yospe at hawaii.edu> said:

>On Sat, 28 Jun 1997 clawrenc at cup.hp.com wrote:

>:Some time ago I promised a summary of the neighborhoods concept.  I've
>:encluded the original post from Brandon on the subject below.
...deletia...

>Option 2... variable size... here we are assuming density as a
>reasonable criteria for neighborhoods. Personally, I disagree, but
>I'll get to that later. Accepting density, we have two options: fluid
>neighborhoods and semistatic neghborhoods. The fluid neighborhood
>changes every time a new object shows up, or leaves. The semistatic
>neighborhood is generated to the mean neighborhood size at
>initialization, and each neighborhood handles fissioning and requests
>for fusion (and possible refission) on the basis of passing a
>threshhold. Example: Mean (optimal population) of 30 items. Maximum
>of 100, minimum of 10. The following neighborhoods currently exist:

>A  B C    D  E
>  F    G      H
>I    J        K
>   L   M  N   O

>Each has a population of 30, and occupies the space halfway to the
>nearest neighbor in each direction. 

How do you determine the placement and size of neighborhoods to
guarantee optimal population?

>This is fine, until 21 each from
>A and B move into F, as 29 new objects are generated in F. F fissions
>into two new entities, and A and B each request mergence with F (not
>yet knowing about the two new neighbors), and each other, and B from
>C as well. A and B should negotiate to merge, if this is written
>properly, as they fall well within range merged (eighteen.)

Depending on component object placement, it would also seem valid for
A and F`1 to merge, as well as B and F`2.  Order of evaluation is
pretty dicey here in determining the optimal result.  Got a
suggestion?  It essentially seems to be an N+! simultaneous equation
where N has the possibility of incrementing out across the entire land
and so needs to be constrained.

>:Most of the discussion which has occurred on this neighborhood concept
>:has centered about two points how to propagate an event across
>:neighborhoods?

>:The obvious answer is for an event to propogate to the neighborhood it
>:occurs in, and from there to all neighborhoods it intersects until it
>:reaches a neighborhood which is out of range.  This works quite well
>:for the simple case:

>:  #############
>:  ##aaaaaaaaa##
>:  ##aaaaaaaaa##
>:  ##aaaaaaaaa##  # is a neighborhhod.
>:  ##aaaaaaaaa##  E is where the event originated.
>:  ##aaaaEaaaa##  a are the neighborhoods the event propagated to.
>:  ##aaaaaaaaa##
>:  ##aaaaaaaaa##
>:  ##aaaaaaaaa##
>:  ##aaaaaaaaa##
>:  #############

>:The problem is that this requires a very regular arrangement of
>:neighborhoods (cf quad-tree, oct-tree).  Given the random placement of
>:dots on the original graph paper as above, the resultant placement of
>:neighborhoods will also be random.  Additionally there is not
>:necessity for any part of the graph paper not containing any objects
>:to actually be a part of any neighborhood.

>:Now, given the same event, consider the case of:

>:  #############
>:  ##aaaaa  xx##
>:  ##aaaaa  xx##
>:  ##aaaaa  xx##  # is a neighborhhod.
>:  ##aaaaa  xx##  E is where the event originated.
>:  ##aaaaE  xx##  a are the neighborhoods the event propagated to.
>:  ##   aa  xx##    propagated to.
>:  ##       xx##  x are neighborhoods the event DIDN'T propagate to.
>:  ##xxxxxxxxx##  and the whitespace areas contain NO neighborhoods.
>:  ##xxxxxxxxx##
>:  #############

>:The problem here is that the efvent can't reach the 'x' neighborhoods
>:as they don't intersect any neighborhoods which are within range of
>:the event, __BUT__ they themselves are within range of the event.  The
>:lack of the "joining" neighborhood prevents them from receiving the
>:event.  THink this this isn't a problem?

>This assumes fixed size neighborhoods, which does not, from
>experience, mix well with questionable existancce of neighborhoods.
>Now, I DO use a similar concept for the GURU project, but...

>  1 2 3 4 5 6 7 8 9 0
>1  ..........
>2  ..oooooo..
>3  ..ooXXoo......
>4  ..oooooooooo..
>5  ......ooYYoo..
>6      ..oooooo..
>7      ..........
>8

>The above shows the range of a character's passive sensory
>capabilities. The range of visability is the current node (fixed
>size) plus the neighboring node (reduced priority) and the
>neighboring to that (minimum priority) Within each region, filters
>are applied, and priority is ranked. A character is only given
>detailed info on things over a certain priority, and in textform,
>only a certain number of info units. Now... the concept of the
>project is such that any two regions that intersect, as above, are
>controlled by a single thread (sliced threads) and fusion and fission
>of threads and regions is commonplace. This puts the burden of these
>partitions on player units, rather than generic objects. A larger
>region is allocated more resources. This seems, overall, more
>productive than variable size neighborhoods.

This is only scalable if your number of recipient (listening?) objects
is small.  Given that you deactivate all portions of your world not
currently inhabited by live players, this is reasonable.  Given a
fully active world where everything is alive all the time, I see
problems.

>This is good... I was missing this sort of hard core discussion.

Agreed.  This is the aspect of the old list that I've been missing
most.  (Yes, I know many of you were also put off by that aspect)

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...