[MUD-Dev] Unique items (was: Graphic MUDS/Ultima Online)

[coder at ibm.net]

On 28/01/98 at 11:55 PM, "Brandon J. Rickman" <ashes at pc4.zennet.com> said:
>On Sun, 11 Jan 1998 21:43:52, JC Lawrence <claw at under.Eng.Sun.COM> wrote:
>>On Fri, 9 Jan 1998 14:26:09 PST8PDT 
>>Vadim Tkachenko<vadimt at 4cs.com> wrote:

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

>I just noticed the revival of this thread.  

Thread revival is one of my major tools in keeping the list fertile.  

>It is nice to know I have
>scored at least one point in my months of heretical postings. 

<bow>

>It gives me
>new energy to prove that faster computers aren't.

Tautologies are (not).

Apologies for the long quotes that follow.  This is an old thread, with
even older roots.

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

This would only seem true if you resolve the determininacy of any and all
keys when they are first seen/picked up.  This in turn requires a fairly
agressive policy for making known objects indeterminate again, which
actually raises the same problem again by allowing an object to
surrepticiously cycle thru determinancy before its state becomes known. 

Another problem here is that this early resolution of identity prevents
other, later, likely more useful resolutions.

Other variations, such as the subject key being possessed and then placed
in a visible but hidden location are also problemic.  I only see the
structure getting interesting if you delay the resolution of determinancy
to the last possible moment -- ie when the key is used on Castle Krak or
some other recognition algorithm is applied and succeeds.

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

In an absolute sense, not true (perception is another matter).  Consider:

  Bubba picks op indeterminate key.
  Bubba puts key into hiding space in back of cave.
  Bubba tosses known-CK tossed into ocean.
  Six years pass.
  Bubba tells Boffo about key at back of cave.
  Boffo opens CK with said key.

Less contrived examples are not difficult to arrange.  The actual source
of the problem in this last example is that the _fact_ and _location_ of
the key are known about while the _fact_ and _lcoation_ of the CK are also
known (simultaenity).  Ergo, logic precludes the first key from ever
resolving to the CK key.  It may of course resolve to some other key which
does not pertain to the same logic trap.  To handle this properly, the
known-about state of every key (known or unknown) must be maintained
time-stamp-wise against all known-keys.  

Not fun.  Expensive.

A good argument can be made that such logical rigour is not necessary. 
Perhaps a fairy swiped the original unknown key at the back of the cave
and replaced it with the CK key when nobody was looking?  Who knows the
logic of fairies?  This is probably a winning argument on the basis that
players just won't care.

My next approach largely agrees with you, but attempts to maintain the
advantages of last-possible-determination:

  There are three types of objects in the world:

    a) objects which have an uncertain state

    b) objects which have a certain state.

    c) objects which don't exist but retain a certain state.

State #b objects which have been actively "lost" (dropped in ocean etc),
exist in state #c.  State #b objects which have been misplaced (eg key at
back of cave) decay into state #a given that they have not been
accessed/recognised within XXX time.  State #c objects are used to enforce
the timing delay you mention, and are destroyed after a suitable period. 
State #a objects may resolve into an object not currently held by a state
#b or state #c object.  State #c merely enforces lost objects remaining
lost for at least a while.

I suspect that I have argued full circle into your original model, but
don't have the interest to track that right now.

>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).

ie the duration of the state #c above.

>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.

Exactly.  I like this.

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

Attributes on the meta-key object.

>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.

The problem is that you need to create methods that actively lose
recovered objects at a near equivalent rate to to their discovery. 
Otherwise your world becomes over-populated.

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

You need to actively encourage that "eventually".  MUD players are very
good at keeping track of their EQ.

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

Quite.  The domain of possibilities should be very large, with the
individual probabilities for each state being very small.  

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

Bingo.  The possibility domain is too small.

>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...).

Die infidel.  The only suitable vocation for MUD players is cleaning up
after bloodthirsty NPC's on player-killing sprees.

>Anyway, now that I've simply reiterated everything JC said in his post,

And I seem to have argued myself into agreeing with you...

>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.

The problem is two sided:  The size of tha data field that needs to be
considered each iteration, and the frequency of that consideration. 
Reduce either side of that product and you've made headway.

One possible attack on reducing the product is to ensure that only those
objects that are possible for a given locality are considered for
creation.  A possible approach:

  All objects are indeterminate until identified.  Such objects are
referred to as "ur-objects".

  Non-existant placeholder objects are referred to as "lost".

  The vast majority of objects are not ur-objects because they have no
"hidden" identity.  Instead they are "normal" objects whose apparent
identity is the same as their real identity.  The game's presentation
however makes all objects appear to be ur-objects.  This distinction is
used merely to lighten the tracking load on the server and DB.

  The identification status of an object is true only while the object is
accessed with sufficient frequency (per object, with a typical value being
once per RL fornight).  It then decays back to an ur-object.

  The server maintains a list of all ur-object types.  All such
object-types of course have an associated objectID.

  All localities maintain a list of possible normal and ur objects for
their locations (ie probability non-zero).  This is just a pointer to a
list of tuples of objectID's and probabilities.

  Upon initiation of an event, it generates a probability value. weighted
as appropriate by the probability field of the locale and the creating
objects.  This value is then used to select that set of potential objects
which have a matching or higher probability for potential creation.

  In the event that multiple (N) objects are to potentially be created,
they are selected randomly with a 2*N^(-1) individual probability, with a
side guarantee that at least one object will always be created.

This doesn't really handle the problem, tracking all the potential
objects, updating the fields as the probability changes, and all the rest
is still a hefty load, but its a start.  I suspect a deeper elegance still
remains.

>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).

I think I'd approach this by weigting their probability fields to
predispose them towards certain discoveries.  This creates a further
problem however as the list of potential objects for the area now has to
be treated as a set of lists each lists as affected by a specific
probability field.  Nasty.

--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...