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

[Adam Wiggins]

[Brandon J. Rickman:]
> On Sun, 11 Jan 1998 21:43:52, JC Lawrence <claw at under.Eng.Sun.COM> wrote:
> >  There are two types of objects in the world:
> >
> >    a) objects which have an uncertain state
> >
> >    b) objects which have a certain state.
> 
> >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.
> 
> 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.
> 
> >  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:
> 
> 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...).
> 
> >  Ditto for Bernie walking the beach and stumbling over just such
> >another ad hoc created key in the sands.
> >
> >Me?  I don't like the concept of unique objects.  I'm going for the
> >determinate/indeterminate state approach where everything not
> >determined is indeterminate.  I'll accept the problem as unlikely to
> >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).

I didn't cut any of this, as I find it all relevant (not to mention quite
interesting).

First of all, the idea that you check for an object being created
every time someone takes a step seems a bit odd to me.  Does this mean
that running back and forth over the same patch of ground 10,000 times
increases your chance of finding the key to castle krak by 10000x?
This doesn't quite seem right, and has the problems of sucking down a
lot of CPU time, as you mention.  Why not have an object population
pulse (similar to what's found in current muds), where the system
runs through the list once, decides which (if any) objects will be
created, and then finds a suitable place to put them?  This has
the object actually placed into the world, just as if someone
had dropped it there.  Then it starts to decay again just as it
did the first time, until finally it disappears to be recreated at
some later time.

This will should cause these items to pop into the world fairly frequently,
but the chance that they will be found on a given run of existance is
pretty low.

This seems to solve every problem - Bubba's key will not suddenly turn into
the key to castle Krak (as the key's properties are determined at
time of creation), and CPU usage is very low, at the slight expense
of extra objects in the world.  I would say that this method would not
be ideal for piles of leaves and other such extra junk, however,
and also the indeterminacy thing as originally conceptualized, above,
seems to have a slightly higher 'neat' factor, for some reason I can't
pin down.

FWIW, Arctic has a similar random creation method for spellbooks and
prayerbooks.  The number of locations are a bit too small, however, for
it to seem very random - longtime players have learned them all, even
though the admin regularly fiddle with the load percentage tables.
Also, the lifetimes of these books are very short - usually they appear
someplace (raning from inside an old tree to the inventory of a tough
NPC) and then disappear within 30 minutes.