[DGD] Where did all the players go?

Wed Dec 13 00:06:46 CET 2017

Something akin to Geir's thesis regarding multiple DGD instances
networked together to share the burden could be used to load balance
in a way (kotaka has some basic internal docs for planning how to
automate this)

Having rooms "timed out" before being archived into "cold storage" so
to speak could also help here potentially.

If a room is predicted not to be needed for a long, long time, then it
could be archived...or even have the game world itself "eat" it and
recycle it, on the presumption that bluebooked NPC scavengers took it,
or hotel staff hucked it out and possibly sent the contents to the
local lost and found office or...etc etc etc.

Ongoing maintenance to prevent decay is also a very useful and
realistic way to make sure that only structures/stuff in active use is
actually kept around placing a computational burden

On Tue, Dec 12, 2017 at 12:50 PM,  <bart at wotf.org> wrote:
> On Tue, 12 Dec 2017 13:05:39 -0500, Schmidt, Stephen wrote
>> 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.
>
> Resources are a good idea I think, but also can easily become a limit on how
> many people can play the game, unless you actively tune the available
> resources to that.
>
> My take on this is to make the cycle much larger and include aquiring
> resources from, and returning them to 'nature', but require effort for
> aquiring resourcees from 'nature', which can be tuned to be more expensive
> than reusing those you already havve or are lying around.
>
> This allows for 'nature' to support a very large number of players without
> having to fine-tune the resource pool, and hopefully with a limit on litter.
> But the decay idea I was talking about isn't just about reducing litter, its
> first of all intended as game element, as the game will allow players to build
> things, but requires them to maintain the things they built. Its also a
> mechanism for allowing a truely insanely large game world whiile putting some
> limits on how much of it requires active tracking of its state and how much of
> it can just be generated on the fly. When things stay forever, you'll
> inevitably end up having to track state for every location in the world
> including every object it might contain. The codebase I have now has no
> trouble doing that for some 100m or so rooms, but it seems a needlessly
> expensive way to go when most of those won't see another visitor, yet some
> will and those should behave realistically in things staying around.
>
> Bart
>
>
>
>>
>> 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.
>> > >
>> >
>> ____________________________________________
>> https://mail.dworkin.nl/mailman/listinfo/dgd
>
>
> --
> http://www.flickr.com/photos/mrobjective/
> http://www.om-d.org/
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd