[DGD] Persistance

[Stephen Schmidt]

On Wed, 26 Dec 2001, Kevin N. Carpenter wrote:
> With that in mind, I'm fascinated with the concept of a persistent mud.

I am too, although I've never been able to do much about it. What
follows is based on meditation on the subject, not on any coding
experience I've had.

> I presume that the mud should always be shutdown and a dump file
> created.  That dumpfile should be passed to the driver as an argument
> when restarting the mud.

Yes. The question of what to do with the user and player objects
of a user who is connected at shutdown time is an interesting one.
>From a system management standpoint it's probably best to destruct
them. From a gameworld standpoint, it's not clear that it is. One
of the issues that really interests me is this: If a world is
persistant, so that objects are expected not to vanish and reappear
causelessly, then what happens to a player character when the
associated user logs out? It seems to me that the PC should still
have some kind of passive existence in the game even when the
user is not connected. Precisely how to handle this is not clear,
and would vary from game to game anyway. A mundane solution is
to give each player a house with a bedroom, or a castle, or some
other permanent location. (Perhaps you could quit only in that
location, though then dropped connections are a problem.) More
fantasy-oriented solutions involve players changing plane, or
changing from trance to life and back, or other, more creative
alternatives.

> I believe I caught Felix mentioning that swap files could be used instead?

Not that I'm aware of; can any gurus comment?

> Once I'm past this, the next issue would be object management.
> Presumably every object in a persistent mud must be upgradeable to avoid
> every having to restart (Hmm, "Let there be light!" comes to mind) the
> mud.

I think DGD takes care of this for you, although I'm shaky on the
details. Certainly I would not advise opening a mud and calling it
"persistent" unless the core mudlib was throughly debugged. Make
sure you understand, for example, the reasons for the restrictions
that the kernel lib imposes on cloning and inheriting objects (as
I understand it, an object can be either cloned or inherited but
not both, and this is precisely to avoid technical problems of having
to deal with changing the code of upgraded objects, though I do
not recall what those technical problems are).

Further, it's not clear to me that the usual model of wizards
extending the game world would necessarily be appropriate for
a persistent mud. If the world was persistent, yet wizards
could clone new objects, there is a problem of open-ended
expansion that would have to be resolved in some way. There
ought to be some in-game-world mechanism for resolving what
happens when an object is destructed. It also seems that expansion
of the game world would be more troubling in a persistent world
than a non-persistant one, though not fatally so. One might be
able to do away with wizards in the usual sense, and allow players
to do more of the manipulation of the game world, within constraints
imposed by the persistence of the objects in the world, and presumably
limits on how new objects can be brought into existence. One would
want to think carefully about game world ecology.

I think I may have taken a thread that the author intended to
be about coding objects, and diverted it into a discussion of
game design :)  But I really believe that, if we change the
software rather dramatically by introducing persistence, then
we ought to think about whether the games that are built with
that software need to change as well, perhaps equally dramatically.
Certainly it is not obvious that the game model should remain
unchanged.

Steve


Sweet words can buy honor
Good deeds can gain respect
If a man is bad, do not abandon him.
	- Tao Te Ching, chapter sixty-two





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