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

[clawrenc at cup.hp.com]

In <338480E0.167EB0E7 at iname.com>, on 05/22/97 
   at 07:09 PM, Shawn Halpenny <malachai at iname.com> said:

>clawrenc at cup.hp.com wrote:

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

As most of the old-timers here on the list can tell you: I do a lot of
that (and get a lot of it done to me).  All of us here, me especially,
have been known to come to the list with some great idea, only to have
it shot down, analysed and the dissected remnants handed back,
followed by our going back and trashing all the code we just wrote (if
not the whole server), and starting over from scratch.  

You've got a *really* tough audience here, probably the toughest
you'll find in some ways.  I think its possibly the single best
feature and most useful aspect of the list.

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

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

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

  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.

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.

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

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.

Getting into explicitly supporting various permutations leads to
gibbering lunacy and endless complexity.  Unghh.  Been there (well,
not the gibbering lunacy).  No thanks.

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

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.

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