[MUD-Dev] Neighborhood watch

[Brandon J. Rickman]

J C Lawrence wrote:
>  Take a piece of graph paper.
>  This is your "MUD World".  The graph on the paper represents the
>coordinate space of your world.

To make sure people don't get stuck on the very literal paper and
coins approach to the problem:

- If you can visualize the two dimensional solution, try using it
for a three (or more!) dimension problem.

- Allow the edges of the neighborhoods to be "open".  That is, an
object that lies on the exact edge of a neighborhood would _not_
be in the neighborhood.  While harder to visualize, this
is useful for code implementation (checking whether an object
is in the bounds of a neighborhood uses the cheaper < comparison
instead of <= or !> or < x+1...).

>Varying the diameter in this way makes the task of "deciding where to
>place the coins" all the more difficult.  Further as your objects can
>actually move about the world, a once sparsely populated neighborhood
>can easily turn into an incredibly heavily populated neighborhood when
>say a character carrying a very large inventory enters a room, or
>approaches another character with a similarly large inventory.

This depends on how you want to handle character inventory.  I had
to contrive the Shoehorn and the rabbits example to avoid being a
proponent of any particular approach to dealing with inventory.  A
critical issue is: How do you handle a sudden increase in the
number of objects in a neighborhood?  If a character with a large
inventory is considered one object it should make things a bit
easier, unless they decide to "drop all".

[Event sidebar: how many events is a "drop all"?  How could you
combine this:
Shoehorn drops a sword.
Shoehorn removes a rabbit pelt.
Shoehorn drops a rabbit pelt.
Shoehorn drops a rabbit pelt.
Shoehorn drops a rabbit pelt.
Shoehorn drops a sack.

Into something like:
Shoehorn drops a bunch of stuff.

but still propagate all six events?]

>Consider the case of a volcanoe in the middle of the desert.  The
>desert is pretty uniformly featureless and so contains very few
>objects, and thus almost no neighborhoods.  The volcanoe erupts. 
>Boom!  Everybody and everything within hundreds of mile should both
>hear and see this eruption.  Problem: The players in a small group
>near the volcanoe all lie within a small island of neighborhoods which
>are not connected to anything.  That small group of neighorhoods
>intersects *nothing* else.  They never see the volcano go "Boom!".

Oh, that's just silly.  You can't put a volcano in a desert.

Okay, let me try a magical hand waving argument: If this is truly a
featureless desert containing very few, or rather sparsely arranged,
objects, then there must be some place in the desert that is the
most uninteresting place to be.  That place in the middle of
everything, which means it is actually not so uninteresting after
all.  We just have to pretend there is an object there and
construct the appropriate neighborhoods and the problem is solved.

This is actually not as ridiculous as I'm making it out to be.
Putting the neighborhoods in meta-neighborhoods (an R* tree or
similar) and so on should prevent you from ever overlooking a
neighborhood when a big event is going down.

Before I could finish this reply...

On Sun, 29 Jun 1997 Nathan Yospe <yospe at hawaii.edu> said:

>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.

How well does this work for a large number of objects/players?  I
can't say I like concentrating on sensory capabilities as an
effective way of partitioning the space.  I would even go so far
to say I don't think object characteristics (objects being virtual
physical objects in this case) need to be considered _at all_ in
the partitioning of space.  Even wall and door objects!  But I 
don't have time to explain why I say this.  (I'd have to make
something up first.)

Perception is a character/client problem, one that tends to thwart
most optimization attempts.  My chosen problem is rooms, coordinate
systems, architecture if you will.

>I am wary of this... I have already begun a series of optimizations to
>allow linear or better collision detections, but I like the creation of
>neighborhoods on the basis of design, rather than arbritrary concerns. (A
>forest is a natural neighborhood, as is a glade within it... half a forest
>is not.) This may be influenced by my concentric neighborhoods approach.

The forest neighborhood and the glade neighborhood.  What about the
place between the two?  The mysterious intersection between 
[postmodernism warning] not-forest and not-glade?  That's where all
the action is, the character fleeing into the forest but still 
visible from the glade.  The edge of the path where Hobbits hide,
the bandits hiding behind trees for an ambush.  The troll blocking
the entrance to the bridge, a guard in front of a door.

All those vast regions of forest are filler, a place to hang out
between the encounters at the edges.  A pool of quicksand is a
natural neighborhood.  Does anything ever happen there?  No, things
happen at the edges, when someone starts to sink and tries to
escape.

>You are aware that I consider the trend toward complete seperation of
>server and behavior a negative one. I suppose I am a minority on this one,
>like the "levels" people on that issue, but there it is. I like having
>support for what I consider fundamental constructs inherent in the server.
>Locations, Physicality, and so forth... As such, I use my neighborhoods as
>the center, and having Physical manifestations within them is not a
>requirement. A physical object CANNOT, however, exist outside of a
>location.

I don't object to implementing behaviors within the server, so long
as there is reasonable access to change those server functions when
the implementation goes awry.  I've spent a lot of time programming
clever hacks to work around harebrained servers, energy that would
otherwise have been useful for completing some implementation.

I don't like server functions that pretend they know clever things
about the database.  E.g., the move() primitive in MOO that would try
to execute some piece of shit :accept method and/or :exitfunc and
:enterfunc.

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

I'm going out of town for several weeks.  I doubt I can keep up with
the volume of this list.  If you want to get my attention, _don't_
put RP or PK in the subject line.

- Brandon Rickman
ashes at zennet.com