- Home /
C# Question - Do I Have to inherit from MonoBehaviour? What happens if I don't?
If I make a class Inventory that "does" not inherit from monobehavior.
and this class is where i keep track of my players items.
Can I instantiate this class In my player class like so?
Inventory bag = new Inventory(); // ?
Also every script in unity requires to be on a gameobject ? so I can't just have classes built and use them within the code?
Answer by duck · Oct 30, 2010 at 10:47 AM
Yes, your classes don't have to inherit from MonoBehaviour, and you can instantiate them in the normal way (using 'new').
Inheriting from MonoBehaviour simply gives your scripts extra abilities, such as being able to:
- be placed on gameobjects
- have public vars which can be adjusted in the inspector
- receive Unity events such as Start() Update() FixedUpdate() etc.
It's worth noting that while you can instantiate other classes using 'new', you shouldn't use 'new' to create new instances of your MonoBehaviour scripts. This is because there are many areas where the functionality of the Monobehaviour relies on assuming that it's attached to a GameObject, and if you create a new one without it being attached to a GO, it can cause it to malfunction and give errors.
For this reason, to create a new instance of a MonoBehaviour at runtime, you should always use AddComponent to create and attach it to an existing gameobject at runtime.
It also removes abilities which is getting REALLY FRUSTRATING. I.$$anonymous$$ the ability to have a base class inherit from $$anonymous$$onobehaviour, then a subclass that inherits from that, is stuck with monobehaviour and can no longer add new instances of classes to a list in the parent (management class) via the "new" keyword..
Answer by fherbst · Oct 30, 2010 at 09:16 AM
Yes, you can do that if you want - but in many cases, it's easier and better to use MonoBehaviours.
Scripts aren't gameObjects - they are Components - and this is only required for scripts which can be added to gameObjects as Components (that is, in the Editor or via AddComponent) and which have Update and Start and so on called automatically.
But yes, you can use classes and stuff the same way you would in "non-unity3d" programming.
What you can do, too, is to inherit from a class which is a MonoBehaviour (you have class A : MonoBehaviour -
> you can create class B : A
and it can be used in the editor).
Oh, and maybe you have to put your custom classes in a folder called "Plugins" to be accessable from other scripts ('cause of compilation order).
No, you don't have to put custom classes in a separate folder - that's only for if you're mixing languages (eg, trying to use Javascript and C# classes together). If all your code is in the same language, they can all access each other just fine.
Okay, than I mixed that things up a bit :). Thanks for clarifying.
Your answer
Follow this Question
Related Questions
C# Conception - Hide inherited members and functions 1 Answer
C# Inheritance, base class attributes, override and null object 1 Answer
Inherited class, trying to overwrite variable. 0 Answers
Can I call a class's method which inherit monobehaviour by a normal class? 0 Answers
Creating a pointer variable to a GameObject inside a class that does not extend MonoBehavior? [C#] 2 Answers