[MUD-Dev] Object Models

[KevinL]

>>> "Ben" wrote
>     Okay, I am aware that a) this may have been discussed prior, and b) it
> may go a little to far into technicalities, however I feel that this is a
> very controversial subject in the minds of many programmers, as it has a
> major impact in the way the MUD is engineered.
> 
>     Now what I am wondering is how you all handle the objects in your MUD.
> The two camps that I am aware of is the strict old style method of
> definining every single object.  The alternative camp is that which feels
> that you should have multiple types of objects, and then have each object
> dynamically inheriting the properties that pertain to it.  The problem I

We do this! :)

Um, ok.  In Moebius, we define an object (ID 1), which holds the
basest level
 
of things required for an object to "be" - everything has a name, a
short_description, etc. etc.  Object 2 (just looking this up now ;)
is a location - it defines everything that's needed for a room
(which isn't much atm, as all objects can be containers, and there's
nothing really defined for
 
rooms, but there you go).  Object 3 is player, object 4 is creature
(yes, that's the wrong way around), and object 3 inherits from
object 4 - so all creature-related stuff (like the fact that they've
got strength, speed, agility, whatever) gets implemented in 4, 3
carries anything player-specific (which is very little, 'cause after
all players are just more intelligent AI, right? :)

Anyway, we do multiple inheritance - something can inherit from both
creature and room, and become some sort of wierd mimic-like mix of
both (think dragons you can walk into, or treasure chests that bite,
or whatever).

Um.  The wins on this actually come when you make much smaller
objects - for instance, object 8 is the creator object, it has all
the creator methods tied to it (things like "create an object",
"edit an object", etc).  So anything inheriting from 8, gets all the
creator commands.

I envisage groupings in terms of wood vs steel vs flesh, for
instance - you could simply inherit from steel and chest and
lockable, and get a locked steel chest.  There's a couple of cute
tricks that opens up - not least of which is the chance to give
players spells like "steel-to-flesh" as a nice way to really screw
over your world ;) But I digress.

Technically, multi-inheritance raises the whole "collision" thing -
if two objects define the same attribute, we simply use the first
one in the inheritance chain.  I had plans for making that
manageable, but for now simply re-ordering the chain (yes, that's
possible) is enough.  Ideally, I'd like to
 be able to mask out certain attributes with others etc - but it
gets really messy really quickly if you're not careful.

In answer to your questions:

a) How do you handle the dynamic inheritance?  Um.  Inheritances are
set by the creators of those objects - our object referencing walks
the tree of inheritance when it needs to to get the data it needs
to.  Not sure what you mean by "handle".

b) How do you error check ;) Ok, I've got a theory on this, that I
know at least one person dislikes...  Generally, all errors are
reported to the player as "something bad happened", logged to a
file, and in the case of a running mud, it'd be expected that admins
are watching that closely.  This is no different to "how do you
handle a broken object" in any other mud.  How you handle knowing
what's available on every object?  Most of our methods (for
instance, "move") check for the attributes they require
(destination_room, for instance) as they are applied - so if I "move
north", and the object called north has a destination_room
attribute, I'll be moved there.  If I "move ben", and you don't have
a destination_room, then it'll tell me I'm being silly - note, this
is not an error, just a "you can't move that way" type message.  If
you add a destination_room attribute to yourself, then for all
intents and purposes you're a door - you're acting like one ;)

I'm considering, slowly, adding some sort of "interface-like" system
- so objects can enter into a contract to "be" a door, and will then
be treated as one - but I'm not sure whether the gains are high
enough or exactly how it would be applied yet.

c) How do you handle saving/loading - um, we're database-backed,
there's no such thing, so this one doesn't count for us ;).

Your key_monster would inherit from a key object and a creature
object, and would therefore get the properties of both - you can
then mask or augment those properties as you choose.  You could then
allow others to create children of that object, to further augment
or mask.  If anything changes about keys, then it'll change for your
key_monster automagically.

How's that? :) Incidentally, I'm all for more technical discussion,
and am hoping others post more info on how they handle/would like to
handle objects ;)

KL
(mud.bofh.net.au 5000, or http://www.bofh.net.au/mud/)

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