January 1998
- Mail from mud Zoran's final Imp Stephen Zepp
- Mail from mud Zoran's final Imp coder@ibm.net
- Mail from mud Zoran's final Imp Shawn Halpenny
- Mail from mud Zoran's final Imp JC Lawrence
- Mail from mud Zoran's final Imp Shawn Halpenny
- Happy new year Marian Griffith
- Totally OT... Marian Griffith
- Totally OT... (Or is it?) s001gmu@nova.wright.edu
- Mud-Dev FAQ Ling
- Mud-Dev FAQ Jon A. Lambert
- Mud-Dev FAQ JC Lawrence
- Mud-Dev FAQ Adam Wiggins
- Who's bugging who? : was- Wild West Jon A. Lambert
- my bio (was Mud-Dev FAQ) Mike Sellers
- request for comments (was: Mud-Dev FAQ) Vadim Tkachenko
- request for comments (was: Mud-Dev FAQ) Jon A. Lambert
- request for comments (was: Mud-Dev FAQ) coder@ibm.net
- request for comments (was: Mud-Dev FAQ) JC Lawrence
- request for comments (was: Mud-Dev FAQ) s001gmu@nova.wright.edu
- request for comments (was: Mud-Dev FAQ) JC Lawrence
- request for comments (was: Mud-Dev FAQ) Vadim Tkachenko
- OT: Suomi Finland Ola Fosheim Grøstad
- OT: Suomi Finland ##Make Nylander
- Totally OT... (Or is it?) (yes it is ;) Marian Griffith
- Totally OT... (Or is it?) (yes it is ;) Ola Fosheim Grøstad
- Totally OT... (Or is it?) (yes it is ;) Adam Wiggins
- Totally OT... (Or is it?) (yes it is ;) Ola Fosheim Grøstad
- Totally OT... (Or is it?) (yes it is ;) Jon A. Lambert
- Totally OT... (Or is it?) (yes it is ;) Ola Fosheim Grøstad
- Totally OT... (Or is it?) (yes it is ;) JC Lawrence
- Totally OT... (Or is it?) (yes it is ;) Jon A. Lambert
- Totally OT... (Or is it?) (yes it is ;) Mike Sellers
- Totally OT... (Or is it?) (yes it is ;) JC Lawrence
- Totally OT... (Or is it?) (yes it is ;) JC Lawrence
- Journal of MUD Research, Vol. 3, No. 1 [TEXT] coder@ibm.net
- World Seeding (was Task Parsing) Ling
- World Seeding (was Task Parsing) JC Lawrence
- World Seeding (was Task Parsing) Stephen Zepp
- threaded servers (was request for comments Mike Sellers
- MUD Economy Shawn Halpenny
- MUD Economy Adam Wiggins
- MUD Economy Shawn Halpenny
- MUD Economy Ling
- MUD Economy Brandon J. Rickman
- MUD Economy Marian Griffith
- MUD Economy Shawn Halpenny
- MUD Economy Shawn Halpenny
- MUD Economy JC Lawrence
- MUD Economy Koster, Raph
- MUD Economy Matt Chatterley
- MUD Economy JC Lawrence
- MUD Economy Jon A. Lambert
- OT: Jobs available Koster, Raph
- OT: DCOM and RMI Jon A. Lambert
- OT: DCOM and RMI Vadim Tkachenko
- OT: DCOM and RMI Vadim Tkachenko
- OT: DCOM and RMI Miroslav Silovic
- OT: DCOM and RMI Alex Oren
- OT: DCOM and RMI Chris Gray
- request for comments Miroslav Silovic
- request for comments JC Lawrence
- Event handling (was: request for comments) Vadim Tkachenko
- Event handling (was: request for comments) s001gmu@nova.wright.edu
- Event handling (was: request for comments) Vadim Tkachenko
- Event handling (was: request for comments) s001gmu@nova.wright.edu
- Event handling (was: request for comments) Vadim Tkachenko
- Event handling (was: request for comments) JC Lawrence
- Event handling (was: request for comments) s001gmu@nova.wright.edu
- Event handling (was: request for comments) JC Lawrence
- Event handling (was: request for comments) s001gmu@nova.wright.edu
- Event handling (was: request for comments) JC Lawrence
- Event handling (was: request for comments) Matt Chatterley
- Event handling (was: request for comments) s001gmu@nova.wright.edu
- Event handling (was: request for comments) s001gmu@nova.wright.edu
- Event handling (was: request for comments) JC Lawrence
- Event handling (was: request for comments) Vadim Tkachenko
- request for comments JC Lawrence
- Text vs Video; Movies, Books & muds. Nathan Yospe
- Unique items (was: Graphic MUDS/Ultima Online) Vadim Tkachenko
- Unique items (was: Graphic MUDS/Ultima Online) JC Lawrence
- Unique items (was: Graphic MUDS/Ultima Online) Brandon J. Rickman
- Unique items (was: Graphic MUDS/Ultima Online) Adam Wiggins
[Brandon J. Rickman:]
> On Sun, 11 Jan 1998 21:43:52, JC Lawrence <claw@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. - Unique items (was: Graphic MUDS/Ultima Online) Brandon J. Rickman
- Unique items (was: Graphic MUDS/Ultima Online) Marian Griffith
- Unique items (was: Graphic MUDS/Ultima Online) coder@ibm.net
- Unique items (was: Graphic MUDS/Ultima Online) coder@ibm.net
- Unique items (was: Graphic MUDS/Ultima Online) Chris Gray
- Unique items (was: Graphic MUDS/Ultima Online) coder@ibm.net
- Unique items (was: Graphic MUDS/Ultima Online) coder@ibm.net
- Unique items (was: Graphic MUDS/Ultima Online) coder@ibm.net
- Unique items (was: Graphic MUDS/Ultima Online) Adam Wiggins
- Unique items (was: Graphic MUDS/Ultima Online) coder@ibm.net
- Unique items (was: Graphic MUDS/Ultima Online) Adam Wiggins
- Delivery Notification: Delivery has failed PMDF e-Mail Interconnect
- Unique items Richard Woolcock
- Unique items Jon A. Lambert
- Unique items Vadim Tkachenko
- Unique items Jon A. Lambert
- Unique items JC Lawrence
- Delivery Notification: Delivery has failed PMDF e-Mail Interconnect
- Delivery Notification: Delivery has failed PMDF e-Mail Interconnect
- Delivery Notification: Delivery has failed PMDF e-Mail Interconnect
- Two Tiers Ling
- MUD Development Digest Dr. Cat
- FAQ Ling
- Clients Matt Chatterley
- Clients JC Lawrence
- Clients Shawn Halpenny
- Clients Matt Chatterley
- Event handling - some definitions Jon A. Lambert
- Event Handling Jon A. Lambert
- Simulations - was: 'A flamewar startingpoint.' Jon A. Lambert
- Formatting apology Stephen Zepp
- OT: Insane Wordwrapping Caliban Tiresias Darklock
- OT: Insane Wordwrapping Alex Oren
- Summary Marian Griffith
- Clients Andrew Wilson
- Vast areas in muds Ling
- Vast areas in muds John G.
- Vast areas in muds Nathan Yospe
- Vast areas in muds Mike Sellers
- Vast areas in muds John G.
- Vast areas in muds Nathan Yospe
- META: Web futures for the list JC Lawrence
- OT: Socket programming - platform specific Jon A. Lambert
- OT: Socket programming - platform specific Chris Gray
- OT: Socket programming - platform specific Jon A. Lambert
- OT: Socket programming - platform specific Caliban Tiresias Darklock
- OT: Socket programming - platform specific Chris Gray
- Graphical mud perspectives Richard Woolcock
- Graphical mud perspectives Nathan Yospe
- Graphical mud perspectives Richard Woolcock
- Graphical mud perspectives Koster, Raph
- Graphical mud perspectives Mike Sellers
- Graphical mud perspectives Koster, Raph
- CORBA, RMI, threads Marc Eyrignoux
- CORBA, RMI, threads Nathan Yospe
- CORBA, RMI, threads Marc Eyrignoux
- CORBA, RMI, threads s001gmu@nova.wright.edu
- CORBA, RMI, threads Brandon Gillespie
- CORBA, RMI, threads Chris Gray
- CORBA, RMI, threads Marc Eyrignoux
- CORBA, RMI, threads Brandon Gillespie
- CORBA, RMI, threads s001gmu@nova.wright.edu
- CORBA, RMI, threads coder@ibm.net
- CORBA, RMI, threads s001gmu@nova.wright.edu
- CORBA, RMI, threads Vadim Tkachenko
- CORBA, RMI, threads Caliban Tiresias Darklock
- CORBA, RMI, threads coder@ibm.net
- Clients based on Netscape 5? Greg Munt
- Clients based on Netscape 5? Chris Gray
- Clients based on Netscape 5? Caliban Tiresias Darklock
- Clients based on Netscape 5? Vadim Tkachenko
- Clients based on Netscape 5? Caliban Tiresias Darklock
- Clients based on Netscape 5? Chris Gray
- Clients based on Netscape 5? Vadim Tkachenko
- Clients based on Netscape 5? Chris Gray
- Clients based on Netscape 5? Vadim Tkachenko
- Clients based on Netscape 5? Chris Gray
- Clients based on Netscape 5? Marian Griffith
- Clients based on Netscape 5? coder@ibm.net
- OT? The impact of the web on muds Mike Sellers
- The Anti-Mac Interface JC Lawrence
- 3D graphics (Was: The impact of the web on muds) Jon Leonard
- 3D graphics (Was: The impact of the web on muds) Caliban Tiresias Darklock
- 3D graphics (Was: The impact of the web on muds) coder@ibm.net
- 3D graphics (Was: The impact of the web on muds) Mike Sellers
- 3D graphics (Was: The impact of the web on muds) Chris Gray
- 3D graphics (Was: The impact of the web on muds) Caliban Tiresias Darklock
- 3D graphics (Was: The impact of the web on muds) coder@ibm.net
- 3D graphics (Was: The impact of the web on muds) coder@ibm.net
- VRML Becomes ISO/IEC International Standard (fwd) Nathan Yospe
- Arctic's Project? Brandon Cline
- Arctic's Project? Adam Wiggins
- Arctic's Project? Brandon Cline
- Arctic's Project? Chris Gray
- FAQ Marc Eyrignoux
- Java and Javascript Greg Munt
- Java and Javascript Chris Gray
- Java and Javascript Matt Chatterley
- Java and Javascript coder@ibm.net
- Java and Javascript Matt Chatterley
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Matt Chatterley
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Chris Gray
- Java and Javascript Jon Leonard
- Java and Javascript Matt Chatterley
- Java and Javascript Jon A. Lambert
- Java and Javascript Ben Greear
- Java and Javascript Jon A. Lambert
- Java and Javascript Ben Greear
- Java and Javascript Jon A. Lambert
- Java and Javascript Ben Greear
- Java and Javascript Jon A. Lambert
- Java and Javascript Mike Sellers
- Java and Javascript J C Lawrence
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Jon A. Lambert
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Jon A. Lambert
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Jon A. Lambert
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Travis Casey
- Java and Javascript Jon A. Lambert
- Java and Javascript Sauron
- Java and Javascript Jon A. Lambert
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Alex Oren
- Java and Javascript Chris Gray
- Java and Javascript coder@ibm.net
- Java and Javascript Matt Chatterley
- Java and Javascript coder@ibm.net
- MetaVoice, MetaFont Ling
- MetaVoice, MetaFont Richard Woolcock
- MetaVoice, MetaFont Vadim Tkachenko
- MetaVoice, MetaFont JC Lawrence
- MetaVoice, MetaFont Chris Gray
- The MLI Project Vadim Tkachenko
- The MLI Project Marc Eyrignoux
- The MLI Project Vadim Tkachenko
- The MLI Project coder@ibm.net
- The MLI Project Ling
- The MLI Project coder@ibm.net
- The MLI Project Caliban Tiresias Darklock
- The MLI Project Travis Casey
- The MLI Project Travis Casey
- The MLI Project coder@ibm.net
- The MLI Project s001gmu@nova.wright.edu
- The MLI Project Vadim Tkachenko
- The MLI Project Travis Casey
- The MLI Project Stephen Zepp
- The MLI Project coder@ibm.net
- The MLI Project Travis Casey
- The MLI Project Chris Gray
- The MLI Project Ling
- The MLI Project Andrew C.M. McClintock
- The MLI Project Ling
- The MLI Project Chris Gray
- The MLI Project Caliban Tiresias Darklock
- The MLI Project Chris Gray
- The MLI Project Caliban Tiresias Darklock
- The MLI Project Niklas Elmqvist
- The MLI Project Caliban Tiresias Darklock
- The MLI Project Chris Gray
- The MLI Project Ling
- The MLI Project Caliban Tiresias Darklock
- The MLI Project J C Lawrence
- The MLI Project Chris Gray
- The MLI Project Koster, Raph
- The MLI Project J C Lawrence
- The MLI Project Vadim Tkachenko
- Races and stuff (was: FAQ) Vadim Tkachenko
- Races and stuff (was: FAQ) Marc Eyrignoux
- Races and stuff (was: FAQ) Vadim Tkachenko
- OT: I'm moving again! JC Lawrence
- MUD Development Digest Dr. Cat
- Administrative Responsibilities Greg Munt
- Administrative Responsibilities Jon A. Lambert
- Administrative Responsibilities Greg Munt
- Administrative Responsibilities Jon A. Lambert
- Administrative Responsibilities Mike Sellers
- Administrative Responsibilities Chris Gray
- Administrative Responsibilities Greg Munt
- Administrative Responsibilities coder@ibm.net
- Administrative Responsibilities Jon A. Lambert
- Administrative Responsibilities Greg Munt
- Administrative Responsibilities Jon A. Lambert
- Administrative Responsibilities coder@ibm.net
- Administrative Responsibilities Chris Gray
- Administrative Responsibilities Mike Sellers
- Administrative Responsibilities Mike Sellers
- Administrative Responsibilities Adam Wiggins
- Administrative Responsibilities Greg Munt