koobas.hobune.stream
Can my scripts derive from Behaviour or Component?
Hi, MonoBehaviour is too heavy for me. So I just want to let my script derive from Behaviour. However, the script that derived from Behaviour like "myScriptExtendsBehaviour" can be added neither by calling AddComponent() nor by using the AddComponent button in the editor. I can't understand why component like "Collider" which derives from Component directly can be added with code and in the editor, while our custom scripts can't do that. Can anybody tell me 1 whether our custom scripts must derive from MonoBehaviour though we think it is too heavy please? 2 why the built-in classes which derive from "Component" directly can be added as a component but the custom scripts can't.
Thank you.
You can't directly derive your classes from Component or Behaviour because those are just baseclasses for the internal components. Always keep in mind that Unity is written in C++ and the actual functionality of built-in components / classes is actually implemented in a C++ class. Almost everything in the UnityEngine.dll are just managed wrapper classes for those built-in native classes.
The MonoBehaviour base class is the only base class from where you can derive your own components from. The name already states that it's a behaviour that is defined on the managed side / inside Mono and not a native class.
Why do you think MonoBehaviour is too "heavy"? The "managed" MonoBehaviour class doesn't contain a single field. It only has two new properties: "runInEditMode" and "useGUILayout". Those two properties and all other methods are actually just externally defined methods in the C++ engine core.
Thank you for your reply. Because Component and Behaviour are the base classes for the internal components, then they can't be derived by our scripts? I don't think this is a sound code design unless the class is real a internal code. I mean it is not public to users or providing some compiling errors if users derive scripts from them. The situation is we can use Component and Behaviour, and the offical document also says users can "Adds a component class of type componentType to the game object" by AddComponent(). Behaviour is definitely a component class, right?
I don't know how Unity implements $$anonymous$$onoBehaviour and whether functions like StartCoroutine, OnXXX $$anonymous$$essages which I don't need would affect the performance. Probably Unity just registers these function in compiling stage if it find the functions are declared in the user scripts.
Why do you think it's not a sound code design? Again, Unity is actually written in C++. $$anonymous$$ono is only used as scripting environment. All the managed classes Unity provides for you are actually wrapper classes around the actual native code class. The (managed) classes themselfs do not have any functionality. Just see it for yourself. Here's the decompiled $$anonymous$$onoBehaviour, Behaviour and Component class.
As i said $$anonymous$$ono is just used as scripting environment. The only (runtime) basecasses you can derive your own classes from are $$anonymous$$onoBehaviour and ScriptableObject. That's true at least for the core classes.
Yes, Behaviour is a Component as it's derived from Component, but it just serves as base class for certain behaviour classes, one of them is $$anonymous$$onoBehaviour. $$anonymous$$eep in $$anonymous$$d that the engine itself is a closed source application and the managed classes just provide an API to the engine. They are not ment to modify / extend or override the built-in concept. They are ment to provide access to engine features. $$anonymous$$onoBehaviours are custom behaviour components which can be created by you.
I still do not really see any reason why you would want to derive your component from anything other than $$anonymous$$onobehaviour. If you don't require any callbacks from Unity, just create a "normal" class. However the concept of "attaching" a component to a gameobject makes no sense if the class does not interact with the engine. You are free to manage your classes and class instances anyway you like.
You asked if you can derive your own classes from Component or Behaviour and my answer does answer this question i think.
Yes, you can.
From this answer on stackoverflow:
Component:
Component is a base class for both Behaviour and MonoBehaviour. It is a base class of any script that can be attached to a GameObject.
This is what almost every Unity build-in script derives from. This includes Collider and Rigidbody.
Behaviour:
The most important thing to know about Behaviour is that anything that inherits from it can be enabled or disabled. Do not inherit your script from this if you don't want it to be enabled/disabled.
For example, Rigidbody cannot be enabled/disabled. This is why it inherits from the Component class instead of Behaviour.
Behaviour inherits from Component.
MonoBehaviour:
The most important thing to note about MonoBehaviour is that you need it when you have to use corutines, Invoking, or any Unity callback functions such as physics OnCollisionEnter function, Start, OnEnable, OnDisable, etc.
MonoBehaviour inherits from Behaviour so that your scripts can be enabled/disabled.
No, that's wrong. The SO answer is misleading and the author actually admits this in various comments below his answer. While it is true that the $$anonymous$$onoBehaviour base class is derived from Behaviour and Behaviour is derived from Component, only $$anonymous$$onoBehaviour can be used as base class for your own classes. Do not just copy information untested.
When you derive a class directly from Component or Behaviour you won't be able to attach this class to a gameobject in the editor. The Editor will show a dialog that the script is not derived from $$anonymous$$onoBehaviour. Likewise when you try to add an instance through AddComponent at runtime you will get a warning that the type is not a valid Unity engine type and nothing will be added.
Component and Behaviour are just base classes and are only used for built-in classes. As I already said the actual built-in components are written in C++ and all the managed classes are just wrapper classes. This is also true for the Component and Behaviour class. The "$$anonymous$$onoBehaviour" class is a special Behaviour type which can actually be extended in the $$anonymous$$ono / .NET scripting environment. The ScriptableObject class is the other Unity engine related class which you can use as base class. Under the hood the Unity engine uses the same c++ class for both $$anonymous$$onoBehaviour and ScriptableObject on the native code side.
