[MUD-Dev] Persistent Worlds

[Ryan Rhodes]

> Jon Lambert wrote:

> Why?  Simulations need to save state.  Not necessarily intervening
> states.  Look at Civilization, Railroad Tycoon or SimCity.  How is
> state saved?  Simple.  The player hits the save button.
>
> So why didn't I just build in an administrative save button.  Well
> the save button approach doesn't solve the problem of fault
> tolerance.  Nor does it solve the problems in light of concurrency,
> incomplete transactions, etc.  Now it is certainly acceptable for a
> single player of Civilization to roll back to the last time you
> saved.  Or is it?  How about a multiplayer game of Civilization?
> Maybe not.  Because positions and plans may have been revealed that
> are now rolled back.  Generally when one saves such a game all
> action freezes while the system saves its state.  Is that acceptable
> in mud where maybe 20-100+ players are playing?  How often can you
> get away doing that save of state?  Not too often.
>
> Then we have the ugly problem of concurrency.  Concurrency in my
> system is hard-threaded.  Other servers like MUQ and Cold
> concurrency is soft-threaded.  Yet it's still present.


I'm not sure I understand what you mean by "hard" and "soft" threaded
servers???

> Others have played around using using SQL with OO servers and have
> posted their experiences.  A big problem with these experiments with
> existing OO codebases is that by design the objects are not
> reflective.  Internally yes, externally no.  Because of that it
> those experiments I've seen with RDMSs have stored the bulk of
> Object data in BLOBs. Obviously that negates virtually all of the
> query features of SQL beyond simple indexed access.

> The basic problem is this.  The object model is fundamentally
> different from the relational model.  Inheritence has to be fudged.
> In the OO world children know their parents, but parents do not know
> their children.  In the relational world the opposite is true.

<<SNIP>>

> > reflective.  We do not use dynamic inheritence or dynamic
> > attributes.
>
> >   Question: Will this system map to an RDBMs?
>
> If you extend a class with an attribute then NO.  Unless the JDBC
> supports what I call DDL or data definition language.  I may be
> wrong, but the dynamic class loading of Java isn't going to be very
> useful in this situation if that class is one that is persisted.

Our framework provides all the base classes and interfaces.  You can
build objects in the game by extending this framework a single time.
We don't allow mud lib objects to extend each other, you just copy the
code into your directory and right another version.  Mostly our system
is in essense a delegation model, as far as I understand the term.
Objects in the framework don't normally provide any data.  They are
normally interfaces you implement like event listeners.  All that
aside, our objects do need to have there states saved in the DB, and
they do extend the server level structure of the data.

Question: It would seem as though if you can abstractly map a compile
time class to an RDBMs you can use the same process to map a runtime
class.  When you say "NO" above, are you speaking of the heavy
overhead of creating tables and handling the joins within the game or
are you saying no its not logically possible to map between the two?

The biggest issue I have in general with storing a runtime morphic mud
is independent of how its stored.  How in the hell do you handle
objects being recoded for modifications, reguardless of weather you
store it as a blob, in an off the shelf DB, or on a homegrown DB.
This sounds unclear, let me give an example:

You code a wizards cloak with a hood that needs to store a boolean for
hoodup / hooddown.  It proliferates through the game and players have
them saved on their character.  Now you recode it and add a zipper
pocket, also needing the boolean for the same reason.  Do you update
all the records immediately, adding the new field?  Now lets say you
recode it again and tak e the zipper pocket off.  Do you just lose
that field altogether in the DB for all instances?  This is a stupid
example but it becomes alot more relevent with complex items where, in
the recoding you may have changed the use of the data.  Old values may
now be out of range.  Swords become awsomely powerful... etc.  The
alternative would seem to re-initialize instances in the DB when their
cooresponding class has been updated / recoded, but now you've lost
all your information.  How is this handled normally?

> > 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.
>

> Yes.  In fact outside of people working on Mud Servers, in all my
> research I've only found a research project by an IBM engineer who
> was looking at this sort of runtime dynamic database schema.  

The only projects I've ever seen anywhere that use dynamic class
loading outside muds are some applications for managing / automating
ACM style programming contest, where you can code / compile / test
submissions all from within the contest app.

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