Over the last 6 months or so there has been a lot of tutorials/talk/hype about Scriptable Objects. I’ve been using Unity since 3.57 and never heard of them until about Unity 5.6 or 2017.
What is it with Scriptable Objects? What advantages do they have over (and when should they be used instead of) the old way of handling data, like keeping it in a class attached to a game object or prefab?
Just watch one/some of the tutorials/talk? 
They are another tool (so to speak) that’s good to know about, imo.
I did watch the videos, probable all the ones in the Lean-Live section. I understand how it’s done but I just don’t see such an advantage. I guess I am thick.
I’m not sure what I can add beyond whatever you’ve watched… it’s not like you have to use them.
I kind of imagine that if someone knows about them and how they work, they’ll choose when/if/where to use them in their own projects.
but all of these are in the tutorials you probably watched, if it is not enough for you, feel free to continue to use the old-school “game object for every manager script”-way
They allow some of the the things you could do with nested prefabs with the advantage of actually existing.
I was more interested in the timing of the usage of Scriptable Objects coming about after all these years of never hearing of them. They seem to be the new shiny. The ‘in’ way to do things.
Great info. Thanks. One thing I don’t understand. What do you mean by “- does not have most of the callbacks”. What callbacks?
Could you please give an example?
For example there is no Update loop. But RTFM https://docs.unity3d.com/ScriptReference/ScriptableObject.html
I’ve been using them for years. Usually as data containers. Here are some examples.
IAP products
IAP Virtual Currency packs
Puzzles. Auto created from json data.
Network priorities for ad system.
Settings for post build customisations.
The very short version is that they enable you to make assets. Do with that what you will.
The reason they suddenly got popular was that there was some pretty good talks at Unite about why it’s useful to have data in assets rather than in a prefab or directly in the scene. There hasn’t been any fundamental shift in functionality.
I’m quoting this for posterity. And blackmail.
People have been talking about these a LONG time. There’s a massive thread from years back which still got posts last year, I think. I guess it’s one of those “open secrets” of Unity
(Or perhaps Unity just has so many features you’re not likely to run across all of them just like that.)
The recently renewed interest started with the video linked in this blog post:
https://blogs.unity3d.com/2017/11/20/making-cool-stuff-with-scriptableobjects/
SOs have been a frequently recommended way to implement an inventory system, so that’s usually the first example people come up with. It’s simple enough to make a system to define loot objects with an IMGUI in the editor to browse it. You can use it as a sort of database with logic on the objects, and changes are permanent (not reset when pausing the game). You could even make specialised dictionaries for word games - particularly useful when you’re making more complicated logic than Scrabble. Or perhaps for a text adventure where words will have variations, tense etc.
The biggest thing to some is that they’re not components you need to attach to game objects - they’re just structures with persistence. Serialising them is free and effortless.
Stuff I’ve used them for:
-Loot tables (core object templates, stat ranges, levelled power rules, affix:power combinations for magic versions)
-Monster stats (defining health, power, lists of sprites/meshes to pick from when spawning)
-Advanced dictionaries (load text files with words, convert them to SOs with more attributes for scores and rules)
-Sprite randomisation rules (heads, bodies, legs with hair/hat/clothing variations and colours)
-Configuration (useful when you use alternative free input systems like OInput)
I definitely feel that’s part of the problem but the other part is the less than ideal documentation. One great example of this is the UnityEvent thread by @JoeStrout . Actual documentation gives very little information on using these and it wasn’t until I read his thread that I started trying to use them.
To expand on what Baste wrote: yep - scriptable objects are a tiny simplification of that prefab hack. The thing most people get wrong about them isn’t that they’re now the best way of having global Inspector class instances, but that they’re more than a 2% improvement over the not-meant-to-be-spawned prefab hack.
If you’ve seen the non-Unity C# coding community, who are also big microsoft fans, they get very excited about every new feature. As C# slowly became the primary language in Unity, some of that idolatry has crept in. I remember the same confusion - seeing more mentions of scriptableObjects (“you should replace that int with an SO!”), finding delighted articles (by non-Unity staff) showing how we could now do X, where X was something easily done before; then finally reading the Unity docs and realizing “oh, style fix, neat.”
Best thing about scriptable objects is their persistence across assembly reloads in editor.
really? I have used unity since unity 2+ and I have heard about them for a long, long time. They have been mentioned in articles and videos a lot since 2014
if you ever needed to make an asset that can run code, or something that doesnt need an update loop, you could have used them.
For example, lets say you make a custom animation creation window, and want to save the animations as project files that have a unique icon etc and when clicked open the editor. scriptable objects to the rescue!
They also play very well with git
Honestly, the prefab hack is so ugly that I hadn’t even considered it a possibility. The sane way to do assets in a non-SO world is through text files that contain json/yaml/custom format text.
They can be used for very, very many things. “Global inspector class instances” is a very small part of it. They’re the way to store any data about your game that’s not directly relating to an object in the scene. My post wasn’t made to downplay their importance - they’re very flexible tools that fills very many needs better than the alternatives.
They are kind of awesome when you’re building editor tools.
They kind of awesome in general. You can basically decouple every part of your application into ScriptableObject assets. It can greatly improve modularity in design.
For instance you make a Weapon component and put 30 variables and slap it on a prefab. Now if you want a new weapon you need to slap a new component on it and assign unique values.
However if you make that Weapon component just reference like 3 SO assets that contain all of those variables then suddenly you can just drag and drop a couple of fields and have a ton of variant weapons without needing to populate any design variables again. The weapon can now Fire like A, reload like F and use J ammo instead of A/A/A.
That’s pretty much my favorite usage. Suddenly scripts and runtime components just become lightweight pointers to a highly compartmentalized back end that is really easy to debug. SO’s, despite the recent uprising in support, are still vastly underutilized.
