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

Ola Fosheim Grøstad <olag@ifi.uio.no> Ola Fosheim Grøstad <olag@ifi.uio.no>
Fri Nov 13 00:01:59 New Zealand Daylight Time 1998

Emil Eifrem wrote:

> At 05:44 PM 11/6/98 , Ola Fosheim Gr=F8stad wrote:
> >I'm striving for a model with few, but meaningful, classes and single
> >inheritance.

> 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 ma=
> muds out there have banana-keys, flowers that are also wands and edible
> chairs.  How will you model this without multiple inheritance?

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

Yes. This was a response to Jon Lambert's comment on the difficulty of fi=
nding a
common object model. I belive one should be able to come down to a common=
model at least on the conceptual level. Maybe you will have to add additi=
constructs below the Item level during implementation to support your
Banana-key. Still, I think the main challenge is to find some base classe=
s which
would be acceptable to almost all muds and then find out the most common
relationships. My preference for single inheritance is motivated by a des=
ire to
force myself (and others) to think about (or rather rethink) the main
relationships. It is also motivated by a general dislike for the problems
associated with multiple inheritance. Of course, your comment does sugges=
t that
the common object model will have to be fairly abstract in order to remai=
useful for the general mud developer.

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

An alternative is to reflect the most important and used aspect in the
single-inheritance hierarchy. Then leave the more rare special cases to o=
constructs (I believe this is what Mark Gritter suggested?)

Now, the real issue I was trying to get discussed was: How much can you s=
into the LEVEL 0 in my object model without severely hampering the artist=
freedom of the designer? And what is really the "true" basic concepts fou=
nd in
MUDs? Are the _basic_ conceptual relationships the same in most MUDs?

More information about the MUD-Dev mailing list