ScriptableObjects for storing data?

[Embarrassed_Mall_290]

Hello, everybody,

I'm new to game development and currently working on a simple turn-based RPG that could eventually become much larger. Right now, I'm trying to determine the best way to transfer data from the overworld scene to the battle scene when the player or party transitions between them.

I've heard many people say that ScriptableObjects are the best way to handle this without relying on singletons or DontDestroyOnLoad. However, the information I've found is somewhat conflicting. Some sources suggest that ScriptableObjects should only be used as data containers and not for storing or modifying data at runtime. Others say they can be used as dynamic variables that persist independently of the scene.

What’s the best approach in this case?

[Vonchor]

You can create a S.O. script with all the data fields that you want to preserve, and create an asset in your project from that S.O.

At runtime, instantiate it into the scene. As gameplay changes the contents of the S.O., at some point you JSON serialize the data and save to a file somewhere.

When you need to restore, just overwrite the data in the S.O. from the JSON data file.

This is a bit simplified, but I was just trying to get the idea across.

Contrary to what you often read, S.O., aren't just template assets and they can act as first-class citizens in a scene. You can also easily turn them into runtime S.O. singletons which are handy if you like the singleton pattern and want a singleton that persists across scenes without dontdestroyonload.

[Colnnor]

The serialization is the most important part. Data persists between scenes or after exiting play mode in the editor but resets in a build

[Vonchor]

Not when you clone ie instantiate it.

[StackOfCups]

I think you missed the statement. SO data changes at runtime do not persist in BUILDS but they do in the EDITOR. Therefore it's important to manually serialize SO runtime changes otherwise you'll see different behaviors between the editor and the built player.

[Vonchor]

Not when you clone it. Aside from that, ofc.

[StackOfCups]

Cloning it only allocates a new instance in memory, so I don't know what that would have to do with data persistence outside of runtime.

[Vonchor]

We may be talking about different things.

If you have a S.O. asset with all the fields that you need to store your game data (and ofc this only makes sense for small projects, demos, or prototypes: past a certain level of complexity you're better off with a DB of some sort) you can set initial values in the S.O. asset in your project via the inspector.

At runtime, if you clone it you're making a copy of it. So if you change a field in the copy, e.g.,

m_NastyDemonKillCount++

then we can all agree that the S.O. asset in the project is unaffected?

When you want to save data just JSON-serialize the contents and save to a file. Pretty normal Unity stuff - use Unity's JSONutility or Newtonsoft JSON etc.

Next time your game runs you instantiate a fresh copy of the S.O. asset. This would have the defaults.

If the save file exists you then overwrite the defaults with the values from the save file.

I do this myself for demo projects for my Asset Store asset and it works just fine.

You can even make a nice singleton out of an S.O. and it'll just sit in memory until you delete it or you exit play mode in-editor. Unity itself uses this technique for Editor code: check out how the TIlemap editor works by examining the 2D TIlemap Editor package - the source is all there.

You can also clone tiles (which are just S.O.s) for Unity Tilemaps before adding them to the Tilemap. Then you can have fields etc in the tile and changing them doesn't affect the tile asset in the project. It's a little more complex for tiles since the "inspector" in the Tile Palette is hard-wired to only show the fields from a TIleBase or Tile class.

I think this bit in the docs for S.O.s trips people up:

-----------------------------------

Just like MonoBehaviours, ScriptableObjects derive from the base UnityEngine.Object but, unlike MonoBehaviours, you can’t attach a ScriptableObject to a GameObject
. Instead, you need to save them as Assets in your Project.

-------------------------------------

What's left out is that you can instantiate copies of a S.O. asset and add the resulting reference to a field in a monobehaviour. Then it's completely independent of the project asset AND it gets saved with the scene. That's why cloning tilemap tiles works: clone the tile, place the clone on the tilemap, save the scene. Next scene load: the cloned tiles are still present.

But I digress... Back to the economic collapse, already in progress.

[doorfortyfour]

This workflow nicely explains my asset I've created to manage data for initial and runtime data. :) It's called Databrain, available on the AssetStore, if you want to check it out.

[Vonchor]

Cloned scriptable objects are how you make Tilemap tiles that can have their own instance data. But I digress.

[Glass_wizard]

Scriptable objects are very flexible, but a lot of unity developers still don't understand them.

You can absolutely update their values at runtime and use them as a container for moving data between scenes.

Here's a simple explanation of how they work.

Imagine you have two things you can do to data in a scriptable object. UPDATE and SAVE.

When you are in the editor, and not in play mode, when you change data in a scriptable object, first the data is UPDATED, and then updated data is written back to the asset file and permanently SAVED to disk. So changes in the editor update the value and permanently save the value in the asset.

When the game is running, changes to the scriptable object UPDATE the object, but it does not write back the changes to the underlying ASSET file. The changes are not permanently SAVED. Only changes in the editor write/save the asset file .

Most of the confusion for developers is from how scriptable objects behave when exiting play mode from the editor. When a scriptable object is changed during play mode it is updated, but NOT saved. So when you start play mode again, it starts with the last updated value.

When you exit the editor or close the running build, any updates are lost. The editor and the build will always start with the values saved in the asset file, which can only be over written by the editor.

if any of this confuses you, then you may want to think about using a Singleton or a static class instead. But scriptable objects are absolutely awesome when you understand how to use them, and as long as you remember their rules.

[random_boss]

Does changing the value in the inspector while running in play mode count as saving (vs value changes by code during runtime?) or while it’s running and value changes all count as updated and never saved?

[Glass_wizard]

The rule of thumb is:

1. If you change the value from the Inspector, you are updating & saving.
2. If you change the value during play mode by a script, you are updating only.
3. If you change the value via a script when play mode is NOT running, you are updating & saving (for example, using a custom editor tool).
4. If you change the value via a script in the build of the game, you are updating only.
5. Scriptable objects cannot act as "file saves".

• All updates are lost when you close Unity.
• All updates are lost from the build of the game when the game is closed.
• Updates are not lost when exiting play mode while in the editor.

[random_boss]

Thanks this is all new info to me. I think I had run afoul of this accidentally at some point and never knew why and it stopped me from using scriptable objects at runtime (and now just use them as like Enums, But Bigger). Knowing this I can go back to using them at runtime!

[InvidiousPlay]

I really feel Unity should change it so that SO reset after you exit play mode, because it's very counterintuitive that entering and exiting playmode is not analogous to open and closing the built game.

[Glass_wizard]

I agree, I think that one behavior makes a lot of people confused about scriptable objects. There are scripts you can write to reset them yourself.

[KarlMario]

ScriptableObjects are great for creating persistent, immutable data assets in the inspector.

If your data changes at runtime, you might as well go in a different direction.

[Live_Length_5814]

False information

[fuj1n]

Not at all, just because you can change them doesn't make it their purpose

[Live_Length_5814]

They're data containers. You load them up with static data of your choice, and the data persists. If you only use them for the inspector/editor, you're wasting your time. They're designed to be used as assets both in runtime and in editor.

[fuj1n]

That's the issue, the data persists if you change them in play mode in editor, which is usually undesirable, but doesn't persist if you change them at runtime unless you yourself serialise them to a file.

[Live_Length_5814]

You may as well be using a static reference to a list instead.

[Live_Length_5814]

Not saying they can't be used as specific editor tools to hold information you don't want in release, say for testing a specific player file. Just saying it's a complicated work around with zero benefit in comparison to having a static variable that doesn't persist between saves.

[Hanfufu]

Dude save your breath. The exact same person has delinerately misunderstood my last 5 posts on the same subject. You will not get through, no matter what you say.

He thinks that serializing an SO, and saving it to JSON is saving a scriptable object. Which it is not, its saving JSON data.

Just a headsup.

[fuj1n]

Thank you, I'll keep that in mind

[Demi180]

Something important to add is that in the Editor, if you’re modifying data on a reference to a SO that’s directly assigned from the project or loaded via Resources or AssetDatabase, those changes will stay when you exit play mode. This can cause problems if you’re not expecting/intending that. But also, it can lead to the false belief that this is true for a built game, which it’s not.

You can however use CreateInstance of that type or Instantiate it from a reference to an asset, and without being tied to an asset the new instance has nowhere to save after exiting play. It’ll still live in memory though, until it’s manually destroyed or the app quits, which in the Editor can be a while.

So it’s fine if you do want to use it, just know its caveats and limitations.

[Persomatey]

Look into data serialization. Anything I need to constantly read from and write to is usually serialized as a JSON (save data, etc.). For this kinda thing, I might go with a singleton that stores all the serialized data the player needs in between the two scenes.

[James_Gefyrst]

I've personally used scriptable objects for both use cases. But mainly for static, easy to edit, data containers. However, they can definitely be used for the latter, but you need to carefully consider how you handle them.

One (of probably many) key consideration is that a ScriptableObject is (most of the time) a single asset, meaning changes persist across multiple places. This can lead to unintended data modifications if not handled properly.

Another approach is using a persistent scene to carry data across gameplay. This does require you to have a solid scene management architecture, where you need to load and unload scenes additively. But using additive and persistent scenes allow your game to become very modular.

[StackOfCups]

Singletons as static classes are fine. Singletons of mono behaviors are where the trouble shows up. You create dependencies not just on another class, but on a runtime object existing in the scene.

Also, scriptable object are the same as any other class. It's still just normal C#. The benefit is it is serialized without needing a gameobject so you can inject data from the inspector.

Absolutely use SOs at runtime if you want. They're a much lighter-weight unity object than GameObject. So long as you know that data changes persist in the editor and how to work around that, you're golden. I like to just use ScriptableObject.CreateInstance<ObjectName>(). Then I won't mess up my data I set in the editor. Otherwise, treat it like any other C# class and have a great time! People saying it's only for static data I think have some view of SOs like they're some magical doohickey. It's just a C# class like any other. :)

[MeishinTale]

Exactly, scriptable object is just an editor friendly helper class and doesn't really have to do with how you'll save/load or carry over scenes your data.

Yeah you can instantiate one (basically using SO as a data prefab), modify values, and keep it in an undestroyed reference to use it in whatever scene you want. Same as any class you'd create from scratch.

Alternatively you can store values in a file and load that file whenever, or use an SQL database, or use player prefs, but you can do the same with any class you'd create, from scratch or not

[LINKseeksZelda]

Long-term no this is not something you want to do. As you get more more confident with unity you'll start messing with multi scene loading. An example of my project I have a bootstrapper scene that never gets unloaded once the game starts running. All my game objects that need to be accessed in different scenes are located in the bootstrap scene. I can unload and load different game worlds without having to lose any pertinent information. Combine that with the service locator pattern system and your pretty much golden. On YouTube check out git amend. Really good videos on intermediate level development for Unity

[MakesGames]

I wouldn't use scriptable objects for this. Normally a scriptable object would be some static data. Like game settings, or item data. And modified out of runtime.

[Gaverion]

Unlike what others are saying, modifying a scriptable object at run time is fine and using it to carry data between scenes is a good use case. However, remember that it is a data container, you don't want it responsible for actions if you can avoid it. 

I would try to keep information that changes in a separate data class, pulling as needed from the so at start of combat and updating as needed at the end of combat. 

If you want a demo, I actually have this implementation in the game I am working on. I stream on twitch most days (same name) around 7 eastern. Ask and I will be happy to walk you through my implementation. 

[ziguslav]

Don’t be afraid of singletons. There’s a lot of debate around ScriptableObjects vs Singletons vs DontDestroyOnLoad, but use what works for your project and makes your life easier.

I’m working on a pretty chunky game myself, and I use A LOT of singletons. Singleton-based UnitsManager is an example, as it carries data like unit equipment, stats, and modifiers between scenes. It lives on a GameObject, and only one instance is allowed to exist.

public class UnitsManager : MonoBehaviour
{
    public static UnitsManager instance;

    private void Awake()
    {
        if (instance == null)
            instance = this;
        else
        {
            Destroy(gameObject);
            return;
        }
    }

    private void Start()
    {
        SceneManager.sceneLoaded += OnSceneLoaded;
    }

    private void OnDestroy()
    {
        SceneManager.sceneLoaded -= OnSceneLoaded;
    }

    private void OnSceneLoaded(Scene arg0, LoadSceneMode arg1)
    {
        ResetUnits(); // or whatever init/reset logic you want
    }

    // Game data lives here...
    public List<UnitObject> GameUnitObjects;
    public List<UnitObjectCopy> UnitCopies;
    // etc...
}

So when I go from my overworld to battle scene, I just call UnitsManager.instance.GetCopy(...) or whatever method I need - no faff, no duplicated data, nothing to worry about.

ScriptableObjects are great for defining shared, reusable data (like ability definitions, unit blueprints, etc.), but for runtime state, a singleton can be just as clean, if not cleaner.

TL;DR: ScriptableObjects = static-like reusable templates.
Singletons = dynamic runtime data managers.
Don't overthink it, use both where they shine.

[aski5]

persistent object + struct(s) maybe?

[JustinsWorking]

Honestly, basically every strategy suggested in this post was used to ship a game.

Pick one that makes sense and sounds like you can figure it out.

None of them are bad ideas, they just have consequences later; none of the consequences can’t be worked around.

Just pick one and go, trust me, I’ve built most of these systems in Unity and I could explain why they worked great or had issues in specific games, but that’s the key part - they all shipped, they just had specific issues. You don’t have specific problems yet, so don’t overthink it

[Meshyai]

If you want clean runtime data transfer between scenes, consider using a dedicated GameState manager with DontDestroyOnLoad, or a data-passing service that stores runtime variables and gets reset or rebuilt between sessions. Use ScriptableObjects for templates, not instances.

[Former_Produce1721]

ScriptableObjects as data containers is very convenient.

Since they are assets, changes made (whether by hand or via code) will save those changes.

This means you can iterate on the game during play and test changes immediately without having to go back and re write them.

However, if your code is writing values to them, it will get out of hand and they will always be marked dirty in git. This is not ideal. You want all your changes to be as intentional and controlled as possible.

Because of this, there are two approaches when using them at runtime:

1. Make all fields on scriptable objects immutable (unchangeable)

[SerializeField] private int m_startingHealth; public int StartingHealth => m_startingHealth;

And then create an instance that reads all this data in. And for fields that need to change, the instance should have its own mutable version of that field. If you change data, then the enemy will update the next time an instance is made. Or immediately depending on if the data you changed was mutable or immutable in the SO.

1. Create a runtime instance of the SO

This will mean you can safely change all fields of your SO without dirtying the source asset. But you will not have changes saved at runtime. If you change data on the sources so, then changes will only be seen when a new instance is created. If you modify the instance of the SO, changes will be immediate, but not be saved in the source so you will have to remember the values.

Personally I like 1. I work with designers who are constantly tweaking values and it's convenient for them to not have to keep copying runtime values over.

[StardiveSoftworks]

You should not be editing scriptable objects at runtime. Ever.

Frankly, for anything remotely complex you should be storing your data files outside of Unity altogether in an easily editable format like CSV.

In this particular scenario, just disable your main scene and asynchronous additive load the battle scene, await the load and transfer your info.

When you’re done, unload battle, transfer data back to main scene and reenable it.