[MUD-Dev] (fwd) Mudlib Design

[J C Lawrence]

-- forwarded message --
Path: news.corp.sgi.com!enews.sgi.com!su-news-feed4.bbnplanet.com!su-news-hub1.bbnplanet.com!dallas-news-feed2.bbnplanet.com!news.bbnplanet.com!newsfeed.gte.net!howland.erols.net!news-peer.sprintlink.net!news-backup-west.sprintlink.net!news-in-west.sprintlink.net!news.sprintlink.net!Sprint!209.98.98.14!darla.visi.com!news-out.visi.com!ptah.visi.com!not-for-mail
From: George Reese <borg at imaginary.com>
Subject: Mudlib Design
Newsgroups: rec.games.mud.lp
Organization: http://www.imaginary.com/~borg
User-Agent: tin/pre-1.4-980202 (UNIX) (SunOS/5.5.1 (sun4m))
Lines: 161
Message-ID: <HyU_.248$E6.1220555 at ptah.visi.com>
Date: Tue, 21 Apr 1998 03:40:23 GMT
NNTP-Posting-Host: thumper.visi.com
NNTP-Posting-Date: Mon, 20 Apr 1998 22:40:23 CDT
Xref: news.corp.sgi.com rec.games.mud.lp:29894

I am getting a lot of requests for that advanced LPC book I keep
promising.  Instead of actually producing that document, I thought I
would take some time to produce a small bit of that text--some
hopefully helpful hints on mudlib design.  This is a first stab at
this document, mostly stream of consciousness.  No doubt some of it
will not come out right, so I welcome constructive comments and
questions.  

Most of you are likely using some sort of mudlib handed down to
you--either because you are on an old mud with an ancient lib, or you
have chosen to use a public mudlib, or someone else has this really
cool bastardization of a lib they want to use.  Nevertheless, you can
still take a look at your mudlib and slowly implement changes that
will give you a better more robust design.

* What is the mudlib?

Before getting deep into design issues, let's not forget the purpose
of a mudlib: it is a place to define standard behaviour for similar
mud objects.  In other words, you want all things that people carry to
fall to the ground when they drop them and you want living things to die
when their mortal bodies give out.  You don't want your creators to
have to do tedious work to accomplish simple tasks.  And finally, you
want to hide the complexities of the mud from those creators.

* Defining Your World

The key to doing all this successfully is putting together a good
model of your mud before you start coding.  Your first step should
thus be to identify the sorts of things that will appear in your mud.
You can do this by sitting down with (or sitting at the computer with)
some of the people developing your mud with you.  It does not need to
be admins.  In fact, it would help to have a few admins, a couple of
coders, and maybe even a player in the mix.  Get together and write
down every noun you can think of.  You should spend no more than 20
minutes writing down the things that come immediately to mind; nothing
anyone says at this stage is wrong.

For example, off the top of my head, I would write down the following:
sword         NPC            player          creator         room
door          armour         weapon          food            drink
container     bag            meadow          tree            fishing pole
hut           ship           body            spirit          underworld
domain        sky            entrance        exit            bank teller
Harry         connection     quest           item

Are some of these things identical objects?  Yeah, an entrance and
exit are pretty much the same thing.  A sword is a kind of weapon.
Nevertheless do not make any such judgments at this point; just write
down what anyone says.  Save the judgments until later.

* Organizing the Objects

You now have a disorganized list of "things" you want in your mud.
This list is not the definitive list of what goes in and what is left
out.  It is just a starting point.  You should, however, take a moment
to make sure nothing important has been left out.

Redundancies
The first thing to do with the list is eliminate redundancies.  What
things are identical with other things?  Be careful not to elimate
things that may seem identical yet have subtle, but important
differences.  Chances are you will not eliminate very many objects
from your list at this point.

Specialization
The next step is to identify levels of specialization.  In the list
above, a sword is a weapon.  Harry is an NPC.  A bag is a container.
On a piece of paper, draw arrows from your specific objects to their
generalizations (Harry -----> NPC). 

Commonalities
Identify anything in common among your objects and create a new object
that represents that common behaviour.  From above, we see that food
and drink both have the capacity to heal a living thing.  We should
then an abstraction that captures the concept of healing.  Let's call
it a 'healer'.  Then draw an arrow from both food and drink up to
arrow.

Containment
Look at your list and see which objects contain other objects of a
specific type.  This is not containment in the same way as a bag
containing items.  It is sometimes called a "has-a" relationship.  For
example, a living thing has a body; a body has (wears) armour.

You can use containment to further identify commonalities.  If, for
example, you have forgotten "container" as an object, you should have
caught that omission by now.  Both a room and a bag have items within
them.  That is a common relationship; you can call the object that
handles that commonality a container.

Finally, there is no right answer here, but there are a lot of wrong
answers.  You need to make decisions based on the world you want to
build.  Do not be so quick though to dismiss things as "oh, we don't
need that!"  Edible armour?  It may be convenient now to say nah, no
reason to have edible armour.  Conceptually, however, writing the code
for edible armour is no more difficult than supporting food and armour
separately.  

* Putting It All Together

Look at these two object models

1. From the Nightmare Mudlib 3.x
armour ------->  item
food   ------->  healing
bag    ------->  container  --------> item

2. From unreleased versions of Nightmare
armour ----------->  item
                     protection
food   ----------->  healing
                     edible
edible armour ---->  item
                     healing
                     protection
bag    ----------->  item
                     container
                     closeable
backpack --------->  item
                     protection
                     container
                     closeable

Both models work.  The second model, however, is much more flexible.
Under MudOS or Java, it is impossible to achieve edible armour or a
backpack under the first model since MudOS has screwey virtual
inheritance and Java does not support multiple inheritance.

The second model places behaviour into smaller, better defined objects
that does not mix unrelated behaviour.  This way you can mix and match
behaviours without duplicating any code.

--
George Reese (borg at imaginary.com)       http://www.imaginary.com/~borg
     "In our fear, we make an image, and that image we call God."
	          Antonius Block in The Seventh Seal
PGP Key: http://www.imaginary.com/servlet/Finger?user=borg&verbose=yes
-- end of forwarded message --


--
J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...

--
MUD-Dev: Advancing an unrealised future.