1998Q1/
<!-- MHonArc v2.4.4 -->
<!--X-Subject: Re: [MUD&#45;Dev] Unique items (was: Graphic MUDS/Ultima Online) -->
<!--X-From-R13: "Penaqba X. Dvpxzna" <nfurfNcp4.mraarg.pbz> -->
<!--X-Date: Thu, 29 Jan 1998 00:54:08 +0000 -->
<!--X-Message-Id: 199801290053.QAA21207#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] Unique items (was: Graphic MUDS/Ultima Online)</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="msg00337.html">Previous</a>
&nbsp;|&nbsp;<a href="msg00339.html">Next</a>
&nbsp;]
&nbsp;&nbsp;&nbsp;&nbsp;
Thread:&nbsp;
[&nbsp;<a href="msg00197.html">Previous</a>
&nbsp;|&nbsp;<a href="msg00343.html">Next</a>
&nbsp;]
&nbsp;&nbsp;&nbsp;&nbsp;
Index:&nbsp;
[&nbsp;<A HREF="author.html#00338">Author</A>
&nbsp;|&nbsp;<A HREF="#00338">Date</A>
&nbsp;|&nbsp;<A HREF="thread.html#00338">Thread</A>
&nbsp;]

<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>Re: [MUD-Dev] Unique items (was: Graphic MUDS/Ultima Online)</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] Unique items (was: Graphic MUDS/Ultima Online)</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>: Wed, 28 Jan 1998 16:53:59 -0800</LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
On Sun, 11 Jan 1998 21:43:52, JC Lawrence &lt;claw#under,Eng.Sun.COM&gt; wrote:
&gt;On Fri, 9 Jan 1998 14:26:09 PST8PDT 
&gt;Vadim Tkachenko&lt;vadimt#4cs,com&gt; wrote:
&gt;&gt; [...]
&gt;&gt; 'course, there are exceptions like above - one-way actions like
&gt;&gt; dropping into ocean, which should be resolved separately.

&gt;I have come to a seperate conclusion as suggested by Carter, or was it
&gt;one of our many Brandons (Cline?).  Essentially it devolves into:
&gt;
&gt;  There are two types of objects in the world:
&gt;
&gt;    a) objects which have an uncertain state
&gt;
&gt;    b) objects which have a certain state.

I just noticed the revival of this thread.  It is nice to know I
have scored at least one point in my months of heretical postings.
It gives me new energy to prove that faster computers aren't.

&gt;This may seem sort of obvious, but the results can be intrigueing.
&gt;Consider:
&gt;
&gt;  There is a key which can be used to get into Castle Krak.  It is the
&gt;__only__ key which can do that, and that is the __only__ way to get
&gt;into castle Krak.
&gt;
&gt;  Bubba drops the key into the ocean.
&gt;
&gt;  The key now enters an "indeterminate" state.
&gt;
&gt;  The result is that every other key in the land which is also in an
&gt;indeterminate state and is not possessed by a player now has a finite,
&gt;but definite, chance of proving to be the key to Castle Krak.  
&gt;
&gt;The trick is that objects only become determinate when they are asked
&gt;to.  To take the case of keys, all keys start with an indeterminate
&gt;state.  If a key is used to try and enter Castle Krak, and if no other
&gt;key has currently been determined to be the key to CK, then a
&gt;probability is weighed, and if won, the current key becomes the key to
&gt;CK.  If that probability is lost, nothing changes -- the key is still
&gt;indeterminate.
&gt;
&gt;There are problems.
&gt;
&gt;  Boffo picks up a key.
&gt;
&gt;  Bubba drops a different key. which is the key to the CK, in the
&gt;ocean.
&gt;
&gt;  Boffo attempt to open the CK with his key -- it works!
&gt;
&gt;The problem become apparent when you make Boffo and Bubba the same
&gt;person.  Bubba just dropped the key to the CK in the ocean, which is a
&gt;unique object, yet another key he already has is also a key to the CK?

This is a subtle and interesting problem.  There are some problems with
your problem:

If Boffo picks up the key _before_ Bubba disposes of his key, then
the determinacy of Boffo's key would have already been made and there
is no chance of it being the key to CK.

The problem is in the amount of time between when a unique object becomes
indeterminate (not in-the-world) and is rediscovered.

Dropping a key in the ocean is a very specific way to lose something,
but so is leaving the key in a desert.  The chance that the key will
be rediscovered should depend on where/how the key was lost and how long
it has been since last seen (these would somehow seed the future
probabilities).

At t+0 the key is "dropped" into the ocean.

At t+10 (days/weeks/whatever) the key, having sat unnoticed at the
bottom of the ocean, is removed by world housekeeping routines.  But
since the key is flagged as unique (or is otherwise important, like
a rabbit skeleton :) ) some note is made.  A weight of 10 is
assigned to the chance that the key will be found in the ocean.

At t+30, through some kind of statistical osmosis, more weights are 
added to related geographies: ocean 15, seaside 2, arctic 1.

At t+100, the chances might be: ocean 50, seaside 40, arctic 20, plains 5,
mountains 5, desert 2, dragon hoard 2, global 1.

Of course at any time the key might be rediscovered.  The hope is that
the rediscovery will be at worse an unlikely (but not absurd) event.

(I'm just making up the geo stuff, and this doesn't mean that these weights
are actually stored anywhere except as an algorithm.)

Originally I was thinking about having items lost for extremely long
periods of time, say hundreds of years.  In building a world you might
create oodles of magical weapons, make up some legends for the more
powerful ones, and then conveniently lose all the weapons before allowing
players into the game.  As time goes by, players start discovering the
lesser or greater magical weapons and start to think maybe the legends
are true.

Eventually the weapons will get lost again, and found again.

&gt;  One possible address is putting a delay on when newly
&gt;indetermiante-states can be realised.  Sure, Bubba drops the key in
&gt;the ocean, but its going to be a month (say) before any key can be a
&gt;key to the CK.  Note that this doesn't solve the problem, it just
&gt;hides some of its cases (same scenario as above can still occur).
&gt;
&gt;  A more subtle address makes all objects which are possessed or
&gt;possessed recently as "determinate".  The indeterminancy then enters
&gt;in the creation of new objects.
&gt;
&gt;  Bubba drops the key in the ocean.
&gt;
&gt;  Later Boffo catches a fish.  If he guts the fish there is a small
&gt;but definite chance that a key will be created for him to find, and
&gt;&gt;that that key will be the key to the CK.

Ample opportunities for "discovering" lost items have to be built into
the game.  Fishing is a nice solution, but things could be buried in
the sand, hidden in a pile of seaweed, or just lying in the middle of
a forest path.  Some actions act as active attempts to "discover" items,
but there should be passive checks as well.  This means that the
probabilities should be quite improbable.  Otherwise:

You chat, "Hey, I lost the key to Castle Krak.  Everyone go stumble
around in the forest until someone finds it."

It would be interesting to know that you might find something if
you went around digging holes.  Players would probably start making
careers out of digging up random stuff.  Oh dear, I think I just
justified letting players have alternative careers (fishing,
digging, drinking...).

&gt;  Ditto for Bernie walking the beach and stumbling over just such
&gt;another ad hoc created key in the sands.
&gt;
&gt;Me?  I don't like the concept of unique objects.  I'm going for the
&gt;determinate/indeterminate state approach where everything not
&gt;determined is indeterminate.  I'll accept the problem as unlikely to
&gt;be noticed, and if noticed unlikely of being a big problem.

Unique objects are fine, there just has to be a way to take them out of
and put them back into the game.

Anyway, now that I've simply reiterated everything JC said in his post,
I've been thinking about how to implement the discovery of objects.

A prototype test case:

For any given terrain/location there is a basic set of likely objects to
be found there, objects being relatively portable constructs (so I'm
not talking about one ton rocks or hundred year old oaks, i.e. relative
scale is assumed to be similar for the moment).  For a forest this might
be:

a clump of leaves
a small stone
some dirt
...

There is also a set of "lost" (or indeterminate) objects with associated
quantities and probabilistic weights:

511 copper coins, 100
4 gold coins, 20
1 Key to Castle Krak, 1
...

Now imagine both lists are hundreds of items long.  

If we are going to check for discoveries every time a character moves
(perhaps a 10% chance of discovering something each time) and we have
100 active characters moving around once per minute we will have to
make a check about 10 times a minute, or every 6 seconds.

Obviously iterating through a thousand item list and making a weighted
probability check for each item isn't very efficient, not every six
seconds.

How would you construct a list (a hash? a linked list?), keeping in mind
that the weights and quantities for many items will constantly change,
with items being removed and added as well.

Characters should also be able to make an active search for specific
items.  Someone could spend some time collecting small stones.  Of 
course, the stones should become harder and harder to find (ref the
quite bizarre stamps example some time back).

- Brandon Rickman - ashes#zennet,com -
While I have never previously found a need for a .sig, this
may be considered one for the purposes of this list

</PRE>

<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<ul compact><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><A NAME="00466" HREF="msg00466.html">Re: [MUD-Dev] Unique items (was: Graphic MUDS/Ultima Online)</A></strong>
<ul compact><li><em>From:</em> coder#ibm,net</li></ul>
<li><strong><A NAME="00343" HREF="msg00343.html">Re: [MUD-Dev] Unique items (was: Graphic MUDS/Ultima Online)</A></strong>
<ul compact><li><em>From:</em> Adam Wiggins &lt;nightfall#user2,inficad.com&gt;</li></ul>
</UL></LI></UL>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00337.html">Java and Javascript</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00339.html">Re: [MUD-Dev] Arctic's Project?</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00197.html">Re: [MUD-Dev] Unique items (was: Graphic MUDS/Ultima Online)</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00343.html">Re: [MUD-Dev] Unique items (was: Graphic MUDS/Ultima Online)</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00338"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00338"><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] Unique items</STRONG>, <EM>(continued)</EM>
<ul compact>
<ul compact>
<ul compact>
<LI><strong><A NAME="00213" HREF="msg00213.html">Re: [MUD-Dev] Unique items</A></strong>, 
Vadim Tkachenko <a href="mailto:vadimt#4cs,com">vadimt#4cs,com</a>, Mon 12 Jan 1998, 17:42 GMT
<UL>
<LI><strong><A NAME="00226" HREF="msg00226.html">Re: [MUD-Dev] Unique items</A></strong>, 
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Tue 13 Jan 1998, 05:33 GMT
</LI>
</UL>
</LI>
</ul>
<LI><strong><A NAME="00200" HREF="msg00200.html">Re: [MUD-Dev] Unique items</A></strong>, 
JC Lawrence <a href="mailto:claw#under,Eng.Sun.COM">claw#under,Eng.Sun.COM</a>, Sun 11 Jan 1998, 21:31 GMT
</LI>
</ul>
<LI><strong><A NAME="00197" HREF="msg00197.html">Re: [MUD-Dev] Unique items (was: Graphic MUDS/Ultima Online)</A></strong>, 
JC Lawrence <a href="mailto:claw#under,Eng.Sun.COM">claw#under,Eng.Sun.COM</a>, Sun 11 Jan 1998, 21:01 GMT
</LI>
<LI><strong><A NAME="00338" HREF="msg00338.html">Re: [MUD-Dev] Unique items (was: Graphic MUDS/Ultima Online)</A></strong>, 
Brandon J. Rickman <a href="mailto:ashes#pc4,zennet.com">ashes#pc4,zennet.com</a>, Thu 29 Jan 1998, 00:54 GMT
<UL>
<LI><strong><A NAME="00343" HREF="msg00343.html">Re: [MUD-Dev] Unique items (was: Graphic MUDS/Ultima Online)</A></strong>, 
Adam Wiggins <a href="mailto:nightfall#user2,inficad.com">nightfall#user2,inficad.com</a>, Fri 30 Jan 1998, 07:37 GMT
<UL>
<LI><strong><A NAME="00377" HREF="msg00377.html">Monthly FAQ posting</A></strong>, 
Ling <a href="mailto:K.L.Lo-94#student,lboro.ac.uk">K.L.Lo-94#student,lboro.ac.uk</a>, Tue 03 Feb 1998, 18:10 GMT
</LI>
<LI><strong><A NAME="00467" HREF="msg00467.html">Re: [MUD-Dev] Unique items (was: Graphic MUDS/Ultima Online)</A></strong>, 
coder <a href="mailto:coder#ibm,net">coder#ibm,net</a>, Sun 15 Feb 1998, 10:24 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00466" HREF="msg00466.html">Re: [MUD-Dev] Unique items (was: Graphic MUDS/Ultima Online)</A></strong>, 
coder <a href="mailto:coder#ibm,net">coder#ibm,net</a>, Sun 15 Feb 1998, 04:44 GMT
</LI>
</UL>
</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>