[MUD-Dev] using DB to store game state

[J C Lawrence]

On Mon, 26 Jun 2000 16:21:14 -0500 
Eli Stevens <wickedgrey at wickedgrey.com> wrote:

> The DB stores all the data about the world (X monster is at Y,
> carrying Z).  The DB also stores all the pending events that would
> modify the world (X monster wants to drop Z).  When an event
> begins execution, it is flagged as such, and when it completes the
> changes are comitted.  This leaves the DB storing the same info as
> before; the (new) gamestate and the list of pending events.

There is extensive discussion of exactly this model and its various
concerns in the archives, both for my own design (search for
"compare & commit"), and Jon Lambert's.

> I am considering using MetaKit <URL: http://www.equi4.com/ > as my
> DB.

I'm not familiar with that product in particular.  There are however
several other similar products (some listed in the Library) which
you may like to compare it to.

> It features "atomic commits" (my term, I think)...

Nope, old term.  You might like to also look at the definition of
ACID as relates to databases.  From the TPC-W Frequently Asked
Questions (FAQ) (happened to have a convenient definition):

--<cut>--
The system properties of Atomicity, Consistency, Isolation and
Durability (ACID) are those that keep data which is protected by
these properties from being corrupted due to interference with other
concurrent users, applications or failing system components. These
are important because people want to know that their data will be
there tomorrow. Jim Gray explained it best, "All of the mechanisms
that make databases more durable are very important. They are
certainly in any database system. If you use a word processor you
have a `quit' button and a `save' button. The `quit' button is
(equivalent to) `abort the transaction'. The `save' button (means)
`save the transaction and make it complete'. If you are drilling
holes in a piece of metal you want the hole to be in the metal and
the database to know that there is a hole in the metal. Transactions
are important for manufacturing, they are important for all of the
financial things we do, (such as) fund transfers, they are important
for taking a book out of the library"
--<cut>--

> ...which means that it keeps two copies of the data on disk, the
> old version and the new.  

You might like to look into the area of rollbacks and how they
influence DB design and transactional recovery (there are several
methods).

> The combo of the two would mean that my DB could only be corrupted
> from within, which to me seems like a good idea.  :) 

There are several transactional databases (which is what you are
talking about) databases listed in the Library at Kanga.Nu.  Even
more are listed in the Free DataBase List, which is also in the
Library.

> It also means that if an event crashes the mud, I can go back and
> examine the event flagged as executing (or the next event to
> execute, same thing) and hopefully figure out what is going wrong.

Yup.  You might like to examine the previous list traffic on my
dispatchor/executor/thread_pool model I used for Murkle as the area
of failing events and their proper handling was well examined (tho
"failing" was defined differently than "crashing")..

> I have reservations about this scheme, because objects (I am using
> C++) in memory will either not be persistent (they would be
> reconstructed from the DB for every event that needed to touch the
> object) or I would have to devise a cashing system that would mark
> when an object should be reconstructed.  Another possibility would
> be to eschew OO, but I don't like tha idea very much.

Have a look at the approach the Texas Persistent Store takes via
Pointer Swizzling.  I doubt that you really want to get involved in
Pointer Swizzling with MetaKit (on quick glance it takes a different
tack), but the approach that Texas' took for cacheing the working
set are pretty good.

--
J C Lawrence                              Internet: claw at kanga.nu
----------(*)                            Internet: coder at kanga.nu
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...


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