Making Scriptable objects while playing?

Hello
on the game im making im using scriptable objects for the characters (to store their stat, clothes, skills,etc).
Im gonna make a character customization, and im wondering. is it possible to have a script that can create a scriptableobject while playing the game? im using a binary formatting for saving, in case it matters.

 

There's no reason you can't...you're looking for ScriptableObject.CreateInstance. That will create an in-memory instance that's effectively the same as if you'd created the instance as an Asset within the project. I use this approach for objects that take ScriptableObject configs, to allow me to assign either config assets that are used throughout my project, as well as allowing one-off dynamic configs to be created on the fly and passed in.

That said, I'm not sure I'd use ScriptableObjects to hold the kind of data you're working with. It's probably fine, but I wonder what the value of using a ScriptableObject is in this case, compared to just maintaining the data in a serializable POCO?

 

well, im using Scriptable objects because i dont know how to use what you said. (in fact i dont even knew i could do that or how)

so, when i use a ScriptableObject.CrateInstace, it creates one and stays in the players hard drive right?, so it they close the game and open again it still is there?

 

So I am by no means an expert, in fact, I'd consider myself very much a beginner, but my understanding (because I did the same thing in my game) is that you need to not only instantiate the SOs, but also create them as assets if you want them to be in your project after play is over.

I could be wrong about this, but that was my experience when I was doing something similar.

Also, I think what dgoyette is saying is that you could store certain types of data without SOs as just serializable classes.

So for example, instead of having a script

public class Skills : ScriptableObject

you could just have a script

 [Serializable] public class Skills 

.

I think SOs work really well when you wanna create stuff on the fly in Unity without having to change scripts, and they work well to store data that needs to be accesssed by many other entities (for example, if you wanted your UI, Game Manager, and all your enemies to know your player's current health) but for certain other data you can use something else sometimes.

Again, I'm just a beginner so please take this with a grain of salt, but that's my take on this topic, hope it helps!

 

No, the scriptable objects won't stick around. Also, in case you didn't know this, although scriptable objects appear to allow runtime data changes to them that persist between sessions, that's only true in the Unity editor. In a build, changes to the Scriptable Objects will not persist between sessions. So, on their own, ScriptableObjects are not a dynamic data storage solution.

As an example, to make sure that's clear, a while back I initially thought ScriptableObjects would be a good way to store user data, such as the kinds of values in Graphics/Audio/Controls options dialog. I thought that the changes the player made while playing the game would be saved back to the scriptable object asset. That's what happens when running the game in Play mode in the Unity editor, but it's not what happens in a build. In a build, that ScriptableObject data gets reset every time you start the game again. Changes stick around during that particular session, but get wiped out every time you restart the game.

Now, you've already mentioned you're saving data to binary objects. So maybe you've already built the functionality to persist the contents of an SO to a binary storage object? In which case you're loading your SOs from binary storage when you start the game, and saving them to binary storage periodically?

In this case, there's really no benefit of a ScriptableObject compared to, say, a plain old serializable class. Unless there's something else about scriptable objects you need that you don't get out of a plain class?

I don't know whether trying to persist dynamically created SOs is a reasonable idea. I've never tried that. My concern would be that if ObjectA references ObjectB (both are scriptable objects), then that means ObjectA stores a reference to the AssetID of ObjectB. That's fine for SO instances you created in the Unity editor, but I wouldn't expect dynamically created SOs to have AssetIDs. Which means if you try to make ObjectA reference ObjectC (some dynamic SO), I don't know what would be saved. And I don't know how you'd release ObjectC's data and restore its asset ID.

Personally I'd just use plain serialized classes, and persist the whole object.