[MUD-Dev] Re: Dynamic muds

[Katrina McClelan]

On Mon, 20 Sep 1999, Ben Greear wrote:

> However, you don't get anything for free, and though the descriptions are
> better than many hand-crafted ones you'll find, they seem to be inferior
> to what a decent writer could produce.  My (current) opinion
> is that a well written snapshot in time is more pleasing to
> play in than a more technically correct system that changes, but can never
> be fine prose.
> 

Jumping into the thread a bit late, The model I had in mind involved
having items know how to describe themselves (at varied distances, as well
as "inside" since rooms would be objects themselves), have a
'noticability' level, that would affect what would be noticed in a area
where 30 objects were availible to choose from, meaning that you'd for
sure notice the large ugly ogre, but not always notice the ruby gem laying
in the corner of the closet. (a search would obviously locate otherwise
missed stuff)

Basically the idea is to generate a room description as the sum
of the parts:

You stand inside (an old bamboo hut that has been weather beaten over
decades of neglect). Some (piles of old rotted wood) fill the corner, and
(bunches of cobwebs hang from the ceiling).  In the center of (the hut) is
(a table that has seen better days).  (The door) leads into (the Mirthwood
Forest).

Ok, I'm not a wonderful writer, but someone with a good flair for
describing objects could make this into a pretty good description.
Everything inside of the parentheses is written by author and stored with
the object, which is most of the substance of the description.  It would
take some messy code to make the grammar on the transitional phrases work,
_properly_, but it would be plausible.  But the nice thing is that if
someone moves the table, or otherwise alters it, the description changes
to reflect this.  In terms of code level implementation this seems fairly
feasible.  In terms of building, well I don't know.  It is the same type
of jump in terms of building that procedural based code to object oriented
code. To me it makes more sense to think in terms of a description in
terms of what is there, than to think of what is there in terms of the
description. You wouldn't make a room and describe what was there, you
would make all of the objects that were there, describe them in general
terms, and then place them to define the scene.  At least that's how I see
dynamic descriptions.  It doesn't imply that you're asking the computer to
write descriptions, you're asking the computer to splice together
descriptions from building blocks.  (In terms of this model, the time of
day, weather, etc could be considered to be "objects" even if they were
special cases that were handled differently... you'd supply desciriptions
for "the rain", "the sunshine", "the full moon", "the clouds" etc etc)

To actually answer a question, yes it would take more work to design ONE
room from scratch.  However, once you start getting objects, they can be
re-used.  This is where the building block efficiency happens.  The
caverns filled with stalactites, cobwebs, fungus, and such could be
designed by dropping multiples of the objects in place, rather than trying
to describe the 50 rooms of the cavern.  (the objects would obviously have
singular and plural descriptions, and groupings for internal use).  I
would be more inclined to use this method to design an area, than the
typical static descriptions.  Then again, I'm an engineer, and not a
artistic person, so my opinion may be a bad sample point.  I also
personally tend to struggle with descriptions that are static in nature.
It's all wonderful to describe the Count Dynsinar's evil glare from atop
his perch, but it all looks stupid if you came by 5 minutes after Boffo
and Bubba killed him, and left his bleeding corpse on the floor.  It's
much easier for me to describe the glare as part of the "Count Dynsinar"
object, and know that the system will use a corpse and pool of blood to
describe the area should the NPC meet up with fate.  For that matter, in
this system Bubba could decide to crack the throne into splinters with his
axe, and given a well designed object that "destructs" (the same way the
poor Count destructed into a corpse and blood), the MUD would be happy to
let him, and change the description to make it look right after the fact.
(Object desctruction would be the ugliest part of the building, since
you'd have to allow for different methods of destruction.  The throne is
going to look different after Bubba's Axe smashes it, than it would if
Boffa's fireball burned it).  More work in a way, but the much better
fruits of the labor would tend to make me more interested in working on
it.  There is some evidence to support this notion when you compare the
typical design of areas in an LP that does give the builder a reasonable
amount of versitiliy (at a cost of complexity) to that of a DIKU style
MUD.

-Katrina



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev