[DGD] Where did all the players go?

[Schmidt, Stephen]

Been a long time since I was thinking about this, but when I was, I was
thinking in terms of resources - not the computational kind, but the
economic kind. There's only so much iron in the game world, etc. What you
can produce depends on how much iron you can access. If there are lots of
swords lying around unused, tying up the world's iron, and if they can be
"recycled" into other things, then players have an incentive to go find
them and scavenge them for their own purposes. It allows players to have a
role in the process, which becomes cyclical. Junk doesn't so much decay as
it gets repurposed.

Steve


On Tue, Dec 12, 2017 at 12:30 PM, Raymond Jennings <shentino at gmail.com>
wrote:

> On Tue, Dec 12, 2017 at 8:56 AM,  <bart at wotf.org> wrote:
> > On Tue, 12 Dec 2017 08:15:38 -0800, Raymond Jennings wrote
> >> I was informed by a public post from ChrisA that one of the side
> >> effects of a persistent world was a load of junk left behind in
> >> Marrach, including but not limited to heaps of scrolls, and piles of
> >> food items that should long since have decayed.
> >
> > Yes, this was why I mentioned how a persistent world more or less
> requires
> > enforced decay of things. I made some pretty extensive design for truely
> huge
> > game world with 'managed persistence' where things left alone may decay
> or
> > otherwise get returned to the 'resource pool'. Managed in that some items
> > might take pretty much forever, others will take a short time.
>
> One of the comments found on phantasmal's website talked about a
> world's "metabolism", and that comment in turn was probably found on
> this very list in the past.  Noah often pulled notes like that when he
> was maintainer of the phantasmal site.
>
> > As the core for this game world would be generated from a map (either
> > generated or a 'real' map provided as a file), all the persistence is
> based on
> > layers on top of the generated world, where each layer has a different
> rate of
> > decay.
> >
> > <snip>
> >
> >> One of the features they could have used DGD for was a persistnet
> >> world...and they wound up implementing it with a hierarchial
> >> save_object/load_object structure, plus a few daemons to pick up on
> >> changed .c files.  Was actually pretty amazing to see how they'd
> >> worked around missing what DGD has.
> >
> > Been there, done that, including the replacing of outdated objects and
> clones,
> > transfering internal state (and while at it, saving and reloading
> internal
> > state over reboots). It can be done, but quickly becomes a mess.
>
> Yes, which is why I praise DGD for doing it the easy way.
>
> > Yet, when all a game needs is player inventories persisting between
> sessions
> > and over reboots, its often what lpmuds do. And while I really like the
> idea
> > of a persistent world, many classic muds don't seem to need one, and for
> > example due to your first comment, it might not even be desirable (WOTF
> still
> > needs work on dealing with random junk lying around)
>
> In this game, being able to plant a tree and watch it grow over a
> month of RL time was immensely satisfying...and even got our druid
> community lecturing the other PCs about johnny appleseeding
>
>
> >> ...and as a wizard I had not succeeded in avoiding what seems to have
> >> become an in-joke on their mud.  That of accidentally nuking every
> >> tree in the world.  Seems to have turned into a rite of passage for
> >> wizards.
>
> > Been there, done that... :-)
>
> > Its a risk inherent to most recomile and replace setups. I did at some
> point
> > manage to protect my own implementation from this, but.. that was after
> it
> > having gone wrong more than a few times.
>
> Actually this had nothing to do with recompiling or replacing.  It was
> a fat-fingered command at the wizard prompt. :P
>
> > Bart.
> >
>