koobas.hobune.stream
Understanding the need of serialization
Hi all,
I'm new to Unity; so far it seems like a good solution to my project; however in preparation, I've heard various comments on limitations due to serialization. I would just like to confirm some of my understanding... is the only purpose of designing your classes to be serializable by Unity and/or making it serializable by deriving from ScriptableObject to allow game state and changes to persist between play mode and edit mode? Isn't this issue completely avoided if we write a custom class to save game state into a flat file like XML or JSON? Or is there something crucial/core to Unity that requires me to understand serialization?
I understand serialization may be important to learn; but its importance is only based on whether you need to persist game state between editor and play modes during development? When the game is actually released; a different form of saving game state will need to be used anyways correct? Or is it just really late at the moment and I'm misunderstanding all of this?
Regards, A new Unity user
Hm, there's a couple of pretty big concepts to explain, but here are just some breadcrumbs:
Unity serializes fields in your MonoBehaviour components to show them in the inspector. Nice for setting designer variables. ScriptableObject does basically the same thing, but it doesn't need to be a component on a scene object. It can be a simple data asset, which is just a super great way of storing binary data in Unity and using custom editors and editor features to edit that data instead of plain formats like text. ScriptableObject also work in the build, but they are probably intended for data like setting up player items and then using that data as part of an inventory system in the game. Saving data in game is often done as binary files, xml, json or other text formats.
So if I don't structure my code to use unity serialization, and store state in say... X$$anonymous$$L, what features in unity do I lose? That's my concise question... or is using unity serialization a must?
First, you lose the ability to edit script variables in the inspector, if you make them private and don't mark them with the SerializeField attribute, or if your script doesn't derive from $$anonymous$$onoBehaviour. But Unity can still use regular custom classes, when they are marked as System.Serializable and things like that, but unity serialization is all about editor features, so that's what you're losing. If you don't need any of those Unity editor features, you don't have to think about serialization, then just think about how to save and persist data in your games, that's a different topic.
