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

[Huibai]

I've not done any coordinate-based work yet...
let me take a stab at it with theories, and anyone with some
experience please let me know what gets too cost-ineffective!
I'm still very 'room' oriented, but you could just replace 'room'
with 'square' or some such, to know what I mean...

: From: Alex Oren <alexo at bigfoot.com>
: } >How do you handle cross-room actions?

I'm going to cut & paste so I can explain algorithms first,
so I beg your forgiveness, Alex and Jeff :)

: } >What algorithms do you use? 
: I meant data structures to represent spatial relationships
: and algorithms to compute message recipients.

Axiom: Each room exit has boolean Seethru which stores
  whether or not you get line-of-sight in that one direction.
also: Each exit can calculate its coordinate-difference 
  (and thus distance) from the next room.

              Examples (from below) :
     Alfred's east exit has Seethru = true;
     Bubba's west exit has Seethru = true;
     Bubba's east exit has Seethru = false;
     Calvin's west exit has Seethru = true;

:   |  [A]          Grassland          [B]  |  [C]  Forest  |   / \

Correlative algorithms: 
1. this_room.SightRange(int depth) returns a mapping of rooms
    directly visible from here (shoots a line through every exit in
    their respective direction, recursively until Seethru is false).
   Depth is Optional Argument for non-line-of-sight cases.
2. this_room.SightedObjs() returns a mapping of objects from
    the room inventories of this_room.SightRange(), indexed by
    the direction they came from.
3. this_room.SightedLivings() returns a subset of this_room's
   SightedObjs() which of course is just those PCs and NPCs.

throw in recursive function VoiceRange(int sound) that returns
a list of all rooms within 'sound' range (that distance deep).
then base VoicedLivings(int s) as a subset of that.  can you tell
i like recursion?  first you swear, then swear again and again...
pretty soon you realize you're recursing... ;) anyway:

: How will the program handle the following scenarios:
: * Bubba sees Alfred ("in the distance") but not Calvin.

{print SightedObjs by index and value}
West: Alfred
East: nothing
{change up the storage for 'nearby','in the distance' etc}

: * Bubba says "hi".  Calvin hears him but Alfred does not.

{all VoicedLivings(40) get to Hear("Bubba says 'hi'\n"),
 assuming 40 is a good conversational distance away }

: * Bubba screams "H-E-L-P".  Calvin and Alfred both hear him.

{VoicedLivings(400) gets to Hear it}

: * Calvin shoots an arrow to the west, which arches over Bubba
:   and accidently hits Alfred.

{arrow flies recursively line-of-sight, getting a better to-hit chance
 against its target but still getting a slight to-hit chance on anyone
 who happens to be along its path.  destroyed by Seethru=false}

: * Calvin walks west.
:   Bubba sees a message "Calvin arrives ...".  Alfred does not.

{new_room.SightedLivings(40) gets to see it happen - still a
 decent conversation-distance that might notice the trivial event}

In a coord-based system, there's going to be some absolutely
tasty mathematics done in one place (Room Exits, I think most
would choose) and then everything else depends on the speed
of those formulas.  To get max efficiency, you might not want
to calculate the entire list of rooms and objects available in all
directions recursively each time you need the info - store it if
your situation demands these calls to be that constant.  The
direction of a room exit might also have to be stored integrally,
so my [juicy] VoiceRange could get a proper reading from the
rooms deeper than a squares away, with updated distances for
each deeper square and without checking rooms already done.

fortunately for me I'm not trying a coord-based right now.  I do
however use the Seethru construct, which works just fine with
a room-based system.  I am still interested in knowing just how
efficient you (need to be/can get) with the intensive coord-calc
calls.

-John (ashen at pixi.com)