[MUD-Dev] Virtual rooms (was: RP thesis...)

[clawrenc at cup.hp.com]

In <338B0796.41C67EA6 at iname.com>, on 05/27/97 
   at 07:35 PM, Shawn Halpenny <malachai at iname.com> said:
>clawrenc at cup.hp.com wrote:

>>   Have an automatic creation/instantiation structure such that an
>>     objects only referred to in a virtual room description can be
>>     instantiated from a template of generic such objects and placed
>>     in the room as above if changes are made to or concerning it.

>Now I'm not sure I want to categorize the objects into those that
>only exist in virtual rooms and those that do not.  There isn't any
>reason a blaze on a tree in a virtual room can't be used in a
>built-room.  

True.

>I assume you mean upon instantiation of the blaze in the
>virtual room, and if it were ever used in a built-room, things will
>still work as they should?	

Yup.

The problem is that you'll have implicit objects in virtual rooms (ie
objects that are mentioned in the description, but which otherwise
don't exist) which need to be made explicit (ie actual objects).  As
you mention this can be true as well for non-virtual rooms.  Consider:

  > l
  You are in a forest.
  > l at trees
  They are a mix of oak, beech and elm, with a few scattered yew 
    and hazelnut.
  > l at yew
  There's a yew tree right by you.  
  > blaze yew 
  You cut a blaze into the yew tree.

I'm presuming that none of those trees actually existed until they
were blazed, at which point one tree of the appropriate type was
instantiated and a blaze applied to it.

>The only portion of the world that is constructed on the fly are the
>regions in which no built-rooms exist.  These regions are a
>collection of 2D locations, essentially bounded by an n-sided
>polygon, the contents of which denote a uniform terrain type that can
>be generically described.  The set of these regions is stored in
>something like a quad- or oct-tree (though truthfully could end up
>being something else entirely, as long as I can reasonably store
>expansive, low-detail regions in a small amount of space and any
>interspersed high-detail regions (i.e.  built-rooms) in an
>appropriate amount of detail).  

I'd be tempted to go for an R*-Tree and then periodically sweep the
tree to remove unwanted/needed rectangles.

>The z-coord is not part of the
>location key into the oct-tree since I am assuming the number of
>places in the world that a large number of objects stacked one on top
>of another will be few.  All objects have a 3D location associated
>with them and exist in a separate mapping, again keyed to location. 
>If a built-room exists at a given location, display its description,
>etc.  If there is no built-room at a point, then examine the oct-tree
>to find the terrain at that location and display an appropriate
>description.

>(That was from memory and should be close enough to true).

Sounds good.

>> My attempted tack is that by building a flexible enough system will
>> allow the complexities to devolve into taking care of themselves.
>> While I currently have no idea how to handle the "path appears/grows
>> back" question, I am convinced that coming up with some sort of
>> generic structure to model it (the tough bit) and applying that in
>> turn to the entire DB structure will result in it being just an
>> implied automaticity in the way the MUD world works.

>I agree.  I plan to have as much stuff take care of itself as
>possible.  As for the path appearing/growing-over, I wonder if we
>don't already have the solution, or at least the building blocks to
>do it.  Since we've got events, we can schedule the regrowth and
>subsequently have those events fail if someone has traversed the path
>recently and post a new regrowth event again to do the same, or else
>they succeed and destroy all the objects associated with the path. 
>This is done on a room-by-room basis, of course, so that the path
>will not all disappear at once.  The path itself can be represented
>by an object (even an exit object, for that matter).

Yeah, the basics are there -- I'm just lost on how to represent it to
the user without requiring an immense amount of work up front from the
builders.  Its easy enough to code a process which increments over
time to a given state.  The problem is doing:

  > l
  You are standing in a narrow clearing amidst tall grasses; 
    very tall grasses actually, reaching to just over your 
    shoulders.
  > 
  A line of tinkers bursts out of the grass beside you, cuts 
    across the clearning, and forces their way into the grass 
    on the other side.  The line of tinkers seems almost 
    endless!  There must be at least 300 of them!
  The line of tinkers finally passes.
  > l
  You are standing in a narrow clearing amidst tall grasses; 
    very tall grasses actually, reaching to just over your 
    shoulders.  A narrow path of recently trampled grass cuts
    across the clearing heading NE/SW.
  > wait a long time
  > l
  You are standing in a narrow clearing amidst tall grasses; 
    very tall grasses actually, reaching to just over your 
    shoulders.  A narrow path of crushed dead grass cuts
    across the clearing heading NE/SW.
  > wait a long time
  > l
  You are standing in a narrow clearing amidst tall grasses; 
    very tall grasses actually, reaching to just over your 
    shoulders.  A narrow path of dead brown grass cuts
    across the clearing heading NE/SW.
  > l at path
  Small shoots of new green grass are beginning to poke their 
    way up thru the old dead grass.
  > wait a long time
  > l
  You are standing in a narrow clearing amidst tall grasses; 
    very tall grasses actually, reaching to just over your 
    shoulders.  Looking NE/SW there seems to be a strangely
    straight line where the grass is a only waist high.

Orchestrating the chages is easy.  Arranging for all the intelligently
readable text is laborious.

>I've though about representing things like paths and rivers as
>collections of line segments and doing intersection tests whenever I
>might have something that hits one of them, but I've got the feeling
>it's more mucking than it's worth...

Yeah, Tho I'd love to be able to damn a river and have it make a
reasonably shaped lake, followed by bursting the damn to have it do
the appropriate damage _and_ reform the river's path.

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...