[MUD-Dev] Unique items

Nathan F Yospe yospe at hawaii.edu
Mon Feb 23 10:15:31 CET 1998


On Mon, 23 Feb 1998 coder at ibm.net wrote:

:On 20/02/98 at 12:21 AM, Mike Sellers <mike at online-alchemy.com> said: >At
:
:>I'm not so sure.  I'm fairly close to completing a prototype along these
:>lines.  I hate to dangle this one out there, but I can't say a lot more
:>just yet.  If it continues to work, it should be pretty interesting.  And
:>the map is, well, big. 

:How much (in the sense of detail depth) of the world are you making
:dynamically generated?  

Just to add my own input on the matter... initially, 100%. Static world
construction comes later. Of course, there is the little fact that each
world is a seperate case, that I have totally neglected mapping between
worlds that are not neighbors, and that neighbors have to be made local
to each other by deliberate specification.

:>>The key datum however is that an area containing (or percieved by) a
:>>self-realising object can't be torn down, whereas an area not containing
:>>only self-ignorant objects can been freely torn down and rebuilt without
:>>impact (presuming your rebuild and prediction tools are good enough)

:>Yes, this is key.  

:The excessively nasty aspect of this are indirectly reaslising objects:

:  -- Bubba leaves a running video camera in the haunted house and then
:leaves for the next country.

Tough... there is no way this one is going to actually create any event
that might interest Bubba in a dynamic region unless the region goes to
active status when someone else enters it. It'll produce a bunch of the
sort of background events the region can be expected to when recovered,
but there may be inconsistancies. For cases like this, I wouldn't care.

:  -- Bubba places a boulder precariously at the top of a cliff with a
:string tied to the stick preventing it from falling down the cliff.  He
:then travels a *large* distance away, goes to sleep, and pulls the string
:on waking.  On return tot he cliff, what does he see?

A fallen boulder. The boulder remains set in a state, there is no cause
to actually update the event until the area goes active again (assuming
it went inactive, it might not have yet), but the string tug will be in
the queue at the highest active node.

:  -- Same scenario, but no string, and magic is used to remove the stick.

Likewise. Well, substituting a remote control detonator or some such. I
don't see why this would _ever_ differ from the string case...

:  -- Same scenario except a carefully positioned magifying glass uses
:sunlight to set fire to the stick.

That'd just be stored and triggered when all stored information is made
real and brought up to date.

:  -- Same scenario except that a trip wire stretched across a cave mouth
:is tripped by a bear leaving its cave a 6 months later after hibernating.

Now this is inprobable. I don't know if I'd have the database contents,
after six months, with that much detail remaining. Haven't really given
database maintainance for long-inactive regions much thought. My design
itself is such that these things would seldom survive so long. Besides,
I don't have hibernating bears. I suppose if I had implemented seasons.

:>>...I think I'm going to try this.  _BUT_, I'll use a mostly
:>>persistant world (fixed terrain, mostly fixed resource maps, fixed major
:>>objects etc), and the make the chaff dynamic.  

:>Good luck!  Who knows, maybe this is the wave of the future. :)

:I suspect in essence it is if only from a computational standpoint: the
:macro-world will be constant, tracked, and deterministic.  Only the
:micro-world will be dynamic, fractalist, and uncertain.

I tend to agree here, though I think deterministic is too strong a term
for what I do on the macro scale. Semi-constant, tracked, and generally
predictable. 

:How about the argument that this is precisely how reality really works? 
:We're not too too far from a (very) macro form of quantum mechanics.

*grin* I don't call my system Physmud for nothing, you know.
--

Nathan F. Yospe - Aimed High, Crashed Hard, In the Hanger, Back Flying Soon
Jr Software Engineer, Textron Systems Division (On loan to Rocketdyne Tech)
(Temporarily on Hold) Student, University of Hawaii at Manoa, Physics Dept.
yospe#hawaii.edu nyospe#premier.mhpcc.af.mil http://www2.hawaii.edu/~yospe/





More information about the mud-dev-archive mailing list