Scriptable Objects for saving dynamic and changeable data

Hello,

Data coming from XML file should be displayed in Unity UI in the run time. Data CANBE changed anytime dependent on the process.

Do you think it is good idea to save this data by using Scriptable Objects?

 

Scriptable Objects revert back to their original starting state when the game starts up. Changed data remains changed in Editor, but not on a built game. If you want data persistence within a single play session, Scriptable Objects might be enough, although I imagine that is not the case

It really should not matter what the data format you are using to save data as long as you can convert it back and forth. XML is good because C# can convert it right out the box without plugins or addons. I'd argue BinaryFormatter has the added benefit of obfuscating the data.

More useful for us to know is what trouble you are facing with saving your data onto a XML file, trouble enough for you to want to seek an alternative.

 

ScriptableObjects are good for saving state too. Imagine you create a scriptable object with an initial state of your game in the editor. It goes in build. Whenever player starts new game, you clone that object. Player plays some time and chages state of that object, like scores some points, passes some levels, ets. After that, when player quits your game, you serialize the clone and save serialized data to PLayerPrefs or filesystem. Now you just need to load it back to continue game and you can easily create game states in editor for starting different difficulty levels, game modes, etc.

 

I can't remember for sure, but I think BinaryFormatter also allocates less memory (causes less garbage collection) when being used. XML is all text based, so there are lots of string manipulation operations.

The benefit to XML or other text-based formats is that, during development, you can easily open the data and see what's in it to make sure things are behaving as you expect.

 

Is it possible to give value to the SCRIPTABLE OBJECT by code in the run time? for example by reading xml data.
We first read data from XML and give them to the SCRIPTABLE OBJECT's variables see picture below please.

 

Yes it is. Although it won't be persistent automatically. So if you need to keep that data between sessions, you will need to serialize the SO and write out to disk or something.

 

I'm a bit confused as to what you're asking.

ScriptableObjects are YAML data files with a built-in inspector that supports editing its data directly. They lose the value of being used for saving and loading in builds, because the inspector is really the entirety of that value- methodology for serialization, for saving and loading them, is in the UnityEditor, not the UnityEngine library. That being the case, they're actually less useful (IMHO) than using just any other serializable POCO for this, because they have extra baggage in the fields and methods they contain that won't even be used. Either way, you'll need your own serialization system to save and load those objects, be it XMLSerializer, JSONUtility, Json.NET, BinaryFormatter, whatever...

If your question is whether you can use a ScriptableObject as an intermediary to save and load data to an XML file, check out ISerializationCallbackReceiver, OnBeforeSerialize, and OnAfterDeserialize. You probably could pull it off, but I wouldn't really recommend it.

Alternatively, you can write you own inspector for XML files directly, in a similar manner to the way ScriptableObject inspectors work, by using a CustomEditor for DefaultAsset types. The "DefaultAsset" custom editor draws for all files you select in the project that don't already have inspectors defined for them, so it would draw for XML files as well. You can see a simple example for SVG files in the answer here.

What I would probably do though is just don't bother giving an inspector to your XML files. It's kind of pointless in most situations I can think of- if you're getting the data from elsewhere to start with, then you should be editing the data there, not in Unity, otherwise you're going to have problems figuring out what edits (in Unity) to persist when the source is overwritten externally. It gets complicated. And if you just want Unity to make runtime changes for saving and loading, then you don't really need an inspector for that- there's really no need to bring ScriptableObject into the mix at all, unless I'm missing something.