What does "Scriptable" mean?

Kind of a silly question, but it has bugged me for some time that I don't feel I have a good answer:

What does "Scriptable" mean? (Particularly when we are talking about the ScriptableObject class.)​

From dictionary.com, we have this definition for the suffix, "-able:"

So a "scriptable" object is an object you can script (if "script" is a verb), or for which you can create a script (if "script" is a noun).

As a verb, how does one script an object (and why can't all objects be scripted)?

As a noun, how does one create a script for an object (and why can't all objects have scripts created for them)?

Please share your thoughts.

 

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.

 

"Scriptable" -> "Can be scripted".

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.

Thanks for the perspective.

 

Sure, but like I said in my original post here, what's that mean?

 

I added an edit to my post above about why I think "ScriptableAsset" would be a more appropriate name for what they are.

 

Totally agree with Vryken, so should have been named "ScriptableAsset".

 

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.

ScriptableAsset kinda nails it really.

 

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.

 

Unity isn't the best when it comes to naming

 

Just when I am on the verge of abandoning my quest for a universal truth we can all acknowledge, one lone beacon shines brightly from the dark.

 

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

 

Yeah, if this was the enterprise world you'd probably have it:
AbstractInheritableSingleScriptedAssetObject

And to create an instance of it it'd be something like:
AbstractInheritableSingleScriptedAssetObjectFactory.CreateTargetedConcreteInstanceAtRuntime<T>()

 

No enterprise developer would use a singleton, they would use DI

 

Tell that to my company... they're in love with Singletons despite all my grumbles.

Though, my joke example wasn't a singleton.

 

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.

 

Definitely, good names are certainly worth an effort.

I doubt anyone here is really going to argue that Unity's conventions through the years have been consistently good, but nor have they been consistently bad.

But when you have a growing product with which the team changes over time... things happen, bad choices are sometimes made. And once they're made... well, it's hard to change it without breaking backwards compatibility.

 

I guess that would also be too abstract, probably too far off and might raise multiple other questions and cause by far more confusion. But it's good when one needs to describe what kind of objects they are. They're standalone objects in that their sole existence is not dependent on any other type of object.

I doubt their intent was really to use the term "object" like we use to in software development. I think it's more of a very abstract and conceptional term (what I referred to as "actual objects" earlier).
As for components, they are scripts, too, but when we think in pure components, e.g. a health component or a movement controller, these are not the typical "objects" one would conceptionally add to a game - it's just the technical part, the way Unity was designed, the technical implementation if you will.

They also could have continued that rather weird convention and name it MonoAsset, MonoObject ... with respect to the naming of MonoBehaviours. But that as well would have raised question and caused confusion... There's no way out and it's pretty much what @Kurt-Dekker said... technical naming is pretty difficult, especially when one develops SDKs/frameworks or an entire engine.

In the end we can just be like: It is what it is.

 

Old but gold, reminds me of the "large company" part:
https://imgur.com/gallery/UV7BEys

I have to admit, in my spare time I do lot's of weird experiments focusing on code architecture, abstractions, patterns etc... sometimes I end up with such beasts, too. It's fun though.

 

Same.

[edit]
Also.... I lost it at meeoooooow.

 

I don't think you should be afraid of too long names though, with modern code completion. A descriptive name is always better than a none descriptive name with a comment that describes it, a comment that in time will desync with the code

 

Well, names have been known to desync with code too, eh?

 

Probably, but not nearly as often as comments

 

Sorry, I ment static factory method.