[DGD] Saving to disk

[Raymond Jennings]

This marshalling of objects between a network of servers deserves a mention
of Geir Hansen's thesis:

http://geir-hansen.com/distributedworld.pdf



On Tue, Apr 16, 2013 at 9:33 PM, Jared Maddox <absinthdraco at gmail.com>wrote:

> > Date: Tue, 16 Apr 2013 07:37:16 -0500
> > From: Blain <blain20 at gmail.com>
> > To: All about DGD and Hydra <dgd at dworkin.nl>
> > Subject: Re: [DGD] DGD
> > Message-ID:
> >       <CAD2jvh7EsA_NMiygT2kR=TFK=
> T1Demdj5dbr8JQOjNuwd48EYQ at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Thanks, Felix.
> >
> > I'm currently trying to install everything I need to compile DGD on my
> > Droid tablet.  So far I've paid for "c4droid" and installed the GCC
> addon.
> > I had to force HOST=DARWIN (My OS string is undefined because the uname
> > command is missing or otherwise inaccessible).  Then it barfs trying to
> > find yacc.  I've searched Google Play for yacc or bison, but to no avail.
> > I e-mailed the author of c4droid to see if he had any knowkedge of there
> > being a droid-compatible yacc/bison.  If I get this thing working, I will
> > e-mail the list of the steps I took to get DGD on the Droid OS and I'll
> > also recommend some programs for coding on the tablet below.
> >
>
> Word of warning. If you actually run DGD on your Droid then you'll
> want to put it's swap file (and preferably everything else it uses) on
> an SD card, so that you can swap it out. NAND (including the Flash
> used inside tablets & smartphones) has a much lower maximium number of
> data writes before you start getting bad sectors/blocks. Better to act
> ahead of time by always keeping this stuff on replacable media.
>
>
> > Date: Tue, 16 Apr 2013 10:01:06 -0500
> > From: Blain <blain20 at gmail.com>
> > To: All about DGD and Hydra <dgd at dworkin.nl>
> > Subject: [DGD] Saving to disk
> > Message-ID:
> >       <CAD2jvh6RCcm9X=
> u4cTVRX62Tc27aYkTrJm0hRW2tsUcY_BFVZQ at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
>
> > For starters, users should not be ever-present in the game.  In a
> standard
> > LPMUD/MudOS game, a user is represented by a .o file.  This makes sense.
> > This also means that the user connection can and should be destructed on
> > logout.  The body, if separate can also be saved to a .o file and
> > destructed.  Other players and NPC's don't usually need to interact with
> an
> > offline player in most MUD designs.  If a designer really wanted to, they
> > could redirect private messages (usually called 'tells') to an internal
> > mail system or a cache waiting for the player to return.  Also, I don't
> > think an environment object should be trying to load a player's body when
> > that player isn't on.  Of course, there are ways which this can handled
> > appropriately in most any persistence scheme.
> >
>
> Outside of certain conditions, I think that it's probably better to
> keep the primary copy of the user & their body in the swap file.
> Still, there are exceptions:
> 1) If you've got a multi-server system then body objects need to be
> able to move from server to server, and swap files don't really help
> with that.
> 2) If you've got too many users, you'll simply need to marshall them
> out to non-swap when they logout.
>
> I also think it makes sense to move "long-inactive" players out to
> non-swap for archival purposes (after all, you might want to restore
> that info for some reason later on).
>
> The real question is "is there any real reason for me to move this?".
> I think that in most cases, the answer is no.
>
> > Persistence seems to be a great way to keep the Game going without
> skipping
> > a beat, but players can choose not to be logged in, and so they should
> not
> > quite be included in the persistence of the Game.
>
> So "teleport" them to a "login zone". If there's several "reentry
> points" for them in the area where they were, then they could even
> choose between them.
>
> > The object will also recursively save its inventory
> > and compile the data mappings received into a string variable, and it
> will
> > reconstruct its inventory using that string upon reconstruction.
>
> Having played around with implementing a C object database, I have a
> note to make. For internal data, simply translating down to strings is
> fine, but for objects that other objects can interact with (let's say
> a sword object), I think you should do it a little differently.
> Firstly, create an object to represent the save file. Every object
> that will be stored inside (body objects, shoe objects, etc.) will
> request an id. They will then be asked for their "self string", or
> whatever you'd like to call it. When they return that self-string,
> instead of containing sub-strings that describe other objects, they'll
> contain a stringified form of the id of the other object. So, a
> mapping would get it's string form embedded directly into that of it's
> owner, as (I assume) would an LWO, but a clone would get it's id
> stored instead.
>
> The reason why you want to do it like this is to prevent the
> possibility of link-recursion in a relatively simple and fast way.
>
> If the object being saved refers to objects that aren't being saved,
> then an id obviously wouldn't be enough (after all, what do you do if
> it gets reissued?). In that case, I'd recommend a combination of
> timestamp and id issued at time of creation (and for multi-server
> setups, the server of origin). This can come up if, e.g., you decide
> that players who logout while in a certain room will appear in that
> room when they return. Obviously you can't store the room with them if
> it's publicly accessible, so you need some other method. The same
> thing could come up if there's an object which for whichever reason
> isn't allowed to leave the game (let's say it's a remote controller
> for a teleporter in a dungeon, or a hologram in a StarTrek-style
> holodeck), but the player is carrying. They'll want to still be
> carrying it (or at least close to it) when they log back in, but other
> players will presumably need it too. So you store it's id, log out the
> player, move the remote somewhere reasonable (e.g. the burrow of a
> packrat), and treat it as the player's restore location when they
> return... even if it's moved, or is in the hands of another player.
>
>
> > Date: Tue, 16 Apr 2013 14:10:39 -0500
> > From: Blain <blain20 at gmail.com>
> > To: All about DGD and Hydra <dgd at dworkin.nl>
> > Subject: [DGD] Saving to disk
> > Message-ID:
> >       <CAD2jvh5TLKfND0b=csthVr+6jaem6Eyh76=
> oXncwS1JamOri2Q at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > On Tue, Apr 16, 2013 at 10:51 AM, Noah Gibbs <noah_gibbs at yahoo.com>
> wrote:
>
> >> 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.
> >
>
> Something you might consider is having a "synchronize" or
> "import/export" system for devs. You could connect the two systems
> together with either outgoing sockets, or an external "cross-connect"
> program. This might require the occasional addition of an "install
> script" or "unmarshall script", but that could be compiled & run at
> the destination from source. Serializing doesn't always have to target
> the disk.
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>