[MUD-Dev] Persistent Worlds

[Miroslav Silovic]

"Ryan Rhodes" <ryanshaerhodes at hotmail.com> writes:

> Too bad this is research and not a comercial package, but it's a
> pretty exciting picture of what's to come.  It has fine grain
> control over which variables will be persisted.  It stores the code
> for instances along with them and handles all the versioning for you
> as well.  All you do is call a function whenever you want to do a
> save and it saves the entire runtime state.  It even sounds pretty
> fast.
 
> I have one problem with using this or any similar approach in my
> system.  While this seems to allow you to select exactly which
> classes will be persistent, it does not (as far as I can tell) allow
> you to select different classes to save at different times.  For
> example, I want to have builders work online in a sort of project
> system.  Builders can create projects, which allow them to walk
> around in a private coordinate space, creating rooms, items and
> creatures as they will appear in the game.  Other than not being on
> the standard map, these projects appear as normal areas in the game.
> Now sometimes you will turn events and AI's on in your project so
> you can test it out.  Maybe you want to play through a quest your
> writing in your area or something like that and you want all the
> creatures walking around and acting.  You don't, however, want any
> of this to save to your project.  I think its probably best if you
> save your project manually.  You turn it on and test it out and when
> your done you reload it from the saved copy and go back to building.
> So approaches to persistence that make it completely transparent,
> just saving the entire Runtime state of the JVM seem like they don't
> allow this.  Even though it allows you to select exactly which data
> will be saved, it doesn't allow you to save different data at
> different times.

(hope you read my previous post before reading this one, since it
explains the things you need to understand this)...

For my persistence system, I'm using multiple databases. Each database
class is simply specified through a standard API - basically a set of
notifications it recieves from the persistent objects, nonloaded
objects ('proxies', although that's not quite what they are, due to
the morphing), and transaction controllers. You instantiate these
classes to access the actual databases (as well as do tricks - read
below). It's completely up to the database to react to these messages
any way it wants, as long as it loads the object when it's requested
to load.

Another thing is that each database object contains a mathed pair of
encoder/decoder class pointers. This means that each database can use
its own tricks to encode. Furthermore, database may point to other
databases and delegate actual backend work to them (basically, it can
just modify the underlying database behaviour).

This approach has some interesting features. For example, you can
create a database object that accesses one database read-only and
writes into only the differences into another db. You can use this to
implement all sorts of version control. You can also use this to
template a large number of objects using a pseudo-random object
factory, then save the diffs into a db. You can even expire these
differences, allowing you to, say, read tracks of the people who
passed through pseudo-random forest, but fade them in a few days.

You can also implement fancy encoder/decoder pairs, so you cleanup
sockets and other nonpersistent information before saving your
objects. Also, I've implemented object caching as a cache database
that overlays some backend db.

Now I only wish I could track this annoying crashbug in GC.

--
How to eff the ineffable?
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev