<!-- MHonArc v2.4.4 -->
<!--X-Subject: Re: [MUD-Dev] Room-based vs. coordinate-based -->
<!--X-From-R13: @nguna Kbfcr <lbfcrNunjnvv.rqh> -->
<!--X-Date: from babe.globecomm.net [207.51.48.8] by in11.ibm.net id 867211666.48414-1 Wed Jun 25 04:07:46 1997 CUT -->
<!--X-Message-Id: Pine.GSO.3.95q.970624073355.24811A-100000@uhunix2 -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: 33b87247.601577402@neptune -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, Re: [MUD-Dev] Room-based vs. coordinate-based</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:yospe#hawaii,edu">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg01486.html">Previous</a>
| <a href="msg01488.html">Next</a>
]
Thread:
[ <a href="msg01474.html">Previous</a>
| <a href="msg01618.html">Next</a>
]
Index:
[ <A HREF="author.html#01487">Author</A>
| <A HREF="#01487">Date</A>
| <A HREF="thread.html#01487">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>Re: [MUD-Dev] Room-based vs. coordinate-based</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#null,net">mud-dev#null,net</A></LI>
<LI><em>Subject</em>: Re: [MUD-Dev] Room-based vs. coordinate-based</LI>
<LI><em>From</em>: Nathan Yospe <<A HREF="mailto:yospe#hawaii,edu">yospe#hawaii,edu</A>></LI>
<LI><em>Date</em>: Tue, 24 Jun 1997 18:07:11 -1000</LI>
<LI><em>Reply-To</em>: Nathan Yospe <<A HREF="mailto:yospe#hawaii,edu">yospe#hawaii,edu</A>></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
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#hawaii,edu
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="01474" HREF="msg01474.html">Re: [MUD-Dev] Room-based vs. coordinate-based</A></STRONG>
<UL><LI><EM>From:</EM> alexo#bigfoot,com (Alex Oren)</LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg01486.html">Re: [MUD-Dev] Alright... IF your gonan do DESIESE...</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg01488.html">Re: [MUD-Dev] Rumours</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg01474.html">Re: [MUD-Dev] Room-based vs. coordinate-based</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg01618.html">Re: [MUD-Dev] Room-based vs. coordinate-based</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#01487"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#01487"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>Re: [MUD-Dev] Room-based vs. coordinate-based</STRONG>, <EM>(continued)</EM>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<LI><strong><A NAME="01458" HREF="msg01458.html">Re: [MUD-Dev] Room-based vs. coordinate-based</A></strong>,
Shawn Halpenny <a href="mailto:malachai#iname,com">malachai#iname,com</a>, Mon 23 Jun 1997, 23:52 GMT
<LI><strong><A NAME="01619" HREF="msg01619.html">Re: [MUD-Dev] Room-based vs. coordinate-based</A></strong>,
clawrenc <a href="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</a>, Tue 01 Jul 1997, 06:45 GMT
</LI>
</LI>
<LI><strong><A NAME="01465" HREF="msg01465.html">Re: [MUD-Dev] Room-based vs. coordinate-based</A></strong>,
Nathan Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Tue 24 Jun 1997, 01:33 GMT
<LI><strong><A NAME="01474" HREF="msg01474.html">Re: [MUD-Dev] Room-based vs. coordinate-based</A></strong>,
Alex Oren <a href="mailto:alexo#bigfoot,com">alexo#bigfoot,com</a>, Tue 24 Jun 1997, 14:09 GMT
<LI><strong><A NAME="01487" HREF="msg01487.html">Re: [MUD-Dev] Room-based vs. coordinate-based</A></strong>,
Nathan Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Wed 25 Jun 1997, 11:07 GMT
</LI>
</LI>
</LI>
<LI><strong><A NAME="01618" HREF="msg01618.html">Re: [MUD-Dev] Room-based vs. coordinate-based</A></strong>,
clawrenc <a href="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</a>, Tue 01 Jul 1997, 06:06 GMT
</LI>
</ul>
<LI><strong><A NAME="01262" HREF="msg01262.html">Re: [MUD-Dev] Room-based vs. coordinate-based</A></strong>,
Alex Oren <a href="mailto:alexo#bigfoot,com">alexo#bigfoot,com</a>, Mon 09 Jun 1997, 22:05 GMT
<UL>
<LI><strong><A NAME="01263" HREF="msg01263.html">Re: [MUD-Dev] Room-based vs. coordinate-based</A></strong>,
Shawn Halpenny <a href="mailto:malachai#iname,com">malachai#iname,com</a>, Sun 11 Jan 1970, 02:46 GMT
</LI>
</UL>
</LI>
</ul>
</ul>
</ul>
</ul>
</ul>
</ul>
</ul>
<LI><strong><A NAME="00176" HREF="msg00176.html">Re: Issues from the digests and Wout's list</A></strong>,
clawrenc <a href="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</a>, Tue 22 Apr 1997, 06:53 GMT
</LI>
</ul>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>