[MUD-Dev] Persistent Worlds

[Ryan Rhodes]

I'm writing this in responce to a thread of posts from back in Q2 1998
reguarding object persistence and the mapping of runtime morphic
objects to an RDBMS or OODBMS.  In particular I was hoping for some
comments from J C Lawrence or Jon A Lambert as they were the authors
and I have briefly familiarized myself with Lamberts project, but
anyone with comments please speak up :)

As I said in my first post I've been working on a Java Mud Framework
for several years, so my concerns are primarily how the issues you
discussed will relate to my Java project.  Please excuse my attempt to
sort through some Kanga.Nu vocabulary.

What is Persistence?

As far as the post have talked the concept of persistence seems to
fall under two catagories.

  1) World Persistence

  2) Persistent Store Technologies & Object to DBMS mapping

World Persistence being, as far as I can understand it, a world which
persists in state through reboots.  To accomplish this I am assuming
you are somehow running the world directly from disk, which is my
first question.

  Question: In the runtime environment of your worlds do you have both
  a copy of the world in memory and a copy of the world on disk?  Or
  do all games actions directly manipulate the DB?  If you run strait
  from disk, what memory caching techniques do you use to improve
  performance?  Did you implement these yourself are have you used off
  the shelf software?

  Question: Is it even neccesary to run the game strait from disk to
  effectively have a persistent world?  Can you run the game from
  memory and just back the whole changing world up to storage for
  reboots?  Does this make maintaining persistence somehow more
  difficult?

Beyond the question of how your doing it, more importantly is why?  I
mean this most seriously as I'm trying to weigh the advantages.  I
understand your projects are less geared towards PK and more towards
realistic simulations.  The benefits I can come up with so far are:

  1) Players killing their way through a hard area won't be screwed
  when reboots leaves them surrounded with the hordes of monsters they
  so carefully worked their way through one at a time.

  2) Plant life can grow and die in a realistic fashion.

  3) Environments and Buildings can be burnt down, requiring
  rebuilding of buildings, regrowth of forest.. etc

  4) Realistic economies may become more managable.

  5) Shopkeepers can be killed off in raids, leaving there shops empty
  until new tradesmen move to the city.

While pondering this, it occured to me that the developers role might
become something different in this context.  For the world to remain
persistant it would now seem not enough to just store the original
version of a room or object in the DB.  You are now storing the
element in all of its various states.

  Question: If you are storing the original version of a room in the
  DB and it becomes burnt down, are you now storing the burnt version
  and completely throwing away the original?  Or did you store both
  versions from the begining?

In general this principle would seem to persist with the world, that
you are no longer just adding creatures or items.  You are now
required to provide for the way these things are generated and
repopulate.  For instance moving from a fixed list of creatures in a
rooms birth state to an algorythm that generates creatures for a
room... In the case of creatures.  Taking into consideration that my
games aim is not realism, but PK / RP, that brings me to my next
question:

  Question: Do you see putting together a more PK action oriented game
  with a persistent world as opposed ideas?  What elements of a pk
  action world might in fact be less workable in a persistent world
  setup?


Now for the technological concerns.  In your posts on mapping to DBMS
you both talked about the impossibilites of mapping a runtime morphic
language to an RDBMs.  The major barriers being dynamic attributes and
inheritance, and in general a lack of object reflectivity.  Our system
allows online compiling / cloning of objects.  We don't use any script
languages, but implement all components directly in java, by extending
one of the classes provided in our framework.  So, the code of our
game is runtime extendable through dynamic class loading, but
reguardless of weather the classes were compiled and loaded pre-boot
or within the game at run-time, they are still java classes and fully
reflective.  We do not use dynamic inheritence or dynamic attributes.

This would seem to indicate to me that we will be able to provide a
fixed mapping between the objects and an RDBMs.  I believe J C said
mapping wasn't difficult for systems with static structures.  Ours,
while it changes at runtime, still seems this kind of static
structure.

  Question: Will this system map to an RDBMs?

Now in discussing this, I noticed you both commented on how no
persistent storage technologies to date supported runtime morphic
code.  To my understanding, and please please correct me if I'm wrong
here, these persistent storage technologies actually require you to
generate the class from the table.. ie the class must be designed in
the RDBMS.  Once the system has generated a class from this, you can
use it in your code and it will automatically map it back to the RDBMS
for storage.  Now if this is true, it would seem its not just runtime
morphic systems that won't map, but all systems which are adding
classes at runtime.  If anyone knows more of how these work, please
illuminate me.

Of the technologies I've found so far that are for java are Java Blend
(Sun), JStore (Borland) and something called Object Store Pro or
something like that.  If anyone can point me to any other Java
persitence technologies on the market I'd appreciate it.

Reguardless of weather an easy cheezy solution exist using off the
shelf parts, I'm fairly convinced I can map these classes to an RDBMs.
I followed an interesting link, I can't find now, to a site J C
posted.  It was a tutorial of nearly an entire system for mapping from
java to RDBM's and surprizingly it was almost identical to the method
I was already using to store them to ASCII text.  As is I'm only
having one major problem....

  Question: How would you suggest mapping collections to an RDBMS.
  Normally every field would map to a column in the corresponding
  classes table.  An object field would end up mapping to a forein key
  reference to another table where that object would be stored.
  Collections like java Vectors, Hashtables, and arrays seem to pose a
  problem.  I don't think I would want each object in the collection
  to map to a foreign key in the previous item in the lists table.

Example: Inventory is a linked list.  I would like for player to have
a forein key under inventory for looking up an inventory table for
that player.  However the algorythms described thus far would leave
the inventory field in player as a reference to the table for the
first item of his inventory, not the whole list.  That item would
contain a foreign key to the next, and so on.  Is there no elegant
solution to this, or am I just going to have to write a custom mapping
for a bunch of different types of classes thats different from my
general mapping algorythm.


My last questions are reguarding the use of databases as a method of
storage for muds in general.  I can understand the want to effectively
push all the burden of file corruption and some of the synchronization
issues on to the well tested DBMS.  I can also see how it would manage
alot of your indexing problems for you.  For example when you want to
change the Object ID of an item and want the DB to automatically
change the ID in all the rooms and players that have the item.  I had
to write my own tools for this sort of thing.  My main questions are
with the advantages for builders...

Question: Do you do your building from within the DB.  Do you have
online building in systems where the game is stored in a DB?  Are
there any systems that use a DB for storage and have provided a
graphical environment for Building that hooks directly into the DB?
Are there any systems with a GUI that allow you to build while also
being online? (with the Builder GUI interacting with the game) and in
General ...

  Question: Is it easier to edit pfiles and area files from within a
  DB or a text file?


As always, I appreciate any and all comments,

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