Is built-in serialization suitable for game saving/loading?

[RomanZhu]

Hi

Would you use that system for saving/loading in your game? What could go wrong?

[Doraku]

I'm already using the static serialization method for the configuration and my "scene" editor. For the full saving/loading of game state, it is still probably need #32 to behave correctly or you might try to serialize resources (texture/sound) and we definitely don't want that. Sadly I haven't work much on that, but adding a list of component types to ignore (or a strict list to serialize) should be easy enough.

[volundmush]

I also have some questions regarding the serializer. I am attempting to create a MUD Server using DefaultECS and in examining the Components and the Serializer, I wonder how exactly components which store Collections work.

For example, I have a LocationComponent which has 'public Guid Location'. all Entities in my setup have a unique Guid for indexing. So, a 'Room' Entity ought to have something like a HashSet Contents in order to quickly know what things are in it... how well does the serializer handle things like Lists, HashSets, Dictionaries, Lists, etc? And, is there a way to make it IGNORE a property on a struct/class/etc?

[Doraku]

It depends of your use cases: both provided serializer implentations do not handle reference cycles (if you tried to serialize an object A containing an object B which itself contains A, you would end up in a infinit loop of copies). They do handle lists, hashsets,... without any problem but if you are using the TextSerializer for readability, you might be surprised by the output. The default constructor is not used when deserializing (except if your target is <= net452), everything is serialized, even stuff you usually don't see (for a List, you would see the inner items array, the size, version and even the syncRoot object, it's even worse for Dictionary) but it works as expected. If you are using the BinarySerializer for speed then readability is not an issue anyway. Handling the IgnoreDataMemberAttribute (or creating a new one) could easily be added as an opt out, though it would be ignored (eh) for unmanaged struct types in the BinarySerializer because of how it works (pointer shenanigans to copy memory quickly).

[Doraku]

Copying limitations stated in the readme:

• do not handle multidimensional arrays
• do not handle cyclic object graph (all objects are copied, thus creating an infinit loop)
• not compatible with Xamarin.iOS, AOT platforms (use System.Reflection.Emit namespace)

If that is ok with you, use it anywhere you want, else wire up the serialization engine of your choice easily with the provided interfaces.