[MUD-Dev] Persistent Worlds

[Ryan Rhodes]

Bruce wrote,

> Be sure to read up on GC if you get a chance. :) JVMs don't really
> seem to do some of the more advanced techniques yet.

> Some fairly good starting points:
>
>   ftp://ftp.cs.utexas.edu/pub/garbage/
>   http://iecc.com/gclist/GC-faq.html
>   http://www.xanalys.com/software_tools/mm/

> Personally, I think GC is a great technique to employ within a
> long-lived application like a MUD server.  I don't think I'd want to
> rely on any of the JVMs that I've seen to date though for that.

Thanks for the links.  From the reading it sounds like I need an
incremental GC.  A concurrent GC would be nice too.  I think the newer
JVM's have incremental GC.  I'm not sure if any support concurrent
collection.

> For some work that was done on persistence in Java, you might find
> Sun's Forest project of interest:
> http://www.sun.com/research/forest/

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.

Jon Lambert said something about an approach some muds take of just
saving the whole system at periodic intervals and I have the same
problem with this, although if your coding it yourself I guess you can
use any combination of methods you want.  Saving the normal game at
periodic intervals while allowing builders to save projects manually.

If you really are making the normal game persistent though, do you
make a distinction between the creatures that are saved with a room
who repop there and the rooms current contents?  Maybe I don't
understant persistent muds correctly, but if what you want to save
about a room is that an elf should start up there, then you don't want
that room to save with its contents empty after someone kills the elf.


    Ryan Rhodes






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