[DGD] Where did all the players go?

[Blain]

So... when do we begin making Dowrkin MUD?  We'll need to showcase our
blossoming package distro mudlib, after all.

On Dec 12, 2017 11:31, "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.
>
>>
>> On Tue, Dec 12, 2017 at 7:24 AM,  <bart at wotf.org> wrote:
>> > For me, it has taken quite some time to wrap my head around the
concept and
>> > implications of persistence. The first thing to realize is there being
2
>> > different kinds of persistence involved.
>> >
>> > - persistent server
>> > - persistent world
>> >
>> > You need the first to build the second, but the fir5st does not imply
the
>> > second, there is value in having a persistent server without a
persistent
>> > world in that you can do updates to the mud without needing 'reboots'.
>> >
>> > With regards to persistent worlds, from a classic lpmud point of view,
this is
>> > typically about 'preserving inventories 'between sessions, and
possibly across
>> > reboots.
>> >
>> > While those can be useful if not desirable features, this is really
not what a
>> > persistent world is about. On a mud implementing a persistent world,
you could
>> > drop something on some out of the way location, and given nobody walks
by and
>> > picks it up, it will still be there 10 years from now. Not needed for
every
>> > game, actuall not even desirable for some games. But for roleplaying
games,
>> > this can be quite valuable. For games which let players build their
own world,
>> > this is highly desirable. AT any rate, a persistent world also more or
less
>> > requires dealing with 'enforced' decay of things, ie, the house a
player built
>> > should, unless maintained, over time become a ruin, and in due time,
'nature'
>> > should take it back and return the location to its original shape.
>> >
>> > This requires being able to maintain the state of every object
potentially for
>> > many years.
>> >
>> > Bart
>> >
>> > On Tue, 12 Dec 2017 03:33:08 -0800, Raymond Jennings wrote
>> >> I probably don't have to remind everyone of Castle Marrach and
>> >> company taking advantage of persistence and runtime upgrading.
>> >>
>> >> I still have high praise for Skotos Tech for those...and I wasn't
>> >> kidding when I've often said in the past that they've inspired others.
>> >>
>> >> Second Contract for one
>> >>
>> >> And for antoher, Noah Gibb's very own Phantasmal which I only
>> >> inherited when he was overwhelmed by real life.
>> >>
>> >> Kotaka's inspiration goes without saying.
>> >>
>> >> On Tue, Dec 12, 2017 at 3:29 AM, Felix A. Croes <felix at dworkin.nl>
wrote:
>> >> > bart at wotf.org wrote:
>> >> >
>> >> >>[...]
>> >> >> In all fairness, unless you have been running a persistent mud for
quite a
>> >> >> while, or done live database conversions on a running system or
such, its
>> > very
>> >> >> difficult to realize what really needs to happen.
>> >> >
>> >> > Sometimes new ideas are simply not accepted.  DGD has had
persistance and
>> >> > runtime upgrading for more than 20 years now.  This doesn't fit
into the
>> >> > LPmud view, and probably never will.
>> >> >
>> >> > Regards,
>> >> > Felix Croes
>> >> > ____________________________________________
>> >> > https://mail.dworkin.nl/mailman/listinfo/dgd
>> >> ____________________________________________
>> >> 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
>> ____________________________________________
>> 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
____________________________________________
https://mail.dworkin.nl/mailman/listinfo/dgd