[MUD-Dev] Object and class heirarchies -- are they really necessary?
darius at connect.com.au
Tue Mar 28 10:48:50 New Zealand Daylight Time 2000
>>> Lazarus wrote
> This is where I wound up. My latest design concluded with a base class of
> 'mud_thing' from which everything else was derived. I thought it was cute
> to pick up my test character (could be used for trouble makers as well)
> and put him in my pocket.
This approach, I've got to say, seemed completely natural - it was a first
principle in the very first design docs for Moebius. I'm somewhat
surprised anyone builds these days in systems where objects _are_
fundamentally different. An object is an object is an object.
However ;) I've got to ask - what goes on in the middle of the tree? All
well and good to say "things start from a common ancestor, fan out, then
come back together", but what does that actually lead to in practice?
I've posted on this subject before - Moebius is fast approaching a common
inheritance line, then various smaller building blocks for various groups
of characteristics - want a wooden object, inherit from wood, want creature
stats, inherit from creature, that sort of thing - is this the approach
that the above leads to, or are there other ways to organise the class
hierarchy that work better? Skotos people? Others? Before I commit
myself to a potentially flawed design? ;)
> > 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?
> What is your question? You handle security of any instantiation the same
> independant of whether it is multiply derived from multiple base classes
> or derived from a single super class. Or, are you proposing online
> editing of the base class definition? Now that would be one heck of a can
> of worms.
We already do it - introduce new attributes, and remove old ones, in the
base class and have the changes reflect immediately (give or take
potentially dodgy cacheing ;). That runs smack into "don't give access to
change these to anyone you can't drive over to and thump" territory - once
you can enforce access restrictions between objects at the mud level, you
then have to make social/political/people decisions about who is trusted
and who isn't - you can't fully protect the mud from the ravages of an
insane creator with access to the base object.
It is _very_ handy for being able to change the world physics without
restarts - introduce new concepts (like weight, size, etc) on-line, tinker
with them, remove them again, without actually disturbing
players/builders/visitors. At least in the small scale, and I'm hoping to
keep a 'sandbox' ability somehow so changes can be modelled online in a
safe environment, then switched through to the rest of the mud, once it
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev