Well, as dictionary says, “able” suffix should form adjectives. You have object and it’s scriptable (adjective). It’s literal asset in your project, which exist on your disk and has path like any file, and this asset has some logic associated with it.
There are other objects in the world of Unity, meterials, or scenes, or prefabs. They have behaviour which you can control, but it’s not like the whole object which whole behaviour is defined by one script which you make.
Hence, “ScriptableObject” → “An object that can be scripted”.
Edit:
I have always thought “ScriptableAsset” would be a better name for what it is though. If we’re going by technicality, then yes, every “object” technically can be scripted.
The main difference of ScriptableObjects though is that they live in the assets folder, rather than being tied to a scene, hence:
“ScriptableAsset” → “An asset that can be scripted” sounds more appropriate, in my opinion.
Ah, that makes sense! They are modifying “Object” with adjective, and they wanted it to describe the nature of the object in a way that distinguished it from the others you mentioned (“Scenes,” and so on). The content of a ScriptableObject is, in fact, script, so they chose an adjective that suggested that was its role.
Kind of missed their own target, though, if that was their thinking. A “scene” doesn’t need to be called a “scenable object,” because “scene” already tells you what you need to know. Thing is, “scene,” and “material,” and “prefab” are all nouns. What might have made more sense would have been to use another noun. Using a noun as an adjective is pretty common in English ("race car,’ “college student,” “claw hammer”). The noun adjunct here could have been simply “script,” and we’d have “ScriptObject.” (Conceivably, they could have just used “Script” all by itself, but that word shows up so often already in a much broader context that it would have caused a lot of confusion.)
What’s kind of ironic about this is that Unity’s manual and the API doc for the class both say that ScriptableObjects are mostly for holding data (in which case, they might have been better off calling them “DataObjects”). Fact is, I put lots of code into my SOs all the time, so “ScriptObject” would have been fine by me.
Yeah, that REALLY would clear things up a lot. I had no idea how I could even think about them with the name “ScriptableObject” because it just means… nothing.
Therefore I ignored them for years and years, when they are in fact an incredibly versatile thing I use every day now.
Especially as we so often hear of “object” in the context of “instantiating an object”, which is definitely NOT what an asset is in Unity. To me, an “instantiated object” is like a prefab clone…mess with it all you want, but the prefab’s unchanged.
Agreed. That would have done a much better job of fitting it into the taxonomy of other assets. A remaining quibble I’d have had with that, however, is connected to my quibble with “InputActionAsset” assets (which are part of the Input System). It seems kind of redundant to put "Asset’ into the name of an asset.
But that’s why I think Tekrel’s take on this is so appealing: Material assets have materials in them; Scene assets have scenes in them; and ScriptableObject assets have script in them. But all code we create by subclassing Monobehavior has script in it, so distinguishing SOs on that basis alone seems vague (and, still, we have not said what “can be scripted” means, as it appears our consensus is that any C# object can be “scripted” as much as a ScripbableObject can).
Here’s a thought: Unity’s docs all say SOs are for holding data, but we all know they can be used to hold code. To me, the big distinction between an SO and a MonoB is not that one holds code and the other doesn’t (since they both do). The big difference is that an SO can be instantiated and serialized by the Unity editor without attaching it to a GameObject. All MonoBs have to be attached to a GameObject when instantiated by the editor. That means you can’t just pass them around or share them among multiple objects. But you can pass around and share SOs because they can exist independently of any GameObject.
So… would it have been a better fit to name them, “StandAlone” assets?
True, ScriptableAsset would at least be little more specific (from a programmers point of view).
In the end, it’s just a name and I guess only UT can tell us why they’ve chosen it.
Perhaps the focus wasn’t really the “scriptable” part of the name, but the “object” part, since they already had GameObjects.
I mean, one could say GameObjects are “the actual objects”, the entities of the game. Sure, they do nothing but carry components, but components are not supposed to exist without a GO. Based on that and from a non-technical, non-programmatic perspective but rather from a design perspective, one could say that pure components are not considered “actual objects” a.k.a “entities” in a game’s world, they are only parts that make up an “actual object”.
Continuing with that thought, the other types of “actual objects” (aside from plain C#, non-UnityEngine.Object types) that are able to qualify themselves as some sort of “entity” are the ones they’ve called ScriptableObjects. Objects that do not really need/have a representation in the scene. They - so to speak - only exist as a script, based on which you can create lots of instances in your asset folder.
*Edit @Stevens-R-Miller exactly my thoughts about the topic… universe synched our brains in that very moment
Perhaps a Unity guy comes along and sheds some light on it.
This discussion is really helping me come to grips with the issue. Particularly comments like this one:
Suddoha’s shift of focus makes a lot of sense. It’s also harmonious with my observation that other types of assets are named for nouns, not adjectives. The noun “Object” is present in both GameObject and ScriptableObject. Both are modified by adjectives, but when “Game” is used as an adjective, it becomes a noun adjunct, whereas “Scriptable” is always just an adjective. (Well, to be pedantic about it, one can draft pretty much any adjective into service as a noun, too, like “the rich” or “my elders,” but the -able suffix so pervasively turns nouns into adjectives that “upcasting” it back into a noun would be kind of absurd, and a noun is just not what comes to mind when you see the word “scriptable.”)
My suggestion above, “StandAlone,” is really no better, as it is also an adjective. Since SOs contain nothing but C# (even if that is only to represent data, and not code), The most precise name for them would have been C#Objects, But that would have been a disaster as it would be confused with the “scripts” we use to create components that are subclasses of MBs. (Does anyone else hate calling code “scripts?” I do.) Worse, all instances of a C# class are C# objects. Distinguishing “C# objects” from “C#Objects” would have been impossible, as a practical matter.
In any case, it’s ultimately irrelevant what a better name would have been, as there is no real chance that ScriptableObjects will ever be called anything else. But this discussion, including what a better name might have been, has really clarified my understanding of what the name we have means. When referring to SOs, “scriptable” means "able to contain C# and only C#, " and “object” means “able to be instantiated without being attached to a GameObject.”
Actually they’re better than most. You’ll find that technical naming is actually quite hard. This is why I always laugh when people say “We’re gonna mandate standards for function and variable names!”
Good luck with that. Often it makes the problem worse. It’s just not possible in anything but the most trivial system, and it’s doubly impossible in a system that is growing and expanding, which applies to pretty much any API that is in current use.
We have our roots in the business enterprise world and its atleast a little better there. We dont name our base classes after the CLR we happen to run at the moment
It’s an undervalued part of the development process. While I agree that inviolable standards that work in all cases are probably impossible to achieve, there is still a middle ground we can aspire to. The Unity Scripting API has examples of the good and the bad. “AudioClip” is hard to argue with, whereas “MonoBehaviour” is hard to defend. And I’d pay brisk money to be able to go back in time and raise my voice at the meeting where Unity decide that the root of its API class hierarchy would be named “Object” (though I cannot print here what I would use that raised voice to say).
My wife knows how to program and works with programmers in her job. They don’t write games, so she has some energy left to discuss coding issues with me when I need someone to help me hash out an issue. The issue we seem to spend the most time on is the one we are discussing here: naming classes. A good name can make it a lot easier to come up with public member names, and all of that makes it a lot easier to write readable code. That’s a major boon when you leave it behind for a few months, then have to come back to it.
So, yeah, good names are worth the effort it takes to choose them. Unity gets it right some of the time, but when they get it wrong, they come up with some real doozies.
