[MUD-Dev2] Persisting a MUD state with plain binary serialization

[Mike Oxford]

Tiago wrote:
> Thing is, binary serialization has a few drawbacks, in terms of versioning
> and it's a pain to control which parts of the graph are serialized or not
> (it's perfect to serialize everything tough).
Not sure what you mean by "binary serialization."  Just copying out of 
memory won't work as I'm sure you're aware.

Couple thoughts here.

1)  Version every single object.  Every object knows how to serialize 
and deserialize itself, with a version header.  You then pass around 
your "save context" and the object knows how to get itself out of it 
(switch() statement calling, say, DeserializeV1()) or put itself in.  If 
you never have more than one "saved graph" you can even go with 
"Deserialize() and DeserializeFromPrevious()" or some such.
2)  You just version the entire graph.  Every time you touch a 
meta-element (schema) ANYWHERE you roll the version up one.  This leads 
to "version 1418437113" but it's an option.  There is no "upgrade path" 
between versions.

The problem with versioning "subtrees/subgraphs" means that the 
interactions across boundaries becomes an issue unless you encapsulated 
everything very very very well and don't pass structs and such.

I would recommend #1 with good encapsulation/data hiding practices and 
virtual function calls.  It's a bit more work but for any project of any 
size you'll more than make up for the time in maintenance.  Also, #1 
gives you the ability to save everything out, stop the game, fire up a 
newer version of the game (with the correctly versioned deserialization) 
and everything will load.

-Mike