Resolved Using scriptable objects for inventory a good idea?

Hey,

I've been reading up on scriptable objects, and people seem to use these a lot for say, inventory systems.
But if I'm making a game that will be published, and possibly be distributed to consoles in phase 2 of the project, will scriptable objects work?

According to the information I have, scriptable objects will save data when you exit the game, but not after it has been published? If that's the case, we at least need some other way of saving the information to disk.

And will scriptable objects persist between scenes (even in consoles) as long as the game is running?

 

Well, more accurately, changes to scriptable objects will persist in the editor, because you are mutating the data of project assets. The same is true if you mutate the data of any other project-level asset during runtime. However...

In a build context, the data will only persist so long as the SO is referenced in memory. Once an SO is entirely unreferenced and exits memory it 'resets', or more accurately, there is no longer an instance of it in memory so the next time its referenced its data will pull from the unaltered copy built into the built game's assets.

So yes, you still need to use an alternative method of saving data even if you use SO's. Because, naturally, you can't mutate a projects asset (simplification, but you get what I mean).

Don't worry about platform here either, the behaviour should be the same for all of them.

Why use them then? Because they're the most straight forward way to author data in Unity, as SO's don't need to be attached scenes and instead live in your project files.

Further to that, because they live outside of scenes, multiple scenes can reference the same SO, acting as a simple way to transmit data between scenes.

Honestly there's a ton of ways to use them, but at they're core they're best as contains of data.

 

Thank you, @spiney199 !
This clarified all I needed to know.

Yes, I can certainly see the benefits of using scriptable objects like this.
It was just just unclear to me how the scriptable objects persisted - but thanks to you, that is no longer unclear.

 

You can actually just make a runtime copy with

Instantiate

That will copy all the public / serialized fields of the ScriptableObject instance and NOT write it to disk, and it will NOT survive app restarts, but you can mutate it all you want.

Putting a single Serializable class instance inside a ScriptableObject is another approach, and then you can easily use JSON to serialize the generally-serializable fields in that top class.

 

This is where my newbness shines. Im very interested in whats being said here, but unfortunately, something is amiss in my brain me thinks. I have been using an SO asset saved in my resources folder and its loaded on app start to read from and store to various game data. Which is odd, because from what im reading here, this shouldn't work?

To be clear, for eg: i have an SO named profile. In it, is a game mode, and a few indexes used to track sessions values. When i play my built version, this seems to be working just fine, and does indeed save and persist between sessions. Am i just completely confusing what you folks are talking about?

For clarity: PC Build only - if that matters.

Cheers.

 

Really???? This seems counter to everything I know about Unity and persistence.

Some possible explanations:

- you are using some script that handles this for you transparently

- you are not interpreting results of your experiments correctly

- Unity has changed and quietly implemented this via some type of user data overrides (seems INCREDIBLY unlikely given the consequences)

- your version of Windows actually has some type of app persistence that "parks" or hibernates your app when you exit (again, seems unlikely because of the side effects and consequences)

 

Hmm, i don't know for sure. What i can assure you is this. There is nothing 3rd party or silently managing this for me, its my own custom SO class, and static Loader class. So i know theres nothing in between doing sneaky stuffs.

Also, i recently started a 'rebuild' of my project removing almost any sort of tool or plugin i might have previously used. Basically, the only thing that isnt a model asset or texture related, art kind of stuff, is Easy Roads. Everything else is my own. I just dont do art. hehe. So i really can't see that option being a case at all.

But it works. I have my game built out in pc build, and the SO is saving the values its been given. Hmm, if i recall correctly, i got me general idea while watching a vid tutorial about ghosts / replays. And in his demo, he used SO's, that held and saved data from a ghost. And in my particular case / setup, it seems to work just fine.

Not sure what to say here. Also , i do not know enough to talk on the highest levels of whats going on , but hey, if you wanna take a look, hit me up sometime. Thanks Kurt.

 

This seems extraordinary enough of a claim that I will simply have to try it myself.

I shall try and put together a test project soon, push it up to github when I'm done.

What I will do is;

- define a SO
- make an instance of the SO
- define some properties in it (int, float, string)
- display it in the app
- allow changing it in the app
- allow the app to quit
- restart the app and see the values

and then we can stand around it squinting and rubbing our chins thoughtfully.

(I'm actually curious how this will turn out!)

 

Hmm, is this perhaps where there is a difference? I create my SO asset in the project , the old [CreateAssetMenu ...], and store it in resources. There is never any other instance of it anywhere. Just the one asset created in the editor. I think maybe just something is being confused, and i am probably way out to left field in the conversation, but for what i am doing with the SO Asset, it works fine and dandy.

Im really leaning towards there has just been a misinterpretation here (most likely from me).

 

Possibly. Let me restate my proposed steps and ask you a question, given we have created an asset as you say.

Steps:

- I have the above asset, and one of its fields contains 123

- I make an app that when launched, it:
-- prints the value in the asset
-- changes this asset to 456
-- exits the app

On the SECOND launch of that app, what value are you claiming will be in that field?

 

In my current setup, it will hold 456.

I am assuming , you mean, you just create the SO, make the asset, and change its value, right?

Then yes, in my setup currently, it is holding and persisting changed values.

EDIT: All this conversation around this , i am about to run a few rigorous tests just to ensure my system isnt frigged or something and that those results im seeing arent indeed related to issues as you have proposed, it wouldn't be the first time. hehe.

 

Okay, then I have been understanding you correctly, and I find this an extraordinary claim, as stated above in #6.

I am actually ridiculously interested in what you and I figure out here... it would be REALLY weird if I conclude one thing based on my Mac version and Unity version, and you report something else.

Oooh... its like some kind of crazy murder mystery where somebody gets stabbed with a prefab and then somebody instantiates it and destroys the original and then nobody knows where the murder weapon went!

 

lol, based on most the reads around here, its clear the MurderWeapon has come up a Null Reference. Anyways, off topic too much.

 

And my green-ness shows right quick. Ignore the above, as it turns out, i did indeed have something inplace to set fields on load, and it was some player pref magic. I had not removed that part yet, and it seems i wont be, as the SO indeed did reset and lose all the data in runtime stand alone without the player prefs stuff in place.

I noticed @spiney199 kept showing up in threads i was reading about similiar subject, and this really made me think i must have something wrong here. Mhm.

Lesson learned. Well thanks to all of you for this thread, as it definitely solved an issue that would have arisen real big real soon i suspect.

Now, off to fix me mess.

 

Here it is: you MUST NOT RUN THIS CODE IN EDITOR! Look at it, but DO NOT RUN

If you run it in editor before building, it will change the project in the editor with the changed data versus the original, and then if you make a PC build it will be invalid, and you will see the before / after.

MY RESULTS:

The SOs are absolutely NOT persisted run to run, as expected.

 

I posted my package before I saw your reply... because my testing of my stuff indicates that I am sane!!!

So this is utterly consistent with your doing the work via playerprefs.

Homicide, look at this, we have jointly managed to enlighten ourselves, learn a few things about life, and best of all, BOTH OF US WERE CORRECT!!!

Perfect outcome. Order has been restored to the Unity3D universe.

 

Lol - this actually presented a bit of a problem for me , but with a little massaging , i managed to integrate all the saving into the SO anyways, but i do have to call a simple initialization method on each of the SO assets i use like this at load time for this hacky magic.

Anyways , i appreciate the follow ups and 'corrections' to my course of action. Ty.

 

I would love to make this a short film...

But glad you guys could confirm how SO's work.