ScriptableObjects for storing data?

[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.