[DGD] Persistance

[Par Winzell]

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

Anything can be achieved with anything else. DGD's style of persistence 
just means that things naturally stay around forever. Old style MUDs 
reboot so often that everything tends to be built around it.

Modern MMORPGs are a good example of hybrids; most of the world state is 
transient and disappears, but select things are stored in a database. Of 
course, even LPMud does this to some degree with player.o files and 
whatever. Everything has -some- persistence. The word can mean almost 
anything.

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

I can't help but feel that you're spending your effort arguing the 
precision of these descriptions rather than trying to harvest the fruit 
of the experience behind them.

In LPMud, if you create a room, you create a hallway.c file that, when 
compiled, sets the description and such of the room. In a persistent 
game, you clone a room object, configure it during runtime (e.g. using 
some kind of editor, or by calling set_description, or whatever). And 
then it is always there, until eternity.

You're right, this is not a shocking "oh my GOD, you can do that with 
persistence!?" thing, but you asked an open-ended question, and you must 
be satisfied with vague answers.

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

No. If the game reboots from no state, then there must be something that 
recreates the state. This can be instructions in a datafile or an LPC 
object or whatever.

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

I have no idea what this means.

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

Good, you'll have no trouble with it then. But Noah was probably talking 
about the problem that when you never have a reboot, you never get to 
start from scratch, and so every time you e.g. change the implementation 
of a datastructure, you have to also write code that transforms the data 
in the existing instances from the old form to the new.

For example, if you decide after 6 years of running the game that 
inventories should be stored using mappings rather than inventories to 
avoid certain laggy situations, you'd have to write a patch function in 
your inventory code to mutate the array to the right mapping format and 
then run that patch function in every one of the possibly millions of 
objects that constitute your world at that point.

In LPMud, you'd just reboot.

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

Uh.

Zell

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