[DGD] Re: Persistance

[Erwin Harte]

On Thu, Jan 08, 2004 at 12:45:32AM +0000, Robert Forshaw wrote:
[...]
> I'm not quite sure what this has to do with persistance. It seems to me 
> that resets and respawning are a design consideration, and can exist 
> regardless of whether the MUD gets rebooted or not...

Yes.  But then you also need to design something that makes items
'wear', so that you don't, after a few months of running, have 200
swords of utter destruction or something along those lines.

In a persistent game uniqueness is important to avoid inflation, so
you don't want to clone the same things over and over and over, which
is what typically resets do.

On IgorMUD this was already an issue after over a month or so of
uptime, imagine a game that runs for years without a cold start?

[...]
> > That
> >changes area design completely.  It also makes an
> >economy possible, since it allows for the possibility
> >of scarcity.  Zone resets are the #1 source of runaway
> >inflation since new "valuables" come into the economy
> >constantly, thus destroying any actual value they may
> >otherwise have had.
> 
> What you are describing is the theory of game balance. What does this have 
> to do with persistance? It can still be achieved with a non-persistant MUD 
> can it not?

Yes.  I don't think anyone is saying you have to write a persistent
game, but I think a lot of us are convinced it's one of the best ways
to make your game environment more appealing, more `real' if you wish.

[...]
> >  State dumps allow you to bring everything back to
> >the way it was pre-reboot, and to do so without
> >writing a single line of save/load code.  So you can
> >get by without init code, without object destructors
> >(well, sort of).  No load/save.  It saves a lot of
> >code.  I know it's a lot -- Phantasmal *has* all that
> >code :-)
> 
> It sounds like you could get away with just doing state dumps, but that 
> does cause lag, no? I'm thinking of preserving user configuration, etc. 
> with savefiles in case there is a crash (you never know what might happen).

If you work with a persistent game, you will keep previous a (few)
previous statedump(s) around and make those statedumps regularly.  If
you crash because of some bug in DGD or something else going haywire,
you go back to the most recent statedump with which you can avoid that
problem, in most cases that'll be the most recent one.  Thereby losing
only a few hours or so of 'state'.

[...]
> Do you mean writing the code to update objects is non-trivial? I thought it 
> was all there in the kernel lib? ;) I never have thought that writing an 
> object manager will be hard.

The support is in the kernel-lib, and there is an example object-db
out there (I think) that shows you how you can track inheritance and
clone lists/counts.

> >For one thing, you can make the object and shape it.
> >You can change the attributes dynamically and they
> >stay.
> 
> They stay on a non-persistant MUD also though, except when there is a 
> reboot...

Indeed.  I remember the first time I walked into a room on the mud I
ran a couple of years ago and realized that it was quite possible that
the equipment I found 'on the floor' there could quite possibly have
been there for over a year (it wasn't a very busy mud).  I quite liked
that idea and if I ever (hah!) write a game again, I'll definitely
make it persistent.

Cheers,

Erwin.
-- 
Erwin Harte <harte at is-here.com>
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd