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

[Adam Wiggins]

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

> >Well, possible, but simple sanity checking on load should take care of
> >most problems.  If a field was set to an out-of-range value, that should
> >be rememdied when it's loaded back in.  This is just a good idea in
> >general, in case the data files get corrupted by external means.
> 
> This is one of the things that you typically would do when you write your
> own load/save functions. A persistent object-store should supposedly
> "free" you from these kinds of things, but it doesn't.  That's what I
> was trying to point out...

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.

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.

Another thing is that we have it set up so that some things have their
restore functionality basically just rebuild the thing from scratch.  This
will cover cases where you have some sort of reference like the above for
purposes of speed - the restore functionality for the current weapon field
just says to point it at whatever's in their hands.  (I still tend to not
like this, but you could certainly do it.)

Of course, I have little experience with in-language persistence.  We have
our own handler for all of this: when you set up a field you just define
its type, default value, range, name, and possibly some other things like
units (distance/temperature/time/weight) and the list of enumerations
if it's an enumerated value (ie, a weapontype chosen from a list like
"axe", "polearm", "sword"..)
This allows us to do everything we like, including writing a nicely
formated world file that we can go and fiddle with if we so desire.  (Ie,
if some sort of corruption happened that was so bad that the persistence
handler couldn't recover from it.)

> >Why?  Unless the base system is not sound, it can take large projects
> >from impossible to merely daunting.
> 
> Because I want control over my object structure.  I wouldn't trust the
> persistence mechanisms I've seen as the only way of storing vital
> information, like scenery and user-profiles.  I want to be able to make

So write your own.  Ours was pitifully easy to write - after I did it
(one evening's work) I was slapping my forehead and asking myself why
in the hell we hadn't done that earlier.  Let me tell you, though, I vastly
enjoyed deleting approximately 1,000 lines of special-purpose load/save
code and replacing it with a 200 line handler that had more functionality
and better error-checking.

> major changes (perhaps for efficiency reasons) in my datastructures
> without too much trouble.  But of course, in a large project you might
> be able to use persistance for distribution of entire "meshes" of objects.

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.

> >> (2)The thought "I am designing a world" is your best friend and worst
> >This seems to imply that a complex world is bad thing?
> >I write PC games at work; I get a bellyfull of super-simplified worlds.
> 
> Now, isn't that interesting?  Games is probably an area where complexity
> is a goal (puzzles etc), but only "fun" complexity.  Ok, so I should make
> it more clear:  It is desirable with a lot of variation in a virtual world,
> but you don't want more mechanisms than neccessary.  By being "smart" you
> may keep complexity down by inventing mechanisms that covers more than
> one field. So essentially you want to keep code complexity and use interface
> complexity low, without sacrificing the perceived richness of the world
> too much.

Of course, although I look at it the other way around.  I know exactly how
rich of a world I want; it's up to me to try to create that world with
a minimum of code, CPU time, memory overhead, and effort on the part of
the world creators.

> >With my spare time I want to do something *really* interesting.
> >Of course, complexity of a world doesn't necessarily trace back to
> >complexity of code.  My own goal is to create as complex a world as
> >possible with as simple and elegant a system as possible.
> 
> 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
elements within the world, as opposed to something about the elements
themselves.  In fact, I prefer that the elements be as simple as possible
in order to combine with other elements in as many ways as possible.
Thus, a random world only maximizes the number of elements in the world
while minimizing the number of interactions.

> Yeah, it might, although some probably run hobby projects because they want
> as many happy users as possible.  Some do it out of research interests.

Well this is true, but IMO these people are the ones who put up stock muds
in hopes of getting a large playerbase.  The true pioneers tend to cause
people to recoil in fear at first (as they tend to do when confronted
with anything slightly different from what they are used to) but over time
a few brave souls find out that it's quite a bit better, on the whole, than
what they were used to before.

> I've got a feeling most people do it for the sake of getting the power though.
> (Controlling a world! Rule... :-)  I think that may be the one big difference

Heh, well I was cured of that by my time as immortals on other muds.  Admining
is thankless, difficult, and frequently dull work.  The only time I expect
to hang around on my own mud is playing my mortals.

> between professionals and hobbyists, a professional wanting to rule the world
> and his users ought to loose his job...

Yup...well, you get paid to put up with the BS I mentioned above.
Not a bad trade-off, all in all...still tough however.

> If this is the case, then the only way hobbyists can contribute to the field
> is by trying out totally new concepts (going way beyond another RPG style
> MUD)... Focusing on minor issues like "alignment" is not going to move the
> field by an order of magnitude.  I just think it's sad that so many people
> spend so much effort into minor issues, when there are so many new things to
> explore out there.

Agreed, although keep listening to what goes on here or better yet grab
some old digests.  I can't think of any element of creating muds that hasn't
been discussed in exhaustive detail at one time or another; the topics
range from the very specific (alignment, as you mentioned above) to the
very general (discussing the different sorts of people who play muds,
writing underlying physical models, or event-based muds).