1997Q2/
<!-- MHonArc v2.4.4 -->
<!--X-Subject: Re: [MUD&#45;Dev]  Room&#45;based vs. coordinate&#45;based -->
<!--X-From-R13: "Penaqba X. Dvpxzna" <nfurfNcp4.mraarg.pbz> -->
<!--X-Date: from babe.globecomm.net [207.51.48.8] by in1.ibm.net id 867631250.20734&#45;1 Mon Jun 30 00:40:50 1997 CUT -->
<!--X-Message-Id: 199706300040.RAA09377#pc4,zennet.com -->
<!--X-Content-Type: text/plain -->
<!--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:ashes#pc4,zennet.com">
</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>
[&nbsp;<a href="../">Other Periods</a>
&nbsp;|&nbsp;<a href="../../">Other mailing lists</a>
&nbsp;|&nbsp;<a href="/search.php3">Search</a>
&nbsp;]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->

Date:&nbsp;
[&nbsp;<a href="msg01590.html">Previous</a>
&nbsp;|&nbsp;<a href="msg01592.html">Next</a>
&nbsp;]
&nbsp;&nbsp;&nbsp;&nbsp;
Thread:&nbsp;
[&nbsp;<a href="msg01536.html">Previous</a>
&nbsp;|&nbsp;<a href="msg01137.html">Next</a>
&nbsp;]
&nbsp;&nbsp;&nbsp;&nbsp;
Index:&nbsp;
[&nbsp;<A HREF="author.html#01591">Author</A>
&nbsp;|&nbsp;<A HREF="#01591">Date</A>
&nbsp;|&nbsp;<A HREF="thread.html#01591">Thread</A>
&nbsp;]

<!--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>: "Brandon J. Rickman" &lt;<A HREF="mailto:ashes#pc4,zennet.com">ashes#pc4,zennet.com</A>&gt;</LI>
<LI><em>Date</em>: Sun, 29 Jun 1997 17:40:50 -0700</LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
On Thu, 26 Jun 1997, Shawn Halpenny &lt;malachai#iname,com&gt; wrote:
&gt;Brandon J. Rickman wrote:
&gt;&gt; On Mon, 23 Jun 1997, Shawn Halpenny &lt;malachai#iname,com&gt; wrote:
&gt;&gt; &gt;An aside--given:
&gt;&gt; &gt;Room R at time t=0.
&gt;&gt; &gt;An earthquake is scheduled to occur in R at t+5.
&gt;&gt; &gt;Room R is spoofed at t+2, creating R' which now exists in lieu of R.
&gt;&gt; &gt;Time t+5 arrives, the earthquake occurs.  Are the effects of the
&gt;&gt; &gt;  earthquake applied to R, R', or both?  Generalized:  are any
&gt;&gt; &gt;  actions occuring on R to be duplicated on R' and vice versa?
&gt;&gt;
&gt;&gt; This is a great example of a particularly bad (and quite common) way of
&gt;&gt; non-atomic coding.  "Scheduling" an event in this case is like declaring
&gt;&gt; a prophecy: "There will be an earthquake in 5 ticks!"
&gt;
&gt;I disagree.  Every event is a prophecy since every event must be scheduled,
&gt;else nothing ever happens (events scheduled to happen immediately may be
&gt;exempt).  The objects affected, however, usually have no idea
&gt;about the impending event, nor do they need to.
&gt;
&gt;And why do you consider it non-atomic?

It is non-atomic because the state of the universe might have (most likely
has) changed since the event was first scheduled.  On execution the event
is now responsible for comparing its image of the universe with the real
universe (recognizing that R' has replaced R, for example).  Put bluntly,
it may in fact be impossible for a "prophecied" event to conform itself
to the changed universe.  It happens all the time.  How many times have
you seen this:

&gt; north
The Bar
Ratz is behind the counter, absently rubbing teh counter with a grimy rag.
&gt; east
The Back Room
&gt; up
Second Floor
Ratz waves to you from behind the counter.  "Hey, Shoehorn, haven't seen
you around lately."

The problem isn't that Shoehorn walked out of the room before Ratz
greeted him.  How about this:

The Bar
Ratz is behind the counter, absently rubbing teh counter with a grimy rag.
&gt; wield knife
You wield the butcher knife
&gt; remove the arm of Ratz with knife
You chop off Ratz's right arm.  He looks pissed.
Ratz waves to you from behind the counter.  "Hey, Shoehorn, haven't seen
you around lately."

Or this:

The Bar
Ratz is behind the counter, absently rubbing teh counter with a grimy rag.
The bar explodes into a brilliant fireball.  You have died.
Ratz waves to you from behind the counter.  "Hey, Shoehorn, haven't seen
you around lately."

Maybe you want to play this game of "what if" and program in all the special
cases you can find.  But once you start you can never stop.

(The typo was intentional.)

&gt;&gt; I'll go out on a limb and claim that events must always immedidately
&gt;&gt; originate from objects.  There should be no indirection of events, such
&gt;&gt; that an event might be scheduled by an object but actually be originated
&gt;&gt; as a server action.
&gt;
&gt;I'm not sure I understand.  Are you saying that for the earthquake to
&gt;occur, the evaluation of the decision (yes, make earthquake, no,
&gt;don't) should occur and immediately after that there either is or is
&gt;not an earthquake?  I.e. there is no concept of having an earthquake
&gt;occur in 5 seconds?

There is no _guarantee_ of having an earthquake occur in 5 seconds.  You
can delay the evaluation of the decision for 5 seconds, and if the conditions
are right cause the earthquake.  The event, if it occurs, originates from 
the same object that originally delayed the evaluation.  But if you pass your
earthquake event on to some cleverly coded scheduler your event has
become a kind of prophecy.

If this was a magically created earthquake we can make this problem part
of the risks of casting big magics.  If Bubba cast the earthquake spell, but
the location for the spell has already been destroyed, where does all that
magical energy go?  If we evaluate the decision immediately before the
event, the spell will no longer have a target and maybe it strikes Bubba
instead.  Or maybe it goes off in Detroit.

To go even further: Let us say that casting an earthquake spell
has two parts: summoning the magical energy/Earth forces, and directing
those forces into the earth with destructive intent.  The longer you wait
before directing the forces, the more forces you can gather and the 
stronger the earthquake will be.  Bubba is only a level 5 wizard and only
knows how to create small earthquakes.  His earthquake spell takes 30 ticks
to complete: 25 ticks to gather the forces, a 4 tick pause (a little margin
for casting errors), and 1 tick to start the quake.  His spell creates two
events, the first event of a certain duration (gathering the forces), the
second intended to occur at t+30 ticks.  The earthquake might take a certain
amount of time as well, but I'm not worrying about that here.

During the 25 ticks that the forces are gathering, other things are 
happening in the universe.  Someone might siphon off some or all of those
forces, meaning a less powerful earthquake.  Or Bubba might lose his
concentration and the earthquake goes off early.  Or someone funnels extra
forces into the spell, creating an earthquake beyond Bubba's control.  
The "success" of Bubba's casting is still in doubt until we get to that
t+30 marker or the spell is otherwise perverted.  Both the originator
(quoted text below) and any indirection (below) of the event are in
fact crucial to the actual performance of the event.

&gt;The earthquake was likely scheduled by whatever code was responsible
&gt;for handling the success of Bubba's earthquake spell, but the
&gt;originator of the event doesn't actually matter.  The indirection
&gt;doesn't matter either.  The event and its (spoof) target can be
&gt;considered independently of all other elements in the game (excepting
&gt;the non-spoof target).  I think the earthquake must be propagated to
&gt;both R and R', since (assuming the effects of the quake persist
&gt;beyond the life of R') when R' is terminated, you can't have the
&gt;effects of the earthquake disappear as well.  The +5 delta I
&gt;mentioned above has nothing to do with how the event is processed,
&gt;but was intended only to show that the spoofing, the earthquake, and
&gt;the aftereffects did not occur at the same time.  I could have
&gt;synonymously said:  'Earthquake occurs in spoofed-room R'.  If R' is
&gt;destroyed before the effects of the earthquake are completely gone
&gt;(i.e. the fissures in the earth, etc.), does R show the same
&gt;effects?'  To which the answer, I think, is "yes, definitely."

You don't consider the effects of the earthquake as just another spoof of
the original R?  If the effects of the earthquake are permanent, why don't
we "flatten" R" (the earthquake spoof) and R?

Hm, if we have R' spoofing R:
R - R'  

And the earthquake is a spoof R" of R:
R - R"

We have to relate R' and R".  Maybe we need an parenthetical operator?
(R - R") - R' or possibly (R - R') - R"

This is becoming messy and confusing.  Never mind.

&gt;&gt; I'm thinking cold-like frobs provide a way to solve this.  Otherwise a
&gt;&gt; tighter way of relating the spoofed object to the object of spoofing is
&gt;&gt; needed.  Then R gets the event and passes it on to it's spoof.  This
&gt;&gt; would need quite a bit of garbage collection.
&gt;
&gt;I know not of frobs, and in the stuff above don't see where any garbage
&gt;collection comes in.

R' is a spoof of R.  R'' is a spoof of R'.  R' has an event scheduled.
The condition causing R' goes away.  Do we pass R''s event to R'', to R, or
dump it?  If R' is destroyed, does R'' become a direct spoof of R, or do
we destroy R'' also?  If we destroy R...

Frobs are (someone will correct me) instances of objects that can be passed
around like data.  Who has them besides ColdC?  

- B Rickman


</PRE>

<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg01590.html">Re: [MUD-Dev] Level abstractions - Realism vs Game Issues</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg01592.html">Re: [MUD-Dev] Level abstractions - Realism vs Game Issues</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg01536.html">Re: [MUD-Dev]  Room-based vs. coordinate-based</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg01137.html">Computers can't....</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#01591"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#01591"><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>
<LI><strong><A NAME="01326" HREF="msg01326.html">Re: [MUD-Dev]  Room-based vs. coordinate-based</A></strong>, 
Brandon J. Rickman <a href="mailto:ashes#pc4,zennet.com">ashes#pc4,zennet.com</a>, Mon 16 Jun 1997, 15:13 GMT
<UL>
<LI><strong><A NAME="01336" HREF="msg01336.html">Re: [MUD-Dev]  Room-based vs. coordinate-based</A></strong>, 
clawrenc <a href="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</a>, Wed 18 Jun 1997, 07:25 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="01517" HREF="msg01517.html">Re: [MUD-Dev]  Room-based vs. coordinate-based</A></strong>, 
Brandon J. Rickman <a href="mailto:ashes#pc4,zennet.com">ashes#pc4,zennet.com</a>, Thu 26 Jun 1997, 11:40 GMT
<UL>
<LI><strong><A NAME="01536" HREF="msg01536.html">Re: [MUD-Dev]  Room-based vs. coordinate-based</A></strong>, 
Shawn Halpenny <a href="mailto:malachai#iname,com">malachai#iname,com</a>, Thu 26 Jun 1997, 21:56 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="01591" HREF="msg01591.html">Re: [MUD-Dev]  Room-based vs. coordinate-based</A></strong>, 
Brandon J. Rickman <a href="mailto:ashes#pc4,zennet.com">ashes#pc4,zennet.com</a>, Mon 30 Jun 1997, 07:40 GMT
</LI>
</ul>
</LI>
<LI><strong><A NAME="01137" HREF="msg01137.html">Computers can't....</A></strong>, 
Jeff Kesselman <a href="mailto:jeffk#tenetwork,com">jeffk#tenetwork,com</a>, Mon 05 Jan 1970, 14:43 GMT
<UL>
<LI><strong><A NAME="01164" HREF="msg01164.html">Re: [MUD-Dev]  Computers can't....</A></strong>, 
Caliban Tiresias Darklock <a href="mailto:caliban#darklock,com">caliban#darklock,com</a>, Thu 05 Jun 1997, 07:44 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="01109" HREF="msg01109.html">Re: [MUD-Dev] RP/PG examples</A></strong>, 
Jeff Kesselman <a href="mailto:jeffk#tenetwork,com">jeffk#tenetwork,com</a>, Mon 05 Jan 1970, 05:01 GMT
<UL>
<LI><strong><A NAME="01138" HREF="msg01138.html">Re: [MUD-Dev] RP/PG examples</A></strong>, 
Adam Wiggins <a href="mailto:nightfall#inficad,com">nightfall#inficad,com</a>, Wed 04 Jun 1997, 11:35 GMT
</LI>
</UL>
</LI>
</UL></BLOCKQUOTE>

</ul>
<hr>
<center>
[&nbsp;<a href="../">Other Periods</a>
&nbsp;|&nbsp;<a href="../../">Other mailing lists</a>
&nbsp;|&nbsp;<a href="/search.php3">Search</a>
&nbsp;]
</center>
<hr>
</body>
</html>