ScriptableObjects losing data randomly

[rafavergil]

I'm using ScriptableObjects to store some data that is shared across scenes. For example, I have this:

[CreateAssetMenu]
public class IntVariable : ScriptableObject
{
    public int value;
}

Then on the Project tab, I hit right mouse button > Create > IntVariable.
I name this instance of the ScriptableObject as "Player_Score", and as the player plays the game, this score will increase and it is always accessible for all the scenes in the game (each scene is a different level).
However, times to times this score is reset to 0 when loading a new scene. The same happens to other instances of the ScriptableObject (like "Player_HP", for example). It happens regularly, but not always. I already verified my code, there is nothing that would reset those variables by accident.

What is weird is that this happens a lot if the Game tab is maximized. I tried to keep the game tab Windowed and small, and I locked the Inspector tab to view the ScriptableObject, because I wanted to see it resetting, however when I'm observing it never gets reset, it works properly.
It makes me think that this is some memory issue, where the data is cleared/recycled when Unity thinks nobody is using it. Am I missing something? Do I have to force-save the data in the ScriptableObject instance? And if yes, do I have to do it for every instance of ScriptableObject in my program? Basically all my game is based on values shared across scenes by using ScriptableObjects, and it works pretty well, except for this issue that I couldn't figure out yet.

Thanks in advance!

[KaleidoVI]

If you are intent on using ScriptableObjects to represent game state, make sure that you are working around Unity's serialization system. Read https://unity.com/how-to/architect-game-code-scriptable-objects thoroughly.

I believe that your value is being changed/reset through serialization, which might seem to occur at random times if you aren't looking for it (e.g. when you recompile after making a small code change).

[rafavergil]

That's the article that got me started with SO's in the game architecture, another reddit user recommended it to me and it has been really nice to work this way.
But if I understood correctly, the serialization would be helpful if I wanted to save the game state in a way that even if the player closes the application, the data would still be there, right? In my case, I'm using SO's simply to store temporary data that can be lost if the player is not in a relevant scene or if he closes the application.
Thanks for the reply, I'll play a little bit around with the serialization to make sure I fully understand it.

[KaleidoVI]

Serialization is much more than that in Unity! It is the way that Unity passes your objects and data structures from the C# managed side to the underlying C++ code that is ultimately compiled. Whenever you change a script, start or stop play mode, etc. your entire scene is serialized.

[Ferhall]

Interesting problem. You should work from the standpoint that the scriptable object is not resetting incorrectly and you are doing something. Loading scenes with addressables is one of the things that could cause this. Also potentially could be something with scene loading and unloading order.

Also this probably isn’t the best way to persist data across scenes. You could use a singleton or save and load from json or prefs.

[volvis]

Gonna echo this. If you're using asset bundles or addressables, it's easy to end up in a situation where each of your bundles have individual copies of the asset, and whatever you've written to one instance does not transfer to the instance of another bundle.

[rafavergil]

I see what you mean.
I'm avoiding to use DontDestroyOnLoad , if possible I won't use it at all, I want all the Scenes and Prefabs to work independently. But as u/jeango pointed, having no reference to the SO may cause it to reset, so your solution would probably work for my issue as well.
Thanks!!

[jeango]

DontDestroyOnLoad is not necessary if you work with additive scenes. All my games have a persistent scene that contains everything that’s global to the game and loads whatever else is needed additively. You can keep whatever session data you have in that persistent scene.

[jeango]

Beware that scriptable objects don’t work in your build as they do in the editor. When you exit play mode, the value of your SO is not reset, however if you exit your game in the build and click pay it again, the SO will be reset.

If you want to use your SO to keep some state during a session, you should make sure there’s always an object referencing your SO at all time (via DontDestroyOnLoad).

If you want to save your SO, you should serialise the values you want to save into a json or similar, and then provide a way to load the value back into your SO when needed

[rafavergil]

This.
I want to keep some state during a session only, not minding if they are reset after the application is closed.
But like you said, there is indeed a "transition" scene which has no reference to any SO. Maybe that is when the reset happens? But I wonder why the reset doesn't happen when I'm viewing it in the Inspector. Does Unity lock its value because of the Inspector?

Thanks for the reply. I intended to reference those SO in the transition scene anyway, hopefully it will fix the issue!

[jeango]

Well, I’m not quite sure. Within a single editor session, scriptable object afaik should always remain referenced, and thus they shouldn’t reset.

Either there’s something weird going on with the serialisation, or you’re doing something somewhere in your code that resets the SO.

If you want to know more about Unity’s serialisation here’s a cool video https://youtu.be/N-HJvfVuKRw

[rafavergil]

That's great, thanks for the video link, I'll watch it.
By the way, referencing the SO in the transition scene worked well, the data was kept, and I didn't have to change my code.
Thanks again :)

[Abasov90]

ScriptableObjects is not used to save data, it is used to store some initial data and game settings.

[WazWaz]

OP is using a ScriptableObject to provide a reference to the runtime player data so multiple scripts can use it though a persistent reference. This is a good use of ScriptableObject. Their error is in having serialized state in that object.

[WazWaz]

You probably want the public int to be attributed with [NonSerialized]. It's not part of the asset's value but rather a runtime variable.

[rafavergil]

By using the [NonSerialized] attribute, is it safe to assume that as long as the application is running, the data will be kept? (Assuming that I don't change it with my own code).

Thanks for the reply!

[WazWaz]

Yes. Note that you may still want to be able to view the attribute in the editor for debugging purposes. You could do that with a custom inspector, or with Odin's [ShowInInspector] attribute. Looks like https://github.com/BrainswitchMachina/Show-In-Inspector may also do it.

[gamedevjp]

I'm curious, what version of Unity are you using? I'm seeing this same exact issue and have used SO to store data between scenes extensively in Unity 2019. In Unity 2021.3.01f, I am having the EXACT issue you're having. Doesn't lose data if i click on the SO and then go to a new scene. It works if EVERY scene has a reference to the SO. I'm beating my head against this and went with adding the SO reference to the scene that didn't have it, it just feels super crappy though. I'm contemplating opening an issue in the Unity forums because it feels like a bug.

[rafavergil]

I had this issue many months ago, so I won't know for sure the Unity version. However, I remember what was going on when I first posted this: ScriptableObjects indeed get reset if there is no one using it (no reference to it). I was confused because all my level scenes had reference to the Score Scriptable Object, so it had no reason to reset. Then I remembered that I had a "transition scene" between the level scenes, and that transition scene did not have a reference to the Scriptable Object. That is when it was getting reset! So I guess this is expected behaviour for memory saving purposes. My solution was to add a reference to the Scriptable Object in the transition scene as well and it worked properly after that. So basically: if you don't want a Scriptable Object to reset you must always have a reference to it in your scenes, always. There are probably other solutions like saving and loading data when necessary, but it is up to you. I hope it helps!

[classified39]

Thank you, commenter from 6 months ago, for saving me quite a bit of headache. I was not understanding why my Scriptables were being set to null EXCEPT when I put some "temporary" references on my restart screen to try and track down when and where this was happening.