[MUD-Dev] Re: MUD Design doc (long)

Nathan F Yospe yospe at uhunix1.its.Hawaii.Edu
Sat Jan 9 15:30:57 New Zealand Daylight Time 1999

On Sat, 9 Jan 1999, Mik Clarke wrote:

:Nathan F Yospe wrote:

:> Like I said, props are all that can be done with my design. 

:I've implemented the detailed descriptions as chains of keywords,
:conditions and descriptions attached to rooms and objects. (Extending
:the Diku/ROM Extra Descriptions).  It makes the search for the target of
:a look/examine command a bit more complicated, but lets me play tricks
:with conditional descriptions and lets me record the fact that someone
:has seen a particular description.

:An example might be a mage examining a sword:

:>examine sword
:A fine blade of polished steel.
:It looks quite sharp.

:...and a warrior examining the same blade...

:>examine sword
:A fine blade of polished steel.
:It has a razor honed edge and is undoubtably the work of the weapon
:smiths of FooBar. This is a rare and valuable blade.

How is this accomplished in code? I have this sort of detail difference,
but it takes place in the client, upon recieving the key for some object
with a known detail, or with corresponding familiarity. There is nothing
different on the server end. Unknown objects will trigger an update from
the server... the text update server is sperate from the game server. If
a client connects and has an update time before the latest update, there
will be a concurrent download of the update as the client connects to
the game server.

:...likewise other characters may be able to see other things.  This
:helps create a need for teamwork, as few characters will have all of the
:skills to perceive all of the clues.

:Recording that someone has seen a particular description is usful for
:subsequently modifying the world - completing quest stages or making
:secret exits usable.

:Consider someone entering a temple...

:Temple of Empark (indoors)
:You are standing in the main chamber of the Temple of Empark.  A pool
:of swirling green fluid sits in the center of the floor, before the 
:statue of the majestic Empark.
:>examine statue
:It stands 60' tall and portrays a sensative young man reclining on an
:elegant throne.  The gods face looks very peaceful and serene.
:>examine pool
:A 30' wide pool containing a swirling green flid.  As you watch the
:ripples form strange, abstract patterns.
:The innkeeper told you that the locals send young girls into the pool
:where they journey to the side of Lord Empark to aid him as he looks
:over the town.

:...and a while later they are in the lair of an evil wizard...

:>examine crystal ball
:A solid sphere of rock crystal. There is a swirl of smoke in its center.
:Looking into the crystal ball you see the hideous visage of Toumar,
:the god of evil and destruction.

:...if they later return to the first temple...

:>examine pool
:A 30' wide pool containing a swirling green flid.  As you watch the
:ripples form strange, abstract patterns.
:Suddenly the visage of evil Toumar becomes apparent amongst the
:swirling ripples!  As you keep watching the image fades and then
:The innkeeper told you that the locals send young girls into the pool
:where they journey to the side of Lord Empark to aid him as he looks
:over the town.

:This is a somewhat more subtle role-playing effect than most Diku
:derivatives aspire to, but I quite like it. 

I'm still working on tuning this sort of effect with my memory net. There
is a lot left to do, as I let this project lie fallow for over a year.

It does add a large personal touch, however, in that a character may have
partial recollections akin to deja vu (an unsuccessful retrieval) or some
sort of imperfect memory, where some details fit, but many have been put
together to fill the picture in. Neural nets are great that way. Even out
of their natural environment, they are powerful.

:> On the other
:> hand, comparing the sizes of a (mostly inherited) prop and a description
:> from a DIKU (probably unfair, as any other codebase would probably use a
:> text compression scheme), I don't see a lot of difference... and any use
:> of a previously defined prop is going to use up one 64 bit long, until a
:> player alters the prop... and even then, there will be a cost of at most
:> 64 bits per alteration.

:Hmmm. So your entire world looks like it was furnished by Habitat? The
:same pine tables and wooden chairs everywhere? Now Diku (or at least my
:Rom->Sunder based derivative) has a restriction that you can only repop
:objects from the same area.  So let's see what I need if I want to model
:an old house - carpets (3 or 4), several different tables (5), dinner
:chairs (2x6), sideboards (2), a stove (1), a sink (1), a double bed (1),
:single beds (3), wardrobes (2), chests of draws (4) - that's somewhere
:around 25 objects, most of which are used only one or two times and
:which don't play any significant game role.  As soon as I want one to do
:something useful (like having a clue carved or woven into it) I have to
:create another object. I suspect the overhead works out at something
:more than just 64 bits per prop instance. 

No repops. There are a lot of variations that are randomized, but things
are mostly unique because of the multiple regions of inheritance. Style,
composition, and structure all factor into manufactured goods, and there
is a lot more than that going on with the native flora and fauna on each
world. Descriptions are dynamic, so even two identical chairs might look
somewhat different in different settings, and inheriting a different set
of factors on the same chair object, which has structure definitions
like size and set of legs, height and back type, and perhaps some major
and minor components information like padding and frame and trim, could
give you an ornate oak chair and a gaudy gold chair and a plastic chair
with softer plastic padding... and the weights and strengths and values
of each would be calculate, and the descriptions would be quite detailed
and even, if I were the author of the style module, artistic. 99% of the
work in describing it would be done by the client, leaving the server to
its vectorized 4D tracking and thermodynamic devolution. You didn't
think I just called it Physmud for no particular reason, did you? Yes, I
know there are flaws here. Tables and chairs don't make sense for some
alien culture, which means a lot of things have to be created from very
simple base constructs. 

Nathan F. Yospe - Born in the year of the tiger, riding it forever after
University of Hawaii at Manoa, Dept of Physics, second year senior (joy)
(On Call) Associate Algorithm Developer, Textron Systems Corp, Maui Ops.
yospe#hawaii.edu http://www2.hawaii.edu/~yospe Non commercial email only

More information about the MUD-Dev mailing list