[MUD-Dev] Object Architecture

[Kwon Ekstrom]

From: "Ben Chambers" <bjchamb at bellsouth.net>

> How do you implement your MUD?  Which objects do you use?  How do
> they interact?  If on Java, how do you divide your projects?  I'm

It's completely based on what you need.  For beginning java I'd
recommand not splitting packages.  If you do split your packages a
simple rule to follow (which would make you life a whole lot easier)
is don't reference objects that are in a package compiled after the
package the object is in.

Personally I divide objects by major purpose...

  Utility - Tokens (Rooms, Items, Creatures) - Communication
  (Sockets, Listeners) - Events - Interpreters/Commands

The list goes on and on....

> wondering because I'm at the beginning phase of design of my own
> MUD, and was wondering how other systems have implemented these
> things.  Any other information about the arrangement of your
> objects within your MUD would be interesting as well.

First off, I'd keep a fairly short class heirarchy (I don't count
"utility" objects which you extend as part of the class
heirarchy... often I start off by extending a utility object... or I
write objects which define the majority of an interface and extend
those... in the long run this helps me code faster.  You have to
remember not to override those methods unless it's necessary, most
JVM's have a slight penalty for over-ridden methods vs inherited
methods... inherited methods don't have a penalty over specifically
designed methods).

I use low end interfaces to type things, and generally have alot of
"small" interfaces to define specific tasks which may be used
repeatedly.  Using interfaces allows me to include them in
multiple-inheritance and separate the implementation from the task.
Often I'll write objects to handle these interfaces.

Take the "HasName" interface... used for referencing Mobs and
Objects by names.  I maintain a list of names where each name is
viable, you compare each name separately so..

There's alot of small details on the subject, but that's now I
handle it.  I could improve performance, but lose extendability in a
few areas... but for the most part, performance hasn't been an issue
and this design scheme has saved quite a few headaches and hours of
coding.

-- Kwon J. Ekstrom

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