In the spirit of sharing more of the tech behind the scenes, and reasons why some things are the way they are, this post contains an overview of Unity’s serialization system. Understanding this system very well can have a big impact on the effectiveness of your development, and the performance of the things you make. Here we go.
· Storing data stored in your scripts. This onemost people are probably somewhat familiar with.
· Prefabs. Internally,a prefab is the serialized data stream of one (or more) game objects andcomponents. A prefab instance is a list of modifications that should be made onthe serialized data for this instance. The concept prefab actually only existsat editor time. The prefab modifications get baked into a normal serializationstream when Unity makes a build, and when that gets instantiated, theinstantiated game objects have no idea they were a prefab when they lived inthe editor.
· Instantiation. When youcall Instantiate() on either a prefab, or a gameobject that lives in the scene,or on anything else for that matter (everything that derives fromUnityEngine.Object can be serialized), we serialize the object, then create anew object, and then we “deserialize” the data onto the new object. (We thenrun the same serialization code again in a different variant, where we use itto report which other UnityEngine.Object’s are being referenced. We then checkfor all referenced UnityEngine.Object’s if they are part of the data beingInstantiated(). If the reference is pointing to something “external” (like atexture) we keep that reference as it is, if it is pointing to something“internal” (like a child gameobject), we patch the reference to thecorresponding copy).