Save system where each component can save/load it self.

First, big chops to you for straightening this out in your head. Your engineering thoughts are spot on here, at least as far as putting the loaded game back together.

You might need to iterate as you load:

  • read the save data
  • set the score and all money and all the global data
  • figure out what the scene name is going to be
  • load the scene and wait for it to finish loading (it ALWAYS finishes next frame or later!)
  • dig through the scene connecting items to the saved elements in the list.

If you start making dynamic amounts of creatures and having to save them, then your problem becomes to feed the loaded save data into the same factory to create the same creature and then move him to where he was saved at.

Finally, here is my very high level blurb on it, and I think it mostly echoes what you say above.

Load/Save steps:

Don’t use the binary formatter/serializer: it is insecure, it cannot be made secure, and it makes debugging very difficult, plus it actually will NOT prevent people from modifying your save data on their computers.

When loading, you can never re-create a MonoBehaviour or ScriptableObject instance directly from JSON. The reason is they are hybrid C# and native engine objects, and when the JSON package calls new to make one, it cannot make the native engine portion of the object.

Instead you must first create the MonoBehaviour using AddComponent() on a GameObject instance, or use ScriptableObject.CreateInstance() to make your SO, then use the appropriate JSON “populate object” call to fill in its public fields.

2 Likes