[MUD-Dev] Persistance/stability

[Adam Wiggins]

[Chris G:]
> [Discussion of state saving, in his followup on UO/Graphics MUDS.]
> 
> Reading all this stuff on what UO saves and what other MUDs save or do
> not save, caused me to realize that I don't really have a grasp of just
> what other MUD systems *do* save. This was probably good when I was doing
> AmigaMUD, since it didn't occur to me to not save absolutely everything.

Heh - sometimes it's better to be ignorant of the status quo.  I thought
the same way until I started coding for the mud I was playing and
suddenly realized that the whole thing was a lot lamer than I had imagined..

> I think of it as a persistent programming language (I saw that term a
> few years back, probably in a SIGPLAN Notices or something), so you
> actually have to go out of your way to make something not saved (you
> have to explicitly reset it). When I first joined the first version of

Which is ideal, I think.  When the 'common' mudbases in question were
developed, you had to be careful what you saved to disk, and when.  Now,
with massive amounts of RAM, fast RAIDs, excellent software caching and
whatever else, saving the state of an entire world is perfectly feasable.
But, as usual, people aren't quick to abandoned the tried-and-true method
(particularly since the entire design of many muds would have to be
changed in order for this to work).

> this list, there was a lot of discussion (like now) with Chris L about
> databases, commits, and lock/lockless stuff, and that just sort of
> re-inforced my notion that other MUDs were persistant languages too.
> It's clear that Diku's aren't, but couldn't we consider MOO's to be?
> How about Mushes? I believe that Mushes don't save over a reboot (?),

I thought they did, it's just that they have very little data to save,
due to pretty simple attributes on the world objects.  Maybe I don't
know what I'm talking about, though.

> but get the impression that MOO's do. LP's don't, unless explicit

The MOOs I've seen never would have worked without world saving.  Again,
game design drives the function of the db...

> saving to files is done by LPC code. Am I vaguely correct here? What

LP is probably the most complex as far as individual objects of everything
you've mentioned.  Besides probably not being very handy hardware-wise
when it was first released, I imagine that you could cause some real
problems by saving things on objects that weren't explicitly specified
by the object creator.

> Adam also mentioned that most MUDs don't stay up for more than a week
> or two. That surprises me, too. I would have thought that LambdaMOO
> would have been up for at least months at a time. Given that most don't

As I think I've already mentioned, Lambda represents an extreme that resides
on the fringes of 'mud' as I've defined it.  Obviously, simplcity gives
you stability, and complexity...well, the way most muds are programmed,
brings along frequent crashes.  Web servers and irc rarely crash.  Some of
the first LPs I played crashed so much that I could barely play them.  (Ie,
average uptime of < 1 hour.)

> save everything over reboots, that sort of corrupts the impression of
> a real "world", doesn't it?

Absolutely.  My hope is that the next generation of mudbases will take
this sort of persistance for granted - a fundamental part of the db.
At that point we can forget about all this crap and get back to work the
darn game.
Incedentally - we're planning on writing a small gateway wrapper for our
mud that will be able to hold onto descriptors when the mud proper crashes,
ala Valhalla.  Since the mud boots in about two seconds on our primary
server right now, we *should* be able to program it well enough that
a 'crash' will just look like a two second pause, which is hardly noticeable
given the haphazard timing of messages (no pulses, anyhow) to players.