[MUD-Dev] MUD Design Fundamentals (Was: Looking for books...)

[Ola Fosheim Grøstad <olag@ifi.uio.no>]

>[Ola:]
>> [Adam:]
>> >Hum...assuming you have good base functionality (resolving references/pointer
>> >to other objects is a prime issue) it should be difficult to make blunders.
>> 
>> References were the ones I was thinking about.
>
>I still don't understand.  If there's a bug in the code, there's a bug
>in the code.  This doesn't have much to do with saving and loading, assuming
>of course that your persistence and reference resolvers are solid.

If there is a bug in the code, you fix it, but fixing the datastructure isn't
so easy, is it?  So you have wipe.

>Perhaps you need to spend some time dusting up your persistence code, then.
>We have ranges and default values for every possible field, and it works
>out basically like this: if the field is out of range, set it to default.
>If the field does not exist, set it to default.  When resolving references,
>check to see if it points to a valid object.  If not, set it to the null value.

Uh... But these are the kind of bugs that are really easy to pinpoint.
Bugs in a graph-like structure is a lot worse..

>One place this doesn't work is dependant fields.  For example, you have a
>reference on the character object which points to their current weapon object.
>Somewhere else you have a pointer to what's in their hands.  If these two
>pointers are not equal to each other, bad things happen.  This is, IMO, bad
>coding.  This will cause you *far* more problems than just in the area
>of persistence.

Well, in any real life computationally intensive system, you'll often end
up duplicating information for cheer speedups, if for no other reason than
to ensure good utilization of processor caching.

>Another thing is that we have it set up so that some things have their
>restore functionality basically just rebuild the thing from scratch.

Yes, and this is what I was talking about, wasn't I?

>Here's a way to look at this whole thing:

><JCL mode ON>
>
>  A mud world should, ideally, never crash or reboot.
>
>  A persistent DB is loaded exactly as it was before the crash or reboot.
>
>  From the viewpoint of anyone in the world, a crash or reboot will appear
>  to be a minor pause which leaves the world unchanged, as opposed to some
>  sort of massive reset of the world.
>
>  Ergo, a persistent DB causes the mud world to reach the ideal state
>  (see #1) without having to rely on never crashing or rebooting.

????? If the program crash, there is something wrong with the state, no?
So what good is there in saving it, and starting up the program again?
One way to resolve this is by logging events, actually you have to do this
as state is not enough, you need history as well.  (of course this is a
field of it's own, very useful for banking systems, where there are large
fines that has to be paid out for every second the system is down)

>> Define "a complex world"!?  A near-random world would be truly complex,
>> wouldn't it? :-)
>
>No.  The kind of complexity I desire is related to the interaction of the

That was a joke.  Entrophy.  You cannot make a general compressor for white
noise, hence it is truly complex.

>Thus, a random world only maximizes the number of elements in the world
>while minimizing the number of interactions.

Randomize the interactions. :*)

Ola.