The inventory in my game is an array of scriptable objects, which was the most convenient way I could find to store and access this data. However, I’m writing a saving and load system and I want to be able to save and load the player’s inventory. From what I’ve seen, scriptable objects are not serializable.
Is there a way for me to save my inventory information, or will I have to create a workaround to produce the correct result?
Not so much as a workaround, but what’s generally called a ‘serialisation surrogate’. Which is, another class you use to generate serialisation friendly data that can be written to disk, and read from later and converted back into Unity-centric game data.
As you’ve discovered, you can’t serialise out Unity objects, or references to them. What you can do, is make a ‘SerializedInventory’ class that takes in your normal inventory and turns into something that can be written out, such as grabbing an item’s unique identifier (a guid or even just its name).
Then when you load the inventory, you use these ID’s to look up from a central database/lookup table, and use that to generate the runtime inventory again. It’s a fairly common practice you’ll become familiar with.
Unity’s JsonUtility supports serializing scriptable objects, so maybe you can use it.
If the item’s property won’t change (= only the amount changes), better solution is as what spiney199 provides. That’s the solution most game used when working around saving inventory, I think.
I’m already doing that for simpler data types (i.e. Vector3), but I got stuck at the central database part. That will probably be the method I go for — generating a hash value for a specific item and saving that, then reversing the hash to look it up.
Do you have any tips for setting up a database? I haven’t done that or seen any resources on it before.
A database doesn’t have to be fancy. It could just be a scriptable object that references all the items in your project (editor scripting helps immensely here), that’s referenced in some singleton/static system (the SO could be a singleton itself), to be accessible when needed.
I’ve seen people make it work with Resources/Addressables too, where they use the name to load it from the respective streaming system as needed.
Beyond those basics, there’s all manner of ways to architect these systems. But keep it small and simple to start with, to help wrap your head around the ideas.