[DGD] Saving to disk

[Raymond Jennings]

Phantasmal (which used to be maintained by noah until real life on his part
dumped it into my lap) has a meat locker to store player bodies.

Users aren't exactly destroyed, but their in game avatars or characters are
at least taken off camera.

Speaking of upsetting users, you may find that many will complain if you
*don't* take them out of the action.  Leaving a userless body out in the
wild can be dangerous to their health.

There may need to be exceptions though, such as making sure players don't
cheat by ducking out of combat or other such hazardous situations by using
linkdeath as a get out of jail free card.


On Tue, Apr 16, 2013 at 12:10 PM, Blain <blain20 at gmail.com> wrote:

> On Tue, Apr 16, 2013 at 10:51 AM, Noah Gibbs <noah_gibbs at yahoo.com> wrote:
> > The all-in-one /obj/thing isn't primarily to allow mutation of one object
> type into another.  It's primarily to avoid the repetitive and error-prone
> coding of many nearly-the-same sub-paths in your code for various types of
> objects that don't quite share properties, but almost do.  By saying "there
> is one global object type with properties and I will just code the
> properties", you avoid that.  Sufficiently careful coding of your various
> types, for instance by flagging them with properties, will also allow you
> to avoid that...  And then you basically have one object type, but with
> properties.
>
> Yeah, someone did bring the mutation thing up before.  I considered it a
> null reason for persistence, though.  I guess my main sticking point was
> just bringing in behavior code somehow to a given class of object and
> making it work as seamlessly as an inheritance tree.  I think, in theory,
> it can be done the same either way, but when I sat down to write an
> /obj/thing.c myself, I felt I was doing way too much work for less or the
> same gain as just nesting inherits for each object class.  I haven't thrown
> the idea out totally, yet, because I intend to make my hybrid mudlib and
> then see what I can do to make a copy of it be full-on persistent after I
> get used to running the lib from the inside.  Reading docs and archives
> doesn't make me anywhere near expert enough to make these kinds of design
> decisions until I do.
>
> > The various player-body stuff isn't actually about save files versus
> persistent.  You can implement any of the player-body features you mention
> with either design.
>
> I just didn't like the idea of letting a player's body hang about in memory
> and risking the chance of losing them forever or letting them clutter up
> memory.  I know it was discussed going through and culling idle bodies, but
> my concerns relate to losing track of objects in persistence mode more than
> anything.
>
> > Your various arguments about swap files also apply to your save files.
>  That is, none of your nominal reasons for choosing one over the other
> actually favor one over the other significantly.  There's nothing wrong
> with save files for objects, of course.  The basic tradeoffs are:
> >
> > * swapfiles are faster because the save code is done custom in C, and you
> don't need to separately marshal the objects.
> > * swapfiles, managed well, are already 50%+ pre-saved at any given time
> because DGD swaps out idle objects.
> > * swapfiles can preserved leaked objects, while good save files never
> should.
> > * swapfiles are less human-friendly to edit.
> > * swapfiles require upgrading objects in place rather than allowing
> save/restore-style upgrades.
> > * swapfiles always automatically fully preserve object relationships,
> while save files can have save/restore errors.
> > * swapfiles require no marshalling code, while save files require writing
> it.
>
> - Saving a player to disk shouldn't take too long and its importance
> supercedes any bit of time it may take.  save_object() is in DGD, so it
> should be fast enough.  Only saving the inventory to string recursively
> would be all LPC and take some time.
> - I wonder how savable objects would handle upgrading in place...  I have
> to really think about that one.
> - Saving your inventory would require a mapping with the object's master
> filename and its internal data dumped to string in a special format
> different from anything Felix already does in save_object().  I currently
> have made an LPC function that does this using a "{<filename>:var=val}"
> format.  When loading from a string, it clones the filename and feeds it a
> mapping of the data fields that followed.  This might be akin to the MudOS
> class structure to some small degree.  The important point is that the
> filename points to a class of object that has all the defaults ready to go,
> and then the mapping of data overwrites whatever was overwritten in the
> original inventory object.  Every object in the game will be able to do
> this, just some objects, like users, won't pass their info out to the
> 'environment' object because they handle their owns ports-of-entry into the
> game.
>
> > That's not a slam-dunk either way.  A hybrid design gets a hybrid of
> these tradeoffs -- you have to write some save/restore code and it can have
> some (fewer) errors.  Savefile objects are fairly unlikely to leak, while
> non-savefile objects can.  Savefile objects are editable and upgradable,
> while your non-savefile objects aren't.  And so on.
>
> Yeah, it's just that some things need to be protected from hanging about in
> the swap, like users, for reasons mentioned.  I otherwise intend to use the
> persistence model as best I can.  The load point trick I mentioned is
> coupled with a clean-up mechanism for removing unused zones from
> memory/swap, which is part of the hybridness of the lib design.  In a
> futuristic-themed game with an enormous space environment, I think that
> cleaning up unused zones and their contents is important.  It's probably
> not as necessary to clean up a small game world, though, if the right
> mechanisms are in place to remove trash objects.
>
> > You're right about areas -- being able to write, import and export areas
> requires some kind of disk format.
>
> Especially when I plan to have two different servers running, a Dev server
> for creation of the game, and a Live server for players to play on.  Areas
> have to be copied from one to the other.
>
> Thanks for taking the time to respond.  Good insight.
>
> --Blain
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>