Hi,
I am using scriptable objects as character & player models. My game is built around the concept of definitions (all scriptable objects) for defining character mechanics and behavior. So a character definition is simply a scriptable object with references to sprites, sounds, and other values representing that character. It also has references to other definitions(scriptable objects) which define its game behavior. These game behavior definitions can also be given to other characters or players thru out the course of the game, and this is where I run into a problem.
Problem: Serializing references to scriptable objects. I am trying to save my game state, and while I can serialize the game state pretty easily. However, if a character assigns a behavior definition (scriptable object) to another character thru gameplay, I need to capture this reference to the scriptable object so I can properly rebuild that characters state when I load. So I need to try and serialize this scriptable object, or I need a way to get a link to the actual scriptable object asset at save time, so I can resource.load it at load time (preferred, that way I can ensure only one copy of that definition is in memory, and not a bunch of deserialized copies.)
It seems like you’re trying to mix two different concepts into one.
-
One thing is your static definitions of the game. Things that are in essence defined by a game-designer/author. These are all static and their update lifecycle is your app updates or DLCs. They’re all the same for every player assuming players all updated to the latest version.
-
Another thing is your savable game state that is in essence defined / altered through player’s gameplay. Every player has it different.
You’re arguably going the right way with using scriptable objects for the 1. They are convenient, inspector-friendly and have smart-links (no baked duplicates).
But you seem to try to save 2. together with 1., which you don’t need. Your savegame only uses your static definitions, but doesn’t need to re-save them, they’re already there! You only need to reference them in some way. It’s also important to separate the concept of a game state that’s used in runtime and that’s saved onto disk. You can have the runtime version human-friendly with readily available direct link to your static definitions / scriptable objects, while the serialised representation of it being much more slim and technology-driven with ints and strings. You have human elegancy where humans deal with it and technological elegancy where technology does.
Finally, you need to pick the technology of choice for serialisation. Unity itself provides PlayerPrefs of which not everyone here is fond. XML, just as ninja_gear suggests is another technology of choice. JSON and Thrift are other alternatives.