[MUD-Dev] Persistent Worlds

[Ryan Rhodes]

Jon Lambert wrote:

> I mentioned the method where one uses the RDBMS as a monolithic
> table of rows of Object IDs and BLOBs (or IMAGEs depending on your
> RDBMS terminology).  The BLOBs or IMAGEs are just binary memory
> dumps of the objects.

When I first started, I played with using BLOBs for storage.  I don't
really have any experience with area building, and my friends that do
all expressly said it had to be stored in text.  They say, "Sometimes
its just nice to be able to pull up the files in text."  To me, you
have the same advantage when you store it in a database.  You can
always pull it up.  I guess I'd call this storing it in a
human-readable format.  I tended to go along because I didn't like the
problems of reading in the binary when the code had changed (your
versioning problem).

Now, as I'm making the storage more transparent, it seems as though
with reflection I can chop it up and put it back together just as
easily weather its in human-readable or binary forms.  Additionally, I
am wanting all the building to go on in a GUI online in the game.  So
my question is, if you edit your areas in a GUI that makes it human
readable for you, and the storage is all transparent, is it still just
nice to be able to pull it up in human readable form in the DB?  (I
noticed alot of peoples posts here seemed to be against BLOBs for
being harder to work with)

> And then there is mapping of the OO model itself into the RDBMS.  I
> made a post or two on that.  It involves defining your own OO
> catalogs (much like SYSTABLES and SYSCOLUMNS) and using those
> catalogs to reconstruct an object from multiple tables.  It's either
> heavy on the joins and/or requires building multiple SQL statements
> to retrieve an entire object.  The nice side effect here is the
> presence of an externally accessible catalog of the muds object
> model.  >

Could you elaborate abit more on why the catalog is "nice"?

I'm tending towards this approach, because of the way our system is
laid out.  We have a layered architecture.  The low level server
layer.  The game layer where a particular game is built on top of the
server layer, and a build layer where all of the items / creatures /
rooms of a world are built on top of that.  Now while inheritence is
used in our system, it is only used in the first two layers.  The game
layer provides a set of classes that can be extended a single time to
create the objects for the world, but these objects cannot extend each
other.  I did this hoping to avoid the massive inheritence trees that
spring up in LP style muds.  I'm still going to have the versioning
problems in the first two layers you talked about, if the inheritence
tree is changed in those layers.

The bottom line is this.  Our build objects can only extend game layer
objects so our inheritence tree is locked in for a given runtime
(except for the new children).  Since it could never happen in our
system that an object could have more than about 3 or 4 parents, does
that make the catalog method a good choice for this system?

I also remember someone saying that you lose all the query ability if
you store your objects in the DB as BLOBS.  If I store each class in
the DB as one huge table with every field as a column, instead of
cataloging it with separate tables for each of its parents do I still
lose alot of query ability, even though I retain human-readability?


Ryan Rhodes

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