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

[Par Winzell]

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!" :-)

 > Christopher commented that they do the same things (assembling their
 > super-class from more malleable single-purpose pieces) -- except
 > that they do it conciously and with intent aforethought.

We actually did start out with the usual subclassing approach, but
before too long it became clear that (especially with a persistent
system) a more data-driven approach was preferable... or at least a
very interesting experiment. So, we made thing.c inherit everything
else and that was that. Pretty much.

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.

After you spend some time playing a Diku, you start developing faith
in the integrity of the virtual reality, in the thingness of things.
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.

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.

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

Now, I realize I'm twisting the argument a bit; at this point, I am
advocating world building through configuration (as opposed to code),
and that's different from one physical object type versus many. But,
of course, there is a connection: with one physical object, the data
dictates the behaviour and so configuration becomes everything. Code
is still a factor, but it is more functional than procedural, and it
is referenced as data more than it is called. In the case of Skotos,
data is made dynamic through our own markup language, which follows
XML syntax, the tags/elements of which are implemented in LPC. This
set of elements can be extended by world builders.

 > When your entire inheritance tree (from an object's perspective) is
 > that you all descend from the same super-class -- how do you handle
 > multi-user security and access controls for editing the consituent
 > components of that super-class?

In our case, and I think mast, there are two levels -- the basic class
that The Powers That Be modifies, and many groups that instantiate or
subclass the basic class, but not really each others' classes.

So builders are affected by changes that we do, but that's it. There
are not really security hierarchies... in my experience it is usually
a mistake to depend, inheritance-wise, on something over which you do
not have control.

Par



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