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

[J C Lawrence]

On Sat, 09 Jan 1999 22:34:11 +0000 
Mik Clarke<mikclrk at ibm.net> wrote:

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

Loosely, there are two data models in client/server systems, and
since you can devolve most data relationships to C/S systems if you
look at them funny enough, you can look at the relationship between
a player character object and the objects it manipulates in the the
game as a client/server system, marking the character object as the
client and the rest as "servers".

This view had a pleasant side effect, it enforces the model of the
human player's only connection to the game being thru the funnel or
filter of the character object.  Further, it enforces the (wise?)
design model of the character object acting as the interpreter for
ALL the IO that the player receives.  

What does this last mean?  The server can't send IO directly to the
player any more as it has to pass thru the character object first.
Further it encourages the code model where interface and
presentation intelligence is removed from the server to the client,
with the result that the character object becomes increasingly
intelligent about such things and the data items it processes
(rooms, objects, EQ, etc) increasingly simple if not non-existent in 
those regards.

  Why should a room care how a character or player perceives it?  It
is an artificial division and badly breaks the relevent XXX design
pattern (the Gang of Four book is at home and I'm not).  

  Why not have the room (or whatever) contain all the relevent atoms
of its own description and then have the client/character assemble
and present those atoms in a way intelligent to *that* character?

This makes objects responsible for their own data public contents
(ie their attributes and method return values), and not for what is
done with them.

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

One of the other nice side effects of this approach is that it then
becomes very simple to have anonymous objects; localised namespaces
if you wish.  For instance:

  For me names are not global (there are a very few exceptions).  As
such objects don't have default names.  The character you ran into
at the castle is only "Bubba" to you because that is what you
explicitly named him.  You have no idea what he calls you.

    > l
    You are standing outside of a ramshackle store.  A sign,
    creaking in the wind, reads, "Bubba's Inn".
    > name store moshpit
    Okay.
    > l
    You are standing outside the moshpit.
    An ugly troll approaches from the south.
    > name troll sucker
    Okay.
    Sucker says, "Hi!  My name is Boffo!  Want to go do the castle?"
    > l
    You are standing outside the moshpit.
    Sucker is here.
    > kill sucker
    ...etc.   

Notice however that the "sucker" name assignment is private to the
character that you are playing.  It won't resolve for the troll, for
any other players, or for the player of the troll.

ObNote: Namespace virii (eg objects that
autoregister/de-register/broadcast or otherwise process a
character's namespace, say attached to a trash object that is handed
about) are kinda fun and *really* *really* annoying.  They can
definitely screw up your whole day.  I'm still argueing how tight to
make the namespace sandbox.  I want it usably open but still fairly
protective against namespace virii.

> Hmmm. So your entire world looks like it was furnished by Habitat? 
> The same pine tables and wooden chairs everywhere? 

Yep.  In fact the entire world pretty well looks like the product of
a production line nightmare.  Part of this is due to the fact that I
expect (hope) that the players will extend the visuals themselves,
thus defining and characterising the world (free user programming
and a well defined protocol for pasting spiffier presentations atop
generic objects).

--
J C Lawrence                              Internet: claw at kanga.nu
(Contractor)                             Internet: coder at kanga.nu
---------(*)                    Internet: claw at under.engr.sgi.com
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...