koobas.hobune.stream
What is a Script when it's attatched to a GameObject? An Object? A Class? A Reference?
I know this question sounds weird, but what is a Script?
Normaly I would think that it's its own category. But if a Script were its own category, its own ObjectOrientedProgramming-Concept in itself, why don't you see it described in any OOP-Primer or on the Wikipedia-page ( http://en.wikipedia.org/wiki/Object-oriented_programming )?
And I get the feeling, that a Script in the ProjectPane is something different than a Script attatched to a GameObject.
In the ProjectPane the Script usually defines one class, but it isn't really a class itself, is it?
Because it also might define several classes (see this related question: http://answers.unity3d.com/questions/2006/does-unity-support-the-declaration-of-several-classes-in-one-script ) and the script can't be several classes at the same time...?
But it isn't an object either, as it has no state.
When it's attatched to a GameObject, however, it does have a state.
So that would mean it's an object, right?
Or does it have a state, really? Maybe it's only the GameObject that stores the state and the script doesn't even know about it???
Either way, what puzzles me about this is, when you search via FindObjectOfType, you will not get the Script but the GameObject the Script is attatched to. So it apears the script only adds something to an existing object instead of being one itself.
Or is this just a shortcut the FindObjectOfType-Function will automatically provide for some reason?
So maybe it is something completely different?
Can I imagine it as the sheet of paper on which the blueprint for my object is written on, wich is neither the blueprint itself, nor the object that would be produced from the blueprint, but still can be altered by drawing on it?
Or maybe like sort of a HelperObject. That can't do much by itself but only when attatched to something, while at the same time changes the functionality of the thing it got attatched to. Kind of like a Gun won't do anything by itself, but when given to a man the man becomes a gunner and the gun becomes a deadly weapon.
Thanks & Greetz, Ky.
A script attached to a GameObject is a persistent instance of a class derived from MonoBehaviour. As such, it is one of multiple components defining both the behavior (what it can do and how it does it) and state of the GameObject it is attached to.
It can be called "persistent" when it is attached to the GameObject because any public variables are serialized and their values stored persistently. That's why when you close Unity and reopen it, the values are the same as before. It's called an "instance" because it is an actual occurrence of something the class defines.
Maybe a better name than "MonoBehaviour" would be "GameObjectComponent". But, honestly, I think MonoBehaviour sounds a lot cooler. "Mono" is probably a bit misleading, even though I guess it does make sense if you understand how the engine is built. "Behaviour" is also a bit misleading because a script does not only define behavior but also state (in fact, it does make a lot of sense to have MonoBehaviours which only define state in certain circumstances).
Anyways: Eventually, any second thoughts will fade and you'll start to love those MonoBehaviours like we all do ;-) ... in the end, those scripts that are attached to game objects are a significant part of the matter that our dreams are made of ;-) ... trust me ;-) ... it's all good ;-) ... you are being ... assimilated ;-)
Ah, just now I make the connection with this http://forum.unity3d.com/viewtopic.php?t=8764☆t=10 forum-post you mentioned in another answer of yours. So the "Component"-Class gives you powerful tools to extend the abilitys of an already existing GameObject but at the price of cripling itself, so no Component can live by itself anylonger (without producing errors). So it's kind of an InstanceComponentObject as oposed to a full-fledged InstanceObject. That also explains why no single Component-SubClass has a Constructor.
In Unity terms, the script defines a component of a GameObject. Until it is attached to a GameObject, no instance of it exists. However, it is a class; just a class that is designed to be attached to a GameObject.
Another way to think about it is, the class represents modular behavior that you are adding to a GameObject.
Note that static methods of the class can be called even before an instance of the class exists.
(Note that I'm talking here of the typical script file, which defines a subclass of MonoBehavior. You can include scripts in your project that define classes that are not MonoBehaviors. These would not be attached to GameObjects, but might define helper classes, for instance.)
Wait a $$anonymous$$oment... A non-attatched Script in the ProjectPane IS a class, HAS a class or DEFINIES a class? I would have thought a "class" to be too abstact a thing to be equal to a script...?
Also, does it have to be a $$anonymous$$onoBehaviour-subclass to be attatched to a GameObject, really? Or wouldn't a Component-subclass be enough? (Of course we want the functionality of the $$anonymous$$onoBehaviour-Class; I'm just asking in theory)
True, the script file is just a bunch of code. The project pane is showing you the scripts that it sees, and therefore are compiled in the project. A script may define a class. If so, instances of the class need to be created somehow. If the class is a $$anonymous$$onoBehavior you can drag the script over to a GameObject, which creates an instance of the class (at design-time) and attaches it to the parent GameObject.
Interesting question about Component versus $$anonymous$$onoBehavior. According to the docs, Component is all that is needed to attach to a GameObject. So theoretically you could declare a component that doesn't have behaviors like responding to mouse clicks. This would be how most Unity built-in components work. Whether the editor lets you actually do this with your own components, I don't know. (In JavaScript, the $$anonymous$$onoBehavior is implicit in the script so you don't even have the option, AFAI$$anonymous$$.)
Huh? I thought it was implicit unless defined otherwise? I was under the impression the "class"-keyword worked for UnityScript, too? Otherwise things like "Scriptable Object" wouldn't be accessible by UnityScript-Users?
My question about script, if I want to make callback mechanism, I need hold one hashtable which contains string NAME and refer to each script instance I want to put in, can I use MonoBehaviour as store type? then after I got the content by the key NAME, I use it as point in C++, just like this (MonoBehaviour)(hashtable.get(key)).SendMessage(...)?
Posting an answer is not a good way to ask a question. Either post a comment, or post a new question.
