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 ;-)

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.)

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(...)?