[MUD-Dev] data structure design in a new mud

Kwon Ekstrom justice at softhome.net
Sat Mar 10 08:08:27 CET 2001


----- Original Message -----
From: "Justin Coleman" <JMCOLE at ENOREE.DJJ.STATE.SC.US>

> I'm working right now on coding a new mud from scratch, and I've hit
> a snag. What is a good way to store objects in a mud? Specifically
> in-game objects, like swords and such. Is it worth the (apparent)
> design time and effort of keeping one central list of all items, or
> is it all right to have smaller lists, one for each room and each
> player that has items?

I don't know about other systems, but I use a global list to store
objects, and smaller lists for each container.  An object should exist
in only 2 lists at a time, the global list and the container that
currently holds it.

Since all objects are in the global list, you don't have to search
each of the small lists to find a specific item globally, and save
resources there, for general use of the object, the smaller container
lists should be used, which saves you the resources of searching
through the much larger list.

Now the way to do this cleanly is simply to write methods to move
objects from list to list, or to remove them from the game completely.
In my own game, I'm using a dispose() method which removes the object
from the global list, and to remove it from it's container.  A
setLoc(Location loc) method removes the object from it's current
Location to a new Location.

BTW, my dispose() method also sets a disposed boolean so I can check
for object disposal.

IMHO this system is best where the files are stored at a secure
location on the server, a game where the visiting client saves the
character would probably be best to store objects solely in the
container lists.

Here's some background information on how objects are handled on my
game, it's written in java, but I'm sure some of these ideas will work
in any object oriented system.

Item, Room, and Creature (my names for the 3 major object types in a
MU*) all extend GameToken, this allows me to easilly write code that
relates to all 3 of them, affects for example.

I'm using interfaces to store GameTokens because I can easily write
additional containers as the game is developed.  Location defines
methods to store GameTokens, Container extends Location and holds
Items, Place extends Container and holds Creatures

Anyway, this should give you some ideas on how to cleanly handle
lists, since that's a critical system for a game, it definitely should
be thought out well in advance.

-- Kwon Ekstrom

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



More information about the mud-dev-archive mailing list