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

[Shawn Halpenny]

clawrenc at cup.hp.com wrote:
> 
> In <338480E0.167EB0E7 at iname.com>, on 05/22/97
>    at 07:09 PM, Shawn Halpenny <malachai at iname.com> said:
> 
> >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.
> 
> I would prefer to do something along the line of:
> 
>   Have virtual rooms modeled much as you documented.
> 
>   Have the descriptions etc for those rooms be generated in a
>     predictable and repeatable manner.

This is what I intend.  Room descriptions for regions where there aren't
true rooms (that is, rooms not built by someone) are generated depending on
their terrain and geographical location.

>   Have a concept of a generic object which can be applied to such
>     a virtual room to cause and track permanent changes to it (eg
>     the blazed tree, the scars, paint etc).

I think this is the sort of thing I mentioned, although I didn't mention
the driving mechanism behind it.  All objects are essentially the same,
the only difference being the variables and methods defined on each
object.  Object B derived from A will have all the properties of A unless
they are overridden, and can add any desired new properties.  This implies
a blaze on a tree can be done with very minimal change (a couple of
strings representing the description and keywords attached to it) to an
already existing pebble design.  

>   Have similar virtual object references which place real objects
>     in virtual rooms along with placement data (a particular
>     arrangement of pebbles).

Same as above.

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

> After that, pretty well everything else should take care of itself.
> Of course the implementation and design of this lot is another
> question, and well worth discussing.  Its a quetion I've explicitly
> avoided by awlays having full instantiation with no support for
> "virtual" rooms or objects per se.  As such my world is much closer to
> a simulation than an on-the-fly construct.

Ah, my assumption was half-correct, with regard to object instantiation in
these rooms.

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

> > > [ necessity of a general solution to record state changes ]
> 
> >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.
> 
> Nooo, I disagree.  I don't see the problem as attemtping to itemise
> all possible interactions -- you'll go nuts down that path -- but
> instead of constructing a system or representation which is capable of
> depicting type basic *types* of arrangements you need.  Once you have
> that, the question of what or whpse sigil, or the paint, or woad, or
> bones, or pebbles or fire scar, or whatever then only becomes a
> variation on a theme of a known change of a known format (ie in some
> manner like other changes) applied to an existant structure in a known
> way.  Its just a matter of determining the basic patterns and rules of
> application at play here.  Then you model that and let the rest take
> care of itself as implicit in the structure you just built.

When reading your preferential method above I realized I might have
misunderstood what you were saying before and got caught up in it before
thinking it all through.  True, itemizing all possible interactions isn't
viable, whereas obtaining a general solution is (though not necessarily
easy).  I agree with your statement of the fundamental principle at work
here; what I was referring to with the "close enough" statement was
that when constructing the general solution, I am prepared to say "close
enough" at a point where I am comfortable with the model so far (and
extending it further requires more work for what I would decide is a
minimal gain).  I'm not implying an all-encompassing, general solution is
not possible, but the getting there may be more work than I need to do to
reach a given level of satisfaction with the model.

> >> 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.
> 
> Yup.  That's the one.
> 
> >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.
> 
> 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).

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

> Don't look at the specifics -- look at the general patterns, and then
> you have only generalised patterns which are applied in specific
> orders and combinations at certain points to create your complexity.
> The patterns are simple, and the support for the patterns is simple.
> Its the *combination* and juxtaposition of the patterns that makes for
> the complexity.

Quite true.  This complexity of the interaction between the patterns is
what I model with the properties of the involved objects.  The objects by
themselves are sufficiently generic enough to let me represent anything
with them.  It's when I start making the "anythings" knock about that some
thought must be exercised.

--
Shawn Halpenny

"Tell a man there are 300 billion stars in the universe and he'll believe
 you.  Tell him a bench has wet paint on it and he'll have to touch
 to be sure."
                                                        - Unknown