[DGD] Persistance

[Noah Gibbs]

--- Robert Forshaw <iouswuoibev at hotmail.com> wrote:
> >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...

  Yes.  Perhaps this wasn't what Erwin (I think?) was
talking about, though it's what you usually hear
called a "persistent MUD".

> > [...] It also makes an
> >economy possible, [...]
> 
> 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 :-)

> What does this have 
> to do with persistance? It can still be achieved
> with a non-persistant MUD can it not?

  This is a consequence of the deal with zone resets. 
It can't be done with zone resets, no.  At least, not
without an exponentially-expanding player base or
serious money drains.  One isn't practical for most
MUDs, and the other is so unpopular with the players
that essentially nobody does it.

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

  There isn't.  You'd never *write* to the datafile. 
You'd just read from it, once, to make the object.

> Setting 
> attributes isn't difficult and having a datafile
> just makes it harder to 
> alter the possible attributes an object may
> have.

  I think you're giving datafiles too little credit,
but that's neither here nor there.  Here's something
that 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.

  For the other 5%, you can either write code your way
or write little scripts that attach to the objects. 
At that point it's kind of an academic distinction.

  However, the first approach works much better for
the other 95% of objects.  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.
 Doing the equivalent of '%set_obj_weight "sword" "9
lbs"' is really hard when the sword object is a .c
file and you'd have to rewrite the code to change that
:-)

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

  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.

> >   State dumps [...] save 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?

  Not a lot, no.  Skotos does it this way.  For that
matter, so does EverQuest if memory serves.  Everquest
doesn't use DGD statedumps, but their periodic backups
are just as large and just as laggy.

  Also, you never have to statedump until shutdown, so
actually, it *never* has to cause any lag.

> I'm thinking of preserving user
> configuration, etc. with 
> savefiles in case there is a crash (you never know
> what might happen).

  Yup.  Statedumps would give you that for free. 
Like, you'd have to write only about ten lines of
code, and *no* code specific to particular kinds of
objects, ever.

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

  Yes.  When you change the definition of an object to
have new data fields, you have to put something in the
new data fields.  When you change how things get
stored, you massage the data into the new forms.  For
instance, I might change my objects to stop storing a
"brief description" string and instead store offsets
into my arrays of nouns and adjectives to make a
description.  So if you see a "broad green tabard"
then you're guaranteed you can "look broad green
tabard" since it uses nouns and adjectives in the
object.

  However, when I take add the new data field (let's
say an array of integer offsets, so it'll be an int
pointer), I'll need to fill in decent values.  I could
make it default to saying the first two adjectives,
then the first noun.  So I'd set the array to [0, 1,
0], where the last element is the offset into the
array of nouns.

  So far, so good.  But where do I put the code to
fill in all those fields?  One answer is "in the
ObjectD".  My favorite answer is to have the ObjectD
call a function called "upgraded" if it exists on
every object that gets upgraded.  That's what
Phantasmal does.

  So I could put that code I mentioned above into the
upgraded() function of my object type, then type
"%full_recompile" at the command line, and my objects
would all start being described as "big brown table"
and "flat checkered floor" and things, all according
to the first nouns and adjectives on their current
lists.  Then I'd go fix all the descs, 'cause that
would look funny :-)

  But I've had to write specific upgrade code for the
specific change I made to my objects.  In a standard
MUD, I'd make the change to the object loading code,
then shutdown the MUD and restart it.  Then all my
objects would be appropriately altered, but I'd also
have to drop everybody's network connection to do it,
and generally disrupt things.  Not nearly as
convenient.  Plus, it's slow to do all that loading
and saving of LPC objects using LPC code.  Much faster
to use a statedump.

> I thought it 
> was all there in the kernel lib? ;)

  Not the stuff specific to the change you just made
to an object type, no.  :-)

> I never have
> thought that writing an 
> object manager will be hard.

  Look at the existing ones before you decide that. 
Please.  There are some subtleties you're not
considering.  Seriously.

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

  Yes.  Do you want all those objects to go away every
time you add a bugfix?  You suggested "every few
weeks".  Even on that timeframe, that's noticeable
disruption.  You're right, not doing it is a luxury. 
But why turn away that luxury?

  Also, bear in mind that altering objects in these
ways is actually a good way for builders to do stuff. 
That's harder if it all goes away every couple of
weeks :-)


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