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

[Kevin Littlejohn]

>>> J C Lawrence wrote
> On Tue, 21 Mar 2000 15:00:08 -0800 (PST) 
> Par Winzell <zell at alyx.com> wrote:
 
> > 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?"

In Moebius, we're facing these issues right now - I'm tinkering with
various different ways to handle the inheritance structure (having the data
actually stored in SQL but presented in objects throws a curve in there
too...  Efficient SQL is painful to create if you have to maintain the
illusion of OO).  At the moment, we're single-inheritanced - one base
object from which everything springs, and it breaks really quickly into an
object for players, an object for locations, etc.  Not real good.

When we manage to get multiple inheritance working (shudder), I've been
toying with the structures we'll end up with.  At the moment, I'm thinking
along the lines of a bunch of smaller objects, which most things in the
world inherit from, which define clumps of attributes.  Example most easy
to deal with is that of materials - define a bunch of objects that provide
the attributes that make up metal, wood, stone, as three different objects,
then just inherit whichever one you want - and presto: you gain all the
attributes of that material.  Same goes for a lot of other stuff - some
things (like basic universal attributes) would exist in objects that
everything inherits from, others would be kind of pick and choose to get
the effect you want.

There's a neat advantage here, which I'm determined to implement - a "stone
to flesh" spell becomes simply something that changes the inheritance - and
can be cast on _anything_, without the object creator having to think about
it.  That provides for a level of mud-world consistency I think would be a
real win, and allow players to seriously invent their own strategies for
dealing with the world.  Also makes for some neat ways to get past locked
doors, or annoy that axe-wielding maniac chasing you ;)

Commands (as per George Reese's article on Imaginary Realities) would be
global, and would simply look for the attributes they need to be supported
on the objects they're applied to - try to sit on something, it'll look for
a carrying capacity.  Define a 'mount' object, and anything that inherits
from that gains that capacity automagically.  This still allows creators to
be facist about what they do and don't allow to happen, but it also
provides for the owners of a mud to make high-level decisions - want all
chests to be sittable on, simply define a chest object, make it inherit
from the mount object, and require builders to use that chest object as
their base.  Change your mind, change the base object only.

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

I'm thinking as I read this thread that security is a two-phase problem -
the technical (how do you determine which objects can do what to whom,
addressed by things such as E and similar, in different ways), and social
(who is actually _allowed_ to make these sorts of sweeping changes, and who
gets clobbered when they screw up).  I suspect trying to solve the one with
the other is, as in the real world, a common mistake.

KevinL
(Rambling again)



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