Using Unity's Serialization as Saving/Loading system.

I want use Unity's serialization system as a save/load system.

Is it possible? I've haven't found anything about this topic. Is there any resources about this topic?

I don't want to deal with Instantiating objects when loading a save file. Unity already does this with scenes/prefabs.

 

Basically what I want to achieve is a "SaveObject" monobehaviour script attached to object I want to save.

When save requested that object serializes itself completely (with child ibjects) into the savefile. Like how unity saves whole scene file.

When load requested global SaveSystem reads that savefile and instantiates everything properly. Just like what happens when you drop a prefab into the scene.

 

Short answer: You can't serialize monobehaviours or GameObjects. Primary reason is because these objects exist partly in C# land and part in the C++ managed game engine side.

Alternate answer: You can with addons like Easy Save or Odin but it's really not best practice. You get some pretty bloated save files and requires a whole gamut of work arounds and short cuts.

I see this question at least once a month and the answer generally is you have to work out an appropriate save system that works with your game. Everyone seems (at first) to think that serialising entire scenes and instantiated objects is easier, but it's not, it will actually be magnitudes more difficult than implementing a GUID system, a data base, and making your own serialisable surrogate classes that can be nicely written to a file with Newtonsoft JSON.net.

 

No. Not really. You can dump objects into son with JsonUtility, but you can't restore them back this way.

 

Sorry, I am not usually active on forums and nothing related came up with my google search.

Currently looking at source code of a prefab file and it doesn't look bloated to me. If I wrote surrogate for those classes that's essentially what I would include. And I'm not planning on saving a whole scene so this would've been great if it was possible :/

I've though about that but I use many scripts per GameObject to separate logic, there's would be just way too many surrogate classes. And also those GameObject's also have nested childs with their own logic that also needs to be stored and loaded.

 

Serialisable surrogate classes are generally pretty simple. So far the three structs I have for my current project just consist of some basic value type fields, matching properties, and one or two constructors.

Just three structs, one for core save data, one for locational data (eg: what level the player is in), and one for inventory data, wrapped up in a larger class. I don't think I'll need many more as I prototype my game. We'll see!

You need to think about how much you actually need to save and recreate. It's most likely a lot less than you think. You also need to design your game/code with saving consciously in mind at all times, so you don't end up in a position where you can't save without it being extraneously difficult.

If need be JSON.Net can save polymorphic values with the right serialisation settings, so you can combine multiple different parcels of information in the same list.

Of course I'm saying all of this without knowing the specifics of your game.