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

Shawn Halpenny malachai at iname.com
Thu May 29 10:26:02 New Zealand Standard Time 1997


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

[ instantiation of objects in real and virtual rooms ]

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

Yep.  It's very unlikely that all the trees that make up the rain forest
exist as objects until something is actually done with them.  Perhaps in
cases like this, the necessary generalization can be handled by the code
that creates the distinguishing mark, since this code can be made aware
of what implicit objects exist in the room (in a fashion similar to
Diku-style extended keywords and
descriptions, I suppose).  For example, "blaze pine" wouldn't work, but
"blaze yew" or "blaze elm" or the generic "blaze tree" would (and would
"blaze tree" prompt for which tree?  Probably not unless there were
other blazed trees in the room.).

[ representing a very large world efficiently ]

> [clawrence:]
> >> 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:

[ watching the grass grow and creating sensible, intelligent
descriptions
  depending on each state ]

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

Aye, and truthfully this isn't terribly high on my list of things to
do.  I'll settle for semi-intelligently readable text, where the object
representing a portion of the path will recreate its description on each
state.  These descriptions will not be seamlessly worked into the
existing room description (yes, it would be nice and I think that's sort
of what you're getting at, but I'm happy enough to have them appear
apart from the generic room desc):
    > 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 NE/SW across the
clearing.

    > wait a while
    > l at path
    Small shoots of new green grass are poking their way up through the
dead
      grass.

    > wait
    > 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 only waist high.

It's very similar to what you'd written, but the distinction is clearer
between the room and what's "in" the room.  I'd argue that the text
remains intelligently readable, but it's not _seamlessly_ intelligently
readable.  I think this sort of thing is inherent to orchestrating the
changes in the path?

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

Hm.  I think creating a reasonably shaped lake is easy enough, since the
surface of your lake will essentially be flat (I'm assuming that if your
world is round, it's large enough that the curvature is not immediately
apparent when looking at an expansive, flat surface).  You could
essentially do a 3D flood-fill starting at the dam and filling in the
reverse direction of the river flow.  Fill the lowest region of
elevation and progress upwards until the desired volume is reached (or
the dam breaks in which case you do the reverse).
Requires some notion of volume of water and I think it'll get ugly as
hell so I probably won't bother with it, but it's a nice idea.  When
reforming the path, perhaps something like a fractal-terrain generation
but in 2D to generate a slightly modified path from the huge increase in
water volume flowing along the old riverbed.

--
Shawn Halpenny

"People that are really very weird can get into sensitive
 positions and have a tremendous impact on history."
                                    - Dan Quayle



More information about the MUD-Dev mailing list