[MUD-Dev] Re: PDMud thread summary
Adam J. Thornton
adam at phoenix.Princeton.EDU
Fri Oct 23 13:46:44 CEST 1998
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.
> > 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.
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.
Adam
--
adam at princeton.edu
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman
More information about the mud-dev-archive
mailing list