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.

Introduction to Scriptable Objects