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

[Nathan Yospe]

On Mon, 23 Jun 1997, Alex Oren wrote:

:Nathan wrote:
:
:} :How would I implement the equivalent of room-spoofs in a coordinate-based
:} :setting?
:} 
:} Nodes of interaction - transparent sublocales with their own coordinate
:} systems, joined by message/information/object passing barriers. Just spoof
:} a node. And have your builders place nodes in terms of reasonable
:} boundaries.
:} 
:} If you need more, I have a 12 page design document on nodes and
:} boundaries.
:
:Yes, please post it here.

Whoo, boy. How about a truncated version?

  II     Locations
    A]   The Node
        - Nodes are the centerpoint of a Location. They define the core of
        each Location's coordinate system, conceptually. In practice, the
        Node is similar to the room construct of an LP, Tiny, or Diku. It
        contains a generic list of all objects contained by the Location,
        as well as a pointer to the Coordinate object of each Physical
        object. Any relocation of a Physical object will check it with the
        Node before scheduling, and, as the Node runs a local Event queue,
        it can also be safely awarded posession of the Event thread socket

(Note: Event thread sockets are detailed separately, and are too complex
 to go into here. Suffice to say that Events are executed by threads tied
 to a Node. The threads themselves are drawn from a pool.)

        without worry about concurency. The standard rules regarding
        thread execution priority apply. See below for more details. The
        node itself is subservient to the Location, and cannot be
        inherited.

      i.  Node bounds:
          Each node has a defined boundary, at which point, continued
          motion effort by a physical object (see momentum) will be
          transfered to a Boundary object, if present, or terminated, with
          prejudice, if specified as a discreet boundary (note: location
          MUST provide a layer of solid matter before a discreet boundary.
          Invisable, indestrucatable, opaque walls are a BAD thing.) or
          wrapped to the specified coordinates within the same region if
          specified as a generic boundary. (most useful for regions
          measurable in large numbers of square kilometers, where the wrap
          point on each coordinate axis is about two kilometers behind the
          boundary line.) The Room class predefines Boundary objects on
          all sides, with open spaces in the boundaries optional. Default
          construction of the Boundary is collapsed matter. This should
          ALWAYS be changed. Collapsed matter is completely
          indestructable, even under the influence of antimatter, which is
          not appropriate for a room. Default thickness of these
          Boundaries is on discreet unit (one cm, in the case of 
          Singularity 2) and this should be changed if the wall is meant
          to be inpenatrable. A defined thickness of -1 yields an infinite
          wall of whatever the choice material is. Excepting planetbuster
          strength damage, which would delete the area entire, this should
          yield satisfactory results, while still allowing the odd plasma
          torch marks in said wall. The Field class defines NO Boundary
          objects whatsoever. Note that this results in there being no way
          for the player to know if they have been transfered between two
          nodes.
      ii. Objects "on" a Node
          While an object resides in a given Location, they are subject to
          treatment as a local object by that Location's Nodes, as well as
          the parent Nodes. For example:
            The "Ruby Pen" is in the pocket of the shirt worn by "Joe the
            Nerd", who is standing in a shack in the middle of the "Plain
            Plains of Plainness" on the planet "Yawn", somewhere in the
            universe.   There are five nodes involved here. The first is
            the global node, which tracks the coordinates of Yawn, which
            tracks the plains, which track that shack, which tracks Joe's 
            body, which tracks the shirt, which contains the pocket (it
            doesn't actually bother with real coordinates. The pocket is
            somewhere on the shirt. Within the pocket (again, no real
            coordinate tracking) is the pen. Were someone to look for the
            pen, while in the plains, a check would go to the shack, and
            be rejected on the basis of visability. Within the shack, an
            eventual query would reach the pocket. If the pen was sticking
            out (likely) the searcher would be informed that the pen was
            in Joe's pocket. Any conditions specific to the plains will be
            applied to anything within the shack, or the pocket, unless
            screened by the Boundaries. Rain, for example, would be 
            rejected.
      iii. Crossing nodes
          Boundaries allow a Location to transfer an object, or
          information, or pass a message to the neighboring Location's
          Node. When a Node needs to communivcate with its neighbors, it
          calls on the Boundary. Occasionally, a Boundary might be
          overloaded to be one-way, or even inpenetrably thick. In these
          special cases, a Boundary only need know one side, or none.
          Normally, a boundary maintains two discreet channels, one for
          each direction. Collision within a boundary is not permitted. A
          boundary will also contain information about a (normally two
          sided) object, if applicable... the wall. If not applicable, the
          boundary has no in-game representation, as it transparently
          passes everything that is handed to it. If a wall is present, it
          can be destroyed. This is not preventable. It can be
          discouraged, but ultimately, an entire room could be destroyed,
          resulting in an orphaned node sitting out in the open. The
          showMe() function should not be overloaded by something that
          does not accomodate this possibility.

*whew* That is enough of that. The point is, it retains advantages of
rooms (spoofability, discreet localities for events) with all of the
advantages of coordinate systems. Combat can occur without hassle across
two nodes... though there is a possibility of "passing in flight" if one
thread lags. This could result in things like

> Shoot arrow at Thag
You send the arrow off toward Thag.
 ... wait ...
Thag runs off and hides behind some trees.
Your arrow thunks into the ground where Thag stood mere seconds ago.

This is, however, desirable, over things like having Thag get hit before
he recieves the message about you shooting at him. (The message gets
queued, before the arrow itself, in the order recieved.)

   __    _   __  _   _   ,  ,  , ,  
  /_  / / ) /_  /_) / ) /| /| / /\            First Light of a Nova Dawn
 /   / / \ /_  /_) / \ /-|/ |/ /_/            Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yospe at hawaii.edu