[DGD] Persistance

[Robert Forshaw]

>From: Noah Gibbs <noah_gibbs at yahoo.com>
> > 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 :-)

I just meant it was under that topic, and didn't appear to have anything to 
do with persistance.

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

I'm sure it can be made to work whatever the situation is, but isn't this 
besides the point? Or am I missing something?

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

The reason I was so befuddled by the mention of 'no respawn, no destruction' 
is because in my experience, things MUST be destructed at some point, if 
only to achieve certain effects. For instance, killing a monster, you 
destruct the monster object and clone a corpse object. Something like that. 
I don't see how this can be achieved if every object isn't permitted to 
destruct? 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.

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

I don't personally consider it an advantage. 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.

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

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.

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

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.

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

But you only have to set attributes once 'my way' as well. Like, in the 
create() or reset() function. 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.

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

This is good news. It does mean though, that in the odd chance that your MUD 
crashes during a state dump, your ruined! And if you only permit a statedump 
at shutdown (which interrupts the MUD, doesn't it?) then you're losing 
however-long-it-was-since-last-reboot worth of changes. So if you haven't 
shut down for 4 weeks, your liable to lose that much character development 
etc. which would be catastrophic. 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?
It is pleasing to know that statedumps don't last long though. :)
>
> > 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?
>
>   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.

That sounds like a big pain. Unless you have good foresight and know a good 
way of avoiding such difficulty (I don't :P).

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

I thought it would go in the object where the data is being loaded to...

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

Well, I think I am tempted to impose the inheritance/cloning limitations on 
my MUD for the sake of persistance, but I don't like the idea of datafiles 
and I think that is something to be considered seperately.

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

I do keep examing the kernel one but I just end up confused. I'll try again 
when I've learned a bit more.

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

Good point. I think I will go for a persitant lib then.

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

I'm not sure what you mean. By 'do stuff' do you mean build or interfere 
with the games natural process? If the latter then that's a no-no as far as 
I'm concerned. If you mean building, then what exactly goes away every 
couple of weeks? The code they've produced doesn't go away (*confused*).

Thanks for the response though, it was valuable because you've swayed me 
into going for a persitant MUD rather than a 'standard' one. :)

_________________________________________________________________
Stay in touch with absent friends - get MSN Messenger 
http://www.msn.co.uk/messenger

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