Here’s a game:<\/p>\n
Some of those are 3D visual objects: Player, Gun 1, Gun 2.<\/p>\n
Some of those are abstract concepts, or data: Inventory, AmmoHolder.<\/p>\n
(in a Diablo clone, the Inventory might be a visual object, but only when you bring up the popup-window to display it. By contrast, in a simple FPS, your inventory may not be displayed at all – no need for it!)<\/p>\n
Unity cannot handle this situation.<\/strong><\/p>\n Classes:<\/p>\n In Unity, you have to make “everything” extend MonoBehaviour. That’s fine for PlayerClass and GunClass: you make a dummy GameObject for each, place it into the scene, and attach the class as a Component.<\/p>\n But that’s impossible for InventoryClass and AmmoHolderClass: if you make them into MonoBehaviours, Unity prevents you from using them as standard classes any more:<\/p>\n …because they have no GameObject to be attached to – they don’t exist! They are abstractions only.<\/p>\n This is core to programming: we use abstractions all the time. Without them, coding would be horrendously inefficient both for the programmer and (to a lesser extent) for the computer.<\/p>\n You have three alternatives here:<\/p>\n So … ScriptableObject is something that extends UnityObject (fixing the problem of “plain C# classes aren’t compatible with Unity”), and you can use in a Scene, and can be referenced by MonoBehaviours, and just work, right?<\/p>\n Wrong.<\/p>\n ScriptableObject is all those things, except: it doesn’t exist in the Scene. It’s an Asset.<\/p>\n This is where Unity docs really screw the pooch. We know for a fact that an SO is an Asset; when we try to use it like a MonoBehaviour, several things break and stop working.<\/p>\n …but it also “kind of” works in-Scene. The docs have no explanation for this. What are the limits? Well, basically: no-one knows, except through trial and error. This is so core to your code that it sometimes instead means:<\/p>\n \ntrial and oh-crap-that-didn’t-work-time-to-rewrite-every-damn-class\n<\/p><\/blockquote>\n You already have all that – it’s called the Class – and to have an Asset too simply creates problems:<\/p>\n Unity’s official docs are rather … incoherent … on the subject. My guess is that they were written by someone who didn’t really understand ScriptableObject, and was looking at the source code thinking:<\/p>\n \nWTF is this? Um. Err. Well … it kind-of seems to sort-of do … this? Maybe?\n<\/p><\/blockquote>\n …and worked it out from observation.<\/p>\n What the docs are TRYING to say is:<\/p>\n \n(gross over-simplification here to make things easy to understand): Unity’s memory-management COPIES every instance many times, and doesn’t support pointers\/references.<\/p>\n This is a HUGE problem in game-development.<\/p>\n ScriptableObject is a workaround that uses diskspace to make templates out of objects, and then simulates pointers by using one shared-file on disk to hold the data for thousands of in-game objects.<\/p>\n This works very well, because the way we built Unity’s core architecture (3D Meshes, Textures etc) already supports that workflow: File-on-disk generates optimized in-memory-object, which is shared\/batched wherever possible.<\/strong>\n<\/p><\/blockquote>\n Going off on a tangent, it waffles about “ShopStore” and “Multiple Scenes” and stuff that the author clearly didn’t really understand. The obvious way of implementing what’s described in the docs is many times simpler, and works much better – you would never do it using ScriptableObject.<\/p>\n What the docs perhaps should have instead said was:<\/p>\n \nYou can also abuse this system to make hardcoded fake in-scene objects that don’t have to be attached to a GameObject.<\/p>\n This will fail if you have any Procedural Content – but Unity was specifically designed never to be used in games that have procedural generation, and no-one should be doing procedural work in Unity, so that’s fine.<\/p>\n Wait … what? What do you mean “we all do procedural generation”? Wh … why? Why would you do such a thing? do you have any idea how slow that will be in Unity? Most of our code assumes everything is done at compile time! We can’t handle dynamic code!!!<\/strong>\n<\/p><\/blockquote>\n (NB: Unity used to be really, really bad at procedural work. Way too slow. There’s really no reason not to be doing tonnes of procedural code in Unity games today – except that Unity itself still has a load of political blocks on it. It doesn’t support procedural properly in places where it could)<\/p>\nWhat you need<\/h2>\n
\n
\n
What Unity offers<\/h2>\n
\n
ScriptableObject to the rescue?<\/h3>\n
Why is Asset-hood so bad?<\/h4>\n
\n
But .. what’s ScriptableObject for?<\/h4>\n