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

Shawn Halpenny malachai at iname.com
Thu May 22 13:22:40 CEST 1997


clawrenc at cup.hp.com wrote:
> 
> In <33830A81.167EB0E7 at iname.com>, on 05/21/97
>    at 08:30 AM, Shawn Halpenny <malachai at iname.com> said:
>
> >clawrenc at cup.hp.com wrote:
> 

[ Matt Chatterley re randomized room descs, sizes, weather, etc ]

> >> The problem with virtual rooms, which can be handled is when players
> >> make a change to a virtual room which requires them to become
> >> permanent, or the notice something in a virtual room and refer to it
> >> later expecting it to be permanent.
> >>
> >> eg:
> >>
> >>   > l
> >>   You are in a forest...(desc of forest)
> >>   > cut blaze on tree
> >>   You cut your sigil on a nearby tree.
> >>
> >> or:
> >>
> >>   > l
> >>   You are in a forest...yada yada something about an oak tree.
> >>   ...much later...
> >>   > say "Just go east in the forest until you see the Oak tree,
> >>   and then head west..."
> 
> >Is this something better handled by modifying the room description or
> >creating an object in the room that functions as a tree with a sigil
> >cut upon it?  I envision doing this with the object as a tree.  The
> >room would have a method to allow an occupant to "cut" something on a
> >tree (or some other synonymous variation).  The method then creates
> >the tree-with-sigil that people would see.
> 
> Yup, this would work for most cases, tho I predict problems with
> determining the list of possible permanent-object-creation actions
> (you're going to tend to miss some (sure you can blaze a tree, but
> what about a fire scar? or re-arranging the pebbles on the ground into
> a pattern, or painting a tree with woad?).

Arg...just _have_ to stir the pot don't you? :>  Yeah, a degree of
generalization is necessary to try and cover all the bases, but I think
I'll draw the line at some arbitrary point where I'm content that it may
not be "real", but it's "real enough".  A number of the possibilities
could probably be ruled out when terrain type is factored in.  For
example, in dense rain forest with a couple meters of detritus beneath
your feet, you'll be unlikely to find some pebbles and would probably
opt for notching the nearest tree.  Educated guesses at what can be
excluded are necessary, or there's no need for me to model anything: 
I'd be working with the real thing.
 
> >...As well, making the tree an
> >object makes it cheap to have other trees-with-sigils at any other
> >place in the world, without creating rooms left and right to
> >accomodate a single change in each (i.e. it's fine to modify the room
> >desc if you cut the sigil into ten trees, but say you cut it into a
> >hundred thousand of them...).
> 
> Yup, but now you have a specialised object template for a tree with an
> emblazoned sigil (whose sigil BTW?).

This is easily encodeable within the tree object (a new object would be
created, but would have the original tree as its parent and only change
the variables that needed changing--i.e. whose sigil).  True, there is
absolutely no savings if there are a hundred thousand different
sigils...again, draw an arbitrary line.  The solution may not be the
most flexible, but seems to be flexible enough.

>                                        What about a tree with a sigil
> that been painted with wad?  Or a sigil and painted with lime?  Or a
> sigil and all the leaves picked off on one side?  Or a sigial and all
> the trunk moss removed?  Or just part of the moss removed?  Or all the
> above and the tree partiall pushed over?  Or a tree with an uprooted
> bush tied to it?  Or a tree with a streamer tied to it?

Just modifications to the sigil variable.  Distinct code would exist to
notch the sigil for your particular house (i.e. the sigil variable on
the tree would be set to some value), and the same code can create a new
semi-generic description for the tree, where people of that house would
see the sigil as it was notched, whereas those not of the house would
see a simple notch or patterned disfiguration of the tree.

> You get the idea.  You need a very generalist solution here to record
> permanent state changes based upon generic objects instantiated from a
> generated description for a virtual room.

Quite true.  This is synonymous with trying to foresee every possible
action a user would take in that context (see above) and trying to make
all objects generic enough to accomodate each action.  I'll opt for
"close enough" in many of these cases, since I just don't have the time
or resources to create Earth, Mark II.

> 
> >OTOH, this isn't as much of a factor if there is a fixed number of
> >actual rooms making up the entire world (but this is not my case).
> 
> Next problem, which is not really a feature of virtual rooms or
> permanent rooms per se (tho its worse with virtual rooms):
> 
>   You have an endless grassy plain.  It is uniform and compleatly
>     unfeatured from horizon to horizon.  The composition and
>     appearance of the grass is unvaried.
> 
>   A toop of users and mobiles tramp across the plain, back and
>     forth along a single route.
> 
>   Shouldn't a path be worn into the grass?  
> 
> Next take a simple forest with a path wending thru it.  If nobody
> traverses the path, should it grow over and dissappear?  Should the
> room descriptions be dynamic and change back from a "this is a path"
> type to "this is a forest type" with possibly multiple gradations
> between?  How long should the transformation take?  Can the process be
> accellerated say thru magic?
> 
> Take the same path thru those verdant woods.  A trader sets up a
> caravan route which leaves the path at one point and cuts thru the
> untamed woods as a perceived short-cut.  Caravans travel this shorter
> route with decent frequency -- should a new path form?  Should the
> description of the room where the path diverges change in accordance?
> Yada yada.

I remember there was a good deal of traffic regarding this sort of thing
on the ng's a few months back and it birthed a number of the ideas I've
got now on how I plan to handle such things.  Certainly, paths should be
worn and covered over with the passage of people and time.  Events will
make that doable, and I think an object scheme like the tree-with-sigil
above will allow the same (of course, some additional methods are
required to notify certain objects about people passing through the room
and what not to create the path). This sort of thing would depend on the
terrain of the room to, where rocky terrain would leave much less to no
noticeable path, and grassy plains a very noticeable path...

Yeah, all doable, but I think you have to limit things to keep
complexity in check.

--
Shawn Halpenny

"Caesar si viveret, ad remum dareris"
                            - Latin for All Occasions



More information about the mud-dev-archive mailing list