[DGD] Persistance

[Noah Gibbs]

--- Robert Forshaw <iouswuoibev at hotmail.com> wrote:
> > The way objects are created, areas
> > designed, everything changes.
> 
> Specifically what changes?

  I'll note that I'm not running a truly persistent
MUD.  Phantasmal's sort of an amphibian -- keeps all
the machinery for full persistence, but also keeps an
object load/save mechanism for everything as well. 
That keeps me from having to write all the upgrade
code, but means I still have a lot of configuration
code left.

  I get a little insight into these things as well,
though not like Skotos.

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

  Anyway, MUD-Dev has addressed these questions, and
I'm not going to be able to do better in one message. 
Go read about it there :-)

> as I understand it setting attributes to an
> object is part of configuring
> its behaviour? What exactly do you mean by
> 'behaviour code' ?

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

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

  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.

> >Most code in a traditional LPMud isn't real code,
> it's just a cumbersome 
> >configuration (set_this and set_that) technique.
> That pretty much goes away 
> >in a persistent game.
> 
> How so? You still need to set attributes on an
> object, do you not?
> How does persistance change this?

  For one thing, you can make the object and shape it.
 You can change the attributes dynamically and they
stay.  Kind of like how you don't need to extrude a
sculpture whole, but can start with a lump of clay. 
So you never have to write the initialization code,
but you *do* have to set data somehow.


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