So for ages now I’ve been storing data that I want to share between objects in a separate class. I simply drop that script onto an empty GameObject and then create a prefab from that GameObject. Voila. I now drag that prefab onto every object I want to share the data with. Done.
Then I watch this video on the Learn section explaining that ScriptableObjects are great for data storage. First you create a script that lists the data you want to store, then you create a second script that creates an .asset file from your script, you then simply drag that script onto every object you want to share the data with. Done.
Now, to me, it sounds like we are doing exactly the same thing except I am using MonoBehaviour, dragging it onto an empty GameObject and then dragging the GameObject into the project’s tab… while they suggest using ScriptableObject and creating a separate script to generate the resource via code instead of just dragging something out of the scene.
So this leads me to wonder: What’s the difference? Why would I want to go through the hassle of creating an .asset when creating a .prefab results in exactly the same end result (just quicker and easier)?
If there is no difference then why does ScriptableObject even exist? What’s it’s purpose? According to that excruciatingly painful video to watch, ScriptableObject exists for this purpose. Is that all? Or what am i missing?
I know the resources required to instantiate and maintin empty gameObjects is really small and that creating a script and a prefab is easy, but ScriptableObjects exists to allow you to store data in a clean way. The important thing here to me is that a ScriptableObject is, by definition, an asset that contains custom user data, while a prefab could contain anything.
If your team is big and you need a lot of data you’ll have to come up with naming conventions or some folder structure that must be explained to other people so they know that some prefabs are objects in the game and some others are just data containers. If you use ScriptableObjects to store data you don’t have to explain anything, there will be an asset that contains the data it should and nothing else.
ScriptableObjects are a good solution for storing level data, weapon data, and so on. Everything that you might store in a text file and then parse is a good candidate for a ScriptableObject, which also has other advantajes, like having the serialization and deserealization built-in and allowing references to project’s assets.
Also, note that you don’t need to have the ScriptableObject script and a second script to create the asset, there’s an attribute you can add to the ScriptableObject so it shows up in the “Asset” menu: Unity - Scripting API: CreateAssetMenuAttribute
There’s not much difference - if you’ve got a system that works for you, I would recommend sticking to it.
ScriptableObjects don’t derive from Monobehaviour. That means that they don’t (and can’t be) attached to objects in the scene hierarchy.
Using your system, you’re having to create an empty gameobject to attach the monobehaviour to, which contains an unnecessary transform component. You’re deriving no benefit from it being instantiated in the scene, and it’s costing you (a little bit of) resources to do so. But it’s no real biggie.