Return to Answer

Unity does not have a build-in system for saving and loading gamestates, so there is no standard solution for this. Which means that there are as many approaches to gamestate serialization as there are Unity programmers.

The problem I see with your solution, though, is that you write the state of an object to the "StateCache" every time OnDestroy is called. Your line of thought is probably that when the current scene gets deconstructed, then the OnDestroy method for all the objects will be called, so they all get an opportunity to write their state to the cache.

But there are a couple problems with this.

1. Objects might get destroyed during the scene for all kinds of gameplay or architectual reasons. You probably don't want to serialize them in that case. The opposite, actually.
2. You have no control over the order in which objects get destroyed during scene changes. Which could be a problem if you have objects that depend on other objects for their serialization.
3. You might want to be able to save the game without destroying everything in the scene.

So using the OnDestroy method is probably not the best idea.

A better idea might be to have a dedicated method for each GameObject that does the serialization. Then the process for scene transitions or creating a savegame would be:

1. Clear the StateCache
2. Populate the StaeCache from scratch by calling the save-method of each object in the scene
3. Write the savegame file / switch the scene

How do you call the save-method of each object in the scene? Well, did I already mention that there are as many approaches to gamestate serialization as there are Unity programmers?

• You could create an interface ISaveable and then give every saveable gameObject a MonoBehavior that implements that interface. You are then able to get all of those via FindObjectsByType.
• Or you could do the same thing with an universal Saveable MonoBehaviour that finds out what MonoBehaviours on the same gameObject need to be serialized and how. Probably by using some custom [Attributes].
• Or you could use the good old Unity messaging system and use the BroadcastMessage method to call every method with a specific name.
• Or you could have a OnSave UnityEvent every saveable game-object is subscribed to
• ...and many more.

The same applies to loading. Instead of relying on Awake() handling it (which might be a mistake if objects spawn or respawn during gameplay), you should also have a dedicated method for setting up each gameObject based on the data in the StateCache.

Unity does not have a build-in system for saving and loading gamestates, so there is no standard solution for this. Which means that there are as many approaches to gamestate serialization as there are Unity programmers.

The problem I see with your solution, though, is that you write the state of an object to the "StateCache" every time OnDestroy is called. Your line of thought is probably that when the current scene gets deconstructed, then the OnDestroy method for all the objects will be called, so they all get an opportunity to write their state to the cache.

But there are a couple problems with this.

1. Objects might get destroyed during the scene for all kinds of gameplay or architectual reasons. You probably don't want to serialize them in that case. The opposite, actually.
2. You have no control over the order in which objects get destroyed during scene changes. Which could be a problem if you have objects that depend on other objects for their serialization.
3. You might want to be able to save the game without destroying everything in the scene.

So using the OnDestroy method is probably not the best idea.

A better idea might be to have a dedicated method for each GameObject that does the serialization. Then the process for scene transitions or creating a savegame would be:

1. Clear the StateCache
2. Populate the StaeCache from scratch by calling the save-method of each object in the scene
3. Write the savegame file / switch the scene

How do you call the save-method of each object in the scene? Well, did I already mention that there are as many approaches to gamestate serialization as there are Unity programmers?

• You could create an interface ISaveable and then give every saveable gameObject a MonoBehavior that implements that interface. You are then able to get all of those via FindObjectsByType.
• Or you could do the same thing with an universal Saveable MonoBehaviour that finds out what MonoBehaviours on the same gameObject need to be serialized and how. Probably by using some custom [Attributes].
• Or you could use the good old Unity messaging system and use the BroadcastMessage method to call every method with a specific name.
• Or you could have a OnSave UnityEvent every saveable game-object is subscribed to
• ...and many more.

The same applies to loading. Relying on Awake() handling it for each gameObject might turn out to be a mistake if objects spawn or respawn during gameplay. So you should also have a dedicated method for setting up each gameObject based on the data in the StateCache. You will also probably have situations where you don't know how many objects of what type are supposed to be in the scene while you build it. So you are probably going to need spawners that instantiate any number of gameObject based on what's in the StateCache.

Unity does not have a build-in system for saving and loading gamestates, so there is no standard solution for this. Which means that there are as many approaches to gamestate serialization as there are Unity programmers.

The problem I see with your solution, though, is that you write the state of an object to the "StateCache" every time OnDestroy is called. Your line of thought is probably that when the current scene gets deconstructed, then the OnDestroy method for all the objects will be called, so they all get an opportunity to write their state to the cache.

But there are two problems with this.

1. Objects might get destroyed during the scene for all kinds of gameplay or architectual reasons. You probably don't want to serialize them in that case. The opposite, actually.
2. You have no control over the order in which objects get destroyed during scene changes. Which could be a problem if you have objects that depend on other objects for their serialization.
3. You might want to be able to save the game without destroying everything in the scene.

So using the OnDestroy method is probably not the best idea.

A better idea might be to have a dedicated method for each GameObject that does the serialization. Then the process for scene transitions or creating a savegame would be:

1. Clear the StateCache
2. Populate the StaeCache from scratch by calling the save-method of each object in the scene
3. Write the savegame file / switch the scene

How do you call the save-method of each object in the scene? Well, did I already mention that there are as many approaches to gamestate serialization as there are Unity programmers?

• You could create an interface ISaveable and then give every saveable gameObject a MonoBehavior that implements that interface. You are then able to get all of those via FindObjectsByType.
• Or you could do the same thing with an universal Saveable MonoBehaviour that finds out what MonoBehaviours on the same gameObject need to be serialized and how. Probably by using some custom [Attributes].
• Or you could use the good old Unity messaging system and use the BroadcastMessage method to call every method with a specific name.
• Or you could have a OnSave UnityEvent every saveable game-object is subscribed to
• ...and many more.

Unity does not have a build-in system for saving and loading gamestates, so there is no standard solution for this. Which means that there are as many approaches to gamestate serialization as there are Unity programmers.

The problem I see with your solution, though, is that you write the state of an object to the "StateCache" every time OnDestroy is called. Your line of thought is probably that when the current scene gets deconstructed, then the OnDestroy method for all the objects will be called, so they all get an opportunity to write their state to the cache.

But there are a couple problems with this.

1. Objects might get destroyed during the scene for all kinds of gameplay or architectual reasons. You probably don't want to serialize them in that case. The opposite, actually.
2. You have no control over the order in which objects get destroyed during scene changes. Which could be a problem if you have objects that depend on other objects for their serialization.
3. You might want to be able to save the game without destroying everything in the scene.

So using the OnDestroy method is probably not the best idea.

A better idea might be to have a dedicated method for each GameObject that does the serialization. Then the process for scene transitions or creating a savegame would be:

1. Clear the StateCache
2. Populate the StaeCache from scratch by calling the save-method of each object in the scene
3. Write the savegame file / switch the scene

How do you call the save-method of each object in the scene? Well, did I already mention that there are as many approaches to gamestate serialization as there are Unity programmers?

• You could create an interface ISaveable and then give every saveable gameObject a MonoBehavior that implements that interface. You are then able to get all of those via FindObjectsByType.
• Or you could do the same thing with an universal Saveable MonoBehaviour that finds out what MonoBehaviours on the same gameObject need to be serialized and how. Probably by using some custom [Attributes].
• Or you could use the good old Unity messaging system and use the BroadcastMessage method to call every method with a specific name.
• Or you could have a OnSave UnityEvent every saveable game-object is subscribed to
• ...and many more.

The same applies to loading. Instead of relying on Awake() handling it (which might be a mistake if objects spawn or respawn during gameplay), you should also have a dedicated method for setting up each gameObject based on the data in the StateCache.

Unity does not have a build-in system for saving and loading gamestates, so there is no standard solution for this. Which means that there are as many approaches to gamestate serialization as there are Unity programmers.

The problem I see with your solution, though, is that you write the state of an object to the "StateCache" every time OnDestroy is called. Your line of thought is probably that when the current scene gets deconstructed, then the OnDestroy method for all the objects will be called, so they all get an opportunity to write their state to the cache.

But there are two problems with this.

1. Objects might get destroyed during the scene for all kinds of gameplay or architectual reasons. You probably don't want to serialize them in that case. The opposite, actually.
2. You have no control over the order in which objects get destroyed during scene changes. Which could be a problem if you have objects that depend on other objects for their serialization.
3. You might want to be able to save the game without destroying everything in the scene.

So using the OnDestroy method is probably not the best idea.

A better idea might be to have a dedicated method for each GameObject that does the serialization. Then the process for scene transitions or creating a savegame would be:

1. Clear the StateCache
2. Populate the StaeCache from scratch by calling the save-method of each object in the scene
3. Write the savegame file / switch the scene

How do you call the save-method of each object in the scene? Well, did I already mention that there are as many approaches to gamestate serialization as there are Unity programmers?

• You could create an interface ISaveable and then give every saveable gameObject a MonoBehavior that implements that interface. You are then able to get all of those via FindObjectsByType.
• Or you could do the same thing with an universal Saveable MonoBehaviour that finds out what MonoBehaviours on the same gameObject need to be serialized and how. Probably by using some custom [Attributes].
• Or you could use the good old Unity messaging system and use the BroadcastMessage method to call every method with a specific name.
• You could have a OnSave UnityEvent every saveable game-object is subscribed to
• ...and many more.

Unity does not have a build-in system for saving and loading gamestates, so there is no standard solution for this. Which means that there are as many approaches to gamestate serialization as there are Unity programmers.

The problem I see with your solution, though, is that you write the state of an object to the "StateCache" every time OnDestroy is called. Your line of thought is probably that when the current scene gets deconstructed, then the OnDestroy method for all the objects will be called, so they all get an opportunity to write their state to the cache.

But there are two problems with this.

1. Objects might get destroyed during the scene for all kinds of gameplay or architectual reasons. You probably don't want to serialize them in that case. The opposite, actually.
2. You have no control over the order in which objects get destroyed during scene changes. Which could be a problem if you have objects that depend on other objects for their serialization.
3. You might want to be able to save the game without destroying everything in the scene.

So using the OnDestroy method is probably not the best idea.

A better idea might be to have a dedicated method for each GameObject that does the serialization. Then the process for scene transitions or creating a savegame would be:

1. Clear the StateCache
2. Populate the StaeCache from scratch by calling the save-method of each object in the scene
3. Write the savegame file / switch the scene

How do you call the save-method of each object in the scene? Well, did I already mention that there are as many approaches to gamestate serialization as there are Unity programmers?

• You could create an interface ISaveable and then give every saveable gameObject a MonoBehavior that implements that interface. You are then able to get all of those via FindObjectsByType.
• Or you could do the same thing with an universal Saveable MonoBehaviour that finds out what MonoBehaviours on the same gameObject need to be serialized and how. Probably by using some custom [Attributes].
• Or you could use the good old Unity messaging system and use the BroadcastMessage method to call every method with a specific name.
• Or you could have a OnSave UnityEvent every saveable game-object is subscribed to
• ...and many more.