[DGD] Persistance

[Robert Forshaw]

>From: Noah Gibbs <noah_gibbs at yahoo.com>
>   As for how areas are designed, imagine a world with
>no zone resets.  Stuff doesn't pop back into place a
>few moments after you kill it or steal it.  You might
>say "that seems stupid.  How would you get more
>opponents and money?"  But if you think it through,
>you wind up with something subtly more like the real
>world.  It's a nice change, or so I believe.

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

>  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?

>Imagine that you created an object once, and it
>stayed.  But imagine you didn't create it as a regular
>occurrence.  You'd never write any initialization code
>for it, not once it had its attributes (which could be
>done in some other way, as Skotos does, or with a data
>file, as Phantasmal does).
>
>   There's no reset, no respawn, no destruction and
>remaking.  It's just, y'know, there.

This sounds drastically different from the conventions I've grown accustomed 
to. What's the point of storing configuration in a datafile? Setting 
attributes isn't difficult and having a datafile just makes it harder to 
alter the possible attributes an object may have.

>So you don't
>write code for routine destruction, nor code for
>initialization.  You just set some attributes (some of
>which may involve code, naturally) and away it goes.

Hmm. I thought that was how it was always done? *scratches head*

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

>In return, when you change object code, you have to
>write a little piece of code to update the existing
>object(s).  That can be nontrivial, sadly.  But it
>runs to turn the old object into the new object, not
>to make the new object from scratch.

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.


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

_________________________________________________________________
It's fast, it's easy and it's free. Get MSN Messenger today! 
http://www.msn.co.uk/messenger

_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd