[MUD-Dev] Re: PDMud thread summary

Jon Leonard jleonard at divcom.slimy.com
Fri Oct 23 12:47:09 New Zealand Daylight Time 1998

On Fri, Oct 23, 1998 at 01:46:44PM -0400, Adam J. Thornton wrote:
> On Fri, Oct 23, 1998 at 05:54:13PM +0100, Jo Dillon wrote:
> > Steve Sparks (ssparks at enigma.sss.org) spake thusly:
> > > On Thu, 22 Oct 1998 ApplePiMan at aol.com wrote:
> > > > >Database storage/persistence (relational or Object Oriented)
> > > locally and in person.
> > > What platform will be used for the Mud?
> > > 	Linux
> > > 	General UNIX running GNU?
> > > 	BSD	
> >   My vote is for any Posix-compliant Unix (so that we can use things like
> > pthreads and suchlike).
> I second this.  If it's Posixy, porting it will be much simpler.  

There really aren't that many OS features that a MUD needs to use, and with
a modular design, these can often be isolated.

I think the only things that all modules would have to be aware of are
dynamic linking and threads.  There should be compile time options to
turn those off, too.  (My old computer supports neither, for example.)

Filesystem access and player communications should probably be isolated to
singles modules, so the effort of porting them to exotic systems should
be fairly low.

In short, I think portability is important, and with only a little extra
effort we can make stuff portable even beyond the range of posix systems.

Things we'll have to be careful about for portability:

Endianness (sending data between systems might get mangled)
64-bit cleanliness (sizeof(int) isn't necessarily sizeof(pointer))
Sockets and other non-blocking IO
Other things I haven't thought about

Systems that I want to be portable to:

Linux/Alpha (frost.slimy.com)
Linux/Intel (my laptop)
SunOS/Sparc (my old computer)

There'll probably be someone interested in porting to Microsoft platforms,
an probably also to AmigaDos.  Others?

> > > What kind of database is usually used?  
> > > If you use a relational database does someone then create a series of
> > > stored procedure that can be called to help speed implementation. If you
> > > do then would they be something like the implied functionality of these:
> >   I'm not sure I like the idea of a relational database. They tend to
> > be inefficient in my limited experience, and also I think some sort of OO
> > database is going to make more sense for a mud.
> Take a look at PostgreSQL.  It's what I'd been planning to use.  However,
> I'm not sure that using a real database makes more sense than a
> lighterweight persistent object interface like, e.g. Texas Persistent
> Store.

I occasionaly consider designs where the only database-like access is
"load data for this ID" and "store data for this ID".  For something like
that, a pretty simple database will suffice (the plain unix filesystem is
enough).  Depending on what game (or admin) features need more database
functionality, we should probably have more than one database module,
and select one based on the needed features.

> Database performance will be disk-intensive and hence slow.  However, what
> I was thinking is to have the in-memory data structure represent the real
> state of the game world, and have a low-priority queue that commits that
> state to the DB when nothing else is going on, or every X seconds.
> However, this does mean you're paying twice for contention resolution.  The
> DB will take care of ensuring atomicity, so if both Bob and Buffy go for an
> object simultaneously, one of them gets it and the other doesn't.  However,
> if you're using the DB only as backing store, you have to resolve this in
> the game engine first so that the state of the world the players see
> remains consistent.

It's not clear that database stuff needs to be slow.  It's possible to cache
disk stuff in memory, and this may happen automaticly.  Also, using a disk
based structure can speed things up by being more cache-friendly.  Hitting
random locations in memory can be comparatively slow on recent processors,
which is why some disk-based systems can outperform their memory-based

Still, I think the better approach is to start designing the system to
be functional, and then profile it to see what needs to be made faster.
Premature optimization is a big waste of time.

Jon Leonard

More information about the MUD-Dev mailing list