[DGD] Saving to disk

[Jared Maddox]

> 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.