[MUD-Dev] Re: A Small Conceptual Object System For MUDs

[Emil Eifrem]

Sorry for the late reply, but I was absent during the weekend.

At 05:44 PM 11/6/98 , Ola Fosheim Gr=F8stad wrote:
>This is an attempt to describe a small conceptual system which can be used
>for describing the most common MUDs. It is not meant as a design for
>implementation. Just as an extremely simple conceptual model, not even with
>attributes specified.
>
>I'm striving for a model with few, but meaningful, classes and single
>inheritance.

[snip class descriptions]

>CLASS Entity (abstract)
>Desc:   Represents something which the user perceive as an entity. Entities
>generally indicate a need for an identifier.

You describe later in your post how you will subclass `Entity' with classes
describing players, items and locations.  I presume that the general idea
is to further subclass these when you want to create objects such as
swords, flowers, keys, etc.  I believe that is how `it's generally done,'
at least in combat oriented muds.

My concern with this approach has to do with the single inheritance
requirement.  As one of your goals is to "describe the most common MUDs," I
think single inheritance with this model can cause problems.  I know many
muds out there have banana-keys, flowers that are also wands and edible
chairs.  How will you model this without multiple inheritance?

The standard C++ way would be to have the Banana-key inherit from the
classes Fruit and Key, and the edible chair from Furniture and Food.  But
that requires multiple inheritance.=20

An easy answer can be that you don't wish to go into such great detail,
another could be to change the requirements.

However, I believe the question is still interesting.  It has had me
entertained for a while now in my server design.  I know there are lots of
people out there who are building servers from scratch in Java...  how do
you guys and gals deal with these issues?  Comments, anyone?

As for Java, I suppose the obvious solution is to use interfaces.  I don't
particularly like that.  I believe the way most low-hierarchy mud world
objects differ isn't in the messages they accept, but rather in the
implementation.  Both the sword and the banana objects accept the eatMe()
message -- where they differ is the implementation.  I think the busswords
are 'implementation inheritance' vs 'interface inheritance.'  Thus, Java
interfaces wouldn't really help.

As far as I can see there are two extreme solutions to this problem. =20

i) Have only one base abstract class (Entity) and the rest specified as
interfaces (Item, Weapon, Sword, Flower, Banana). Consequences: A builder
that wished to make a banana-key (I assume runtime extension of the world)
would have to provide *all* implementation for the specifics declared by
the Fruit and Key interfaces. Not good for the poor builder. And even if
the object hierarchy was static and compiled into the driver, this would
still mean a *lot* of duplicate code in the world implementation.

ii) A fixed single-inheritance hierarchy. Consequences: Clean and neat
world object hierarchy with minimal code duplication, but with an inability
to support my trendy Banana-Keys. And everyone knows that all respectable
muds either have or want them.


-EE