[DGD] Persistance

[Noah Gibbs]

--- Robert Forshaw <iouswuoibev at hotmail.com> wrote:
> > > What you are describing is the theory of game
> > > balance.
> >
> >   Well, sort of.  Not that I've heard any real
> theory
> >on that topic put forward :-)
> 
> I just meant it was under that topic, and didn't
> appear to have anything to 
> do with persistance.

  In the sense that persistence isn't required to do a
"no resets" game, you're right.  Phantasmal, for
instance, does "no resets", but isn't usually run
persistent (it can, but I don't do it that way on my
own MUD).

  However, those approaches are usually combined
because most non-persistent MUDs divide state into
"permanent state" (which gets reset) and "transient
state" (which you never bother to save to disk, and
which dies on reboot, because you're going to throw it
away next reset anyway).  You're right that you can do
this on a non-persistent MUD, but few non-persistent
MUDs do.  Persistent MUDs, on the other hand,
frequently do.

  That's because zone resets cause some problems that
become obvious very quickly on persistent MUDs, but
less obvious on non-persistent MUDs.

  This would be one of those "subtly different" things
you were asking about.

> > > >   There's no reset, no respawn, no destruction
> and
> > > >remaking.  It's just, y'know, there.

  Here we go.  I confused you here.  When I say the
above, I'm treating the phrase "destruction and
remaking" as a unit.  Like when you save a list of
object numbers in a file for a player inventory, but
destroy the underlying objects.  Stuff like that.  Or
when you save to a file, restart the MUD, and reload.

  It's not that there's no destruction (as you say,
some effects require it).  It's that the
destruct-and-remake cycle, very common on most MUDs,
almost never happens on persistent MUDs.

> I also think that respawning is manditory
> unless you plan to be 
> writing new game content every day for
> the entire
> lifespan of the MUD.

  Well, if the basic activity on your MUD is killing
monsters, then yes, you're right.  I'll simply leave
the name "Blood Dusk MUD" as an example of a
surprisingly traditional MUD that doesn't work that
way (well, mostly).

> >[...]Skotos seems to consider a feature (and I
> >certainly do), though you may not:  you can make
> >objects entirely without having to write code. 
> >While
> >that approach doesn't scale to really complicated
> >objects, it's a good way to make 95% of the objects
> >in a given MUD.
> 
> I don't personally consider it an advantage.

  Didn't figure you would.  You don't seem to have
much experience with just how horrible most MUD
builders' code is.  There's time for you to gain
enlightenment in that respect.

> I wouldn't be comfortable if 
> the builders on my MUD didn't actually know
> how to code. Setting attributes 
> for me has always been the easiest part of MUD
> building.

  If your MUD builders are required to be competent
coders, you're cutting your pool of builders to less
than half of its original size.  If they have to be
good at writing prose *and* coding, you're cutting it
to more like a tenth, especially if you don't pay them
(and nobody does).

  If your builders are only required to be tolerable
(or barely-tolerable) coders, then you want to make
them write code very rarely.  If you can give them a
simpler interface, you do.

  This is where you get to tell me that you'd never
accept anybody that wasn't a good coder to build on
your MUD.  I know the drill.  However, it's also where
I get to laugh at you since I know how hard it is to
find good builders who *can't* code, let alone the
ones who can. :-)

> It seems like a lot of work, writing a
> mini-interpreter for scripts etc. and 
> for datafiles, just so you can evade the
> 'effort' of writing actual code. It 
> doesn't make much sense to me.

  That's because you don't like the idea of altering
object attributes on the fly.  I *really* like the
idea of being able to change an object's description
or weight or damage rating using a single command on
the command-line.  Having a data format instead of all
code starts paying off very quickly in that case.

  And you're not avoiding the effort of code.  You're
avoiding the error-proneness of code, and the slowness
of code, and the security requirements of code, and
handling errors caused by code...  The nice thing
about a data format is that you can be really fascist
about it.  Not an integer?  Ditch it.

  You can handle all the same problems with code, but
debugging all the error handling machinery is more of
a pain.  Again, I know.  I do both.

> > Plus you can alter the
> >objects more easily after creation since your
> >changes stick, and you don't have to make
> >changes to the code.
> 
> That is one advantage, sure, but with an object
> manager keeping everything 
> in task it isn't so hard to make an 'update'
> command to recompile an altred 
> object.

  Nope, that's pretty easy, you're right.  However,
given the choice of a one-line update command or
editing a file and recompiling, I'll take the one-line
update command.  Again, that's what my MUD does.

> >   Here's the different bit -- you don't have
> > to set
> >the attributes in a way that's reproducible.
> >Your way
> >involves writing code that knows how to set
> >attributes.  Our way involves setting the
> >attributes
> >in any way *once*, then never worrying about
> >it again.
> >  Not even to save or restore it.
> 
> But you only have to set attributes once 'my way' as
> well.

  Nope.  You have to write code that knows how to set
it once, which is different.  You still have to keep
the code around to keep setting it.  Your code has to
keep working -- not just the line that sets the
attributes, but the whole file, 'cause otherwise it
doesn't compile and the object goes away.  The code is
brittle, and you have to make sure it sticks around.

> And you still have to write code that knows 
> how to set attributes, by reading and interpreting
> the datafiles and then 
> setting the relevent variables.

  Once, yes.  But not once per object.  I've done it
twice because I have the code to read datafiles and
the code to read command-line commands.  Still, I've
done it twice, not hundreds or thousands of times.

  Chances are good that any good MUD will have a lot
more than two objects :-)

> This is good news. It does mean though, that
> in the odd chance that your MUD 
> crashes during a state dump, your ruined!

  Well, yes.  Statedumps are the fastest complete
backups you'll find under DGD.  You can complain about
them causing lag, but any other form of complete
backup will cause even more lag.  If you object to the
possibility that a crash will destroy your stuff, you
have to keep backups.  And statedumps are the fastest
available backups.

> And if you only permit a statedump 
> at shutdown (which interrupts the MUD, doesn't it?)

  It does, in fact, interrupt the MUD.  That's why I
(for Phantasmal) have a form of shutdown that allows
statedumps, and I also have a "%statedump" command
that does a statedump *without* shutting the MUD down.
 As with a number of other issues you've mentioned,
you don't have to pick one way and do it that way. 
You can do both, it just takes a little more code.  In
this case, barely more code at all.

> The only way to keep things backed up 
> enough would be to do a statedump every
> hour or so,
> and I think that's too 
> much lag. Which is why I was thinking, it
> would be more appropriate to save 
> certain critical objects, like the users,
> every 20 minutes or so, and do 
> statedumps as well say, every 5 days?

  Sure, that'd work.  I think you've decided
statedumps are laggier than they are, but whatever. 
You can try it out and see how much of a problem you
have.  I suspect you'll discover that statedumps are
fast and your worries are baseless.  But it's easy to
make that configurable, so you'll write about the same
code either way.


=====
------
noah_gibbs at yahoo.com

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd