[MUD-Dev] Object and class heirarchies -- are they really necessary?

[J C Lawrence]

On Tue, 21 Mar 2000 15:00:08 -0800 (PST) 
Par Winzell <zell at alyx.com> wrote:

> J C Lawrence writes:
>> This surprised me as I'd been tending in that direction myself
>> without ever having noticed.

> I believe your precise expression was, "You bastards!" :-)

Obviously one of my more articulate days.

> My favourite benefit of this approach is the same one that
> e.g. Diku has over most LPMuds... that you nail down in the
> implementation of the single physical class the entireity of the
> feature set... and as a consequence, all physical objects are
> guaranteed to respond sanely to a known set of actions.

Good point.  To parrot George Reese, there are also good effects in
the handling of command grammars.  It really kills "Guess the verb,"
in most of its variations, encluding my favourite, "What will XXX do
here?"

> After you spend some time playing a Diku, you start developing
> faith in the integrity of the virtual reality, in the thingness of
> things.

Constancy.  Hobgoblin of little minds and the source of the
familiarity/contempt homily -- and awfully reassuring.  Think about
it:

  You want your players to take the command set and basic
functionality of your world for granted.  Ergo, you almost always
want your game to follow the route of "least surprise".

Aside: While surprise is good, its a quickly tiresome quality.  You
don't want to be surprised everytime you open a door, walk more than
10 feet, or notice a new grain of sand on the road.  Spend surprise
where its most effective.

Once you get your players treating those command and control areas
in an off-hand "of course" manner, you've won that small battle.
You know that the mechanics of playing your game are no longer
distracting your players from actually playing the game.

This of course doesn't state that its helping them or making it easy
either.  Just that your command processes are now no longer getting
in the way.  Ceasing to be offensive is one thing.  Starting to be,
umm, attractive, is another.

> I believe this is one of the most important attributes an
> imaginary world can possess. In fact, it is not so dissimilar to
> the challenges an author of (especially speculative) fiction faces
> when she sets out to develop a world: the world can be crazy, but
> if it does not have internal consistency, it leaves the
> reader/player feeling almost ill.

True.  

As an aside I added a bunch of links to the Library a while back on
the area of internally consistent and detailed world design in
particular.  Some are under /Top/Game Design/Tools/Astronomical:

  http://www.kanga.nu/library.php3?viewCat=145

Have a look at Epona in particular.

> LPMuds usually fail miserably in this regard. Where on a Diku,
> things are constructed basically through configuration, LPMuds are
> very much programmed. While in theory the Diku model is a strict
> subset of the LPMud one, in practice most LPMud world builders
> implement behaviour of their objects by assembling ancient
> fragments of code taken from examples and each other, and filling
> in the cracks through guesswork.  As a result, walking through the
> average LPMud area is an assault of sub-standard code, reality
> flickering like a cheap monitor.

If you've spent any time on LambdaMOO, you get this treatment to the
ne plus ultra.  All the worst characteristics of finely grained
inheritance trees and a long long history of orgranic user-derived
growth/hacking tend to excell there (or did a couple years ago when
I was last there).  This is not to say that LM is not utterly
incredible.  It is incredible in both its successes and failures.

> So though in theory, with competent and _disciplined_ developers,
> the LPMud can be everything a Diku can and then some, in practice
> there's no question which code base I prefer to be a player
> in. Since Skotos uses DGD, an LP driver, we must attempt to
> conjure up this discipline largely through our world
> implementation (and developer interface).

Beatings will continue until code constancy improves.

> ...in my experience it is usually a mistake to depend,
> inheritance-wise, on something over which you do not have control.

True.  That was one of the sources of the design requirement for
Murkle that features must be programmable without requiring source
access to any other objects.

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


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