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

coder at ibm.net coder at ibm.net
Sat Feb 14 21:52:54 CET 1998


On 30/01/98 at 08:26 AM, Adam Wiggins <nightfall at user2.inficad.com> said:
>[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.

...etc

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

Good point.  A possible address is to place meta-ur-objects in every
possible location for the final object.  Upon one of those meta-ur-objects
being realised (ie becoming an actual ur-object or normal-object) all
other meta-ur's would be destructed.  Note that this is essentially
identical to creating locality lists of ur-object probabilities, but with
the added overhead of the extra object creations and maintenance.

The main problem here is that one of the design goals of this model was
reducing the total count of objects that needed keeping track of, with the
cannonical case being the meadow where ten million bunnies had been
slaughtered.  There is little need to keep track of 10 million bunny
skeletons.  However, if Bubba digs in the meadow he should find bunny
bones.  Using the uncertainty model above, there would be no bunny
skeletons until Bubba dug and found one, which bunny bone would have been
dynamically created by Bubba's digging so that he could find it (realism).

>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 would work for less populous items than the above bunny skeletons,
and has some interesting promises for ur-objects.  Chasing thos down
briefly seems to end up with a very reduced functionality set of the above
and prior described locality idea.

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

In a user programmable game this also opens the object's existance and
location to user program resolution, which can be far from ideal.  Leaving
the objects unrealised makes the fact of their existance unknown until the
moment of definition (not the creation of the ur-object, but the
definition and transformation of the ur-object into the normal object).

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

ie it basically recreates the current model with the only addition the
dyamic creation of undiscovered objects.

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




More information about the mud-dev-archive mailing list