Another infrequent post, another entirely different programming topic.
I'm developing a mobile game with Unity3D (C# only), and I rolled my own serialization and deserialization code for it. I recently decided to see what stable general solutions exist, and found these:
- Unity has built-in serialization functionality which is not the same as that in .NET. I haven't investigated this option yet, but I know that a derived type's stuff will not be stored in a serialization of a base-type variable (see the second link).
- whydoidoit's Unity Serializer looks like a good Unity-specific option. I will probably end up settling on this as the proper thing in Unity. I was kind of hoping to use a vanilla XML NET solution, but that looks infeasible at this point, as described below.
- XmlSerializer is the very general .NET solution; it will do as much as it can for you (short of serializing anything other than public properties), and you can override its behavior with IXmlSerializable. But it requires that any IEnumerable or ICollection implementations have Add methods. UnityEngine.Transform implements IEnumerable and lacks an Add method, so GameObjects cannot be serialized this way.
But the deal-breaker for me is that I've already implemented a serializer for IDictionary (because XmlSerializer rejects anything with that interface), and my IXmlSerializable implementations keep multiplying. Maybe I'm just doing it wrong.
- DataContractSerializer is the less-flexible, more-efficient counterpart to XmlSerializer that lets you serialize any and all read-write properties and fields, not just public properties. But the author of the class to be serialized must have specified that DataContractSerializer can serialize that class - so only custom classes/structs will work with this; forget everything in UnityEngine.
- BinaryFormatter is an attractive .NET-only option because binary can represent anything with ease, even circular references. The object model is already binary in RAM, after all. Unfortunately the results will naturally not be intelligible to humans and a level-designer could never be expected to generate/modify it by hand.