Using constructors in Unity (C#)
I would find it very useful to initialize values in constructors for many of my classes, but I just read in the scripting reference the following :
"Never initialize any values in the constructor. Instead use Awake or Start for this purpose. Unity automatically invokes the constructor even when in edit mode. This usually happens directly after compilation of a script, because the constructor needs to be invoked in order to retrieve default values of a script. Not only will the constructor be called at unforeseen times, it might also be called for prefabs or inactive game objects.
Using the constructor when the class inherits from MonoBehaviour, will make the constructor to be called at unwanted times and in many cases might cause Unity to crash. Only use constructors if you are inheriting from ScriptableObject."
Is it really so dangerous or can I use them anyway? For example, I want to instantiate various weapons in my game and give them random stats (damage, range, etc...) using a constructor that initializes these values. Would this cause problems? Or how would I use this "ScriptableObject" they mentioned? Can scripts inheriting from ScriptableObject be attached to gameObjects?
So how are you supposed to instantiate the class by passing values to it? (Nobody mentions this..unbelievable.)
Answer by Daniel-Brauer · Nov 01, 2010 at 06:15 PM
As the documentation says, you shouldn't implement (and definitely shouldn't call) constructors for MonoBehaviours. One of the reasons for this is that in the best-case scenario, your constructor will be called when the game starts, and then the contents of the instance will be over-written by de-serialized data as Unity loads up your scene file.
If you want initialization code to run when the game starts, use Start() or Awake(). Awake() will be called immediately as part of the instantiation process. Start() will be called before the first Update() call that the newly instantiated object gets.
ScriptableObjects are non-Behaviour Objects that Unity lets you serialize as stand-alone assets. They're for storing data that doesn't belong to a specific level or prefab. GUISkins are a good example of a ScriptableObject.
Oh, I didn't know that about ScriptableObjects
. Good to know, thanks!
A good alternative is to create a public virtual Setup()
method that can be inherited across your classes and called immediately after being created.
Answer by Ferb · Nov 15, 2014 at 05:25 PM
For what it's worth, I've done this before. I was new to Unity but experienced in C#, so I naturally tended to do things that way. The only problem I had was that any Unity-specific code, like accessing the Transform for instance, wouldn't work in the constructor, assumably because Unity hadn't initialised those things at that stage. But if the code was just initialising basic variables or just using .NET libraries, I never had any problems with it. I think the dangers are probably overstated, but I avoid it now anyway, just because you can't call the constructors you make, which limits their usefulness (because the constructors can't have any arguments, and can't be overloaded). You can make a public initialise function and call it on the Monobehaviour derived object just after initialising it, which effectively does the same thing and avoids any harm and allows you to control the calling of it.
Answer by xeophin · Nov 01, 2010 at 05:23 PM
You can easily use the Start()
method to initialise and randomise the values of your weapons it is automatically called when an object becomes part of a scene, and it should make no difference for you (apart from the fact that, yes, technically, Start()
is not the constructor ;) ).
Answer by Mike 3 · Nov 01, 2010 at 05:25 PM
If you instantiate a monobehaviour via the constructor, things would go pretty bad fast - it'll be only the c# side of the component, and won't be attached to an object
Adding the constructor itself is usually a bad idea too - it'll load the code at random times
Instead, think about adding an Init method with all the parameters you'd use in the constructor
Answer by Tumbo The Gnome · Mar 03, 2015 at 12:20 AM
One pattern that I've been experimenting with lately to aid with inheritance involves using the constructor to subscribe to event/delegates defined in the base class. For example:
public class Example : MonoBehaviour
{
public delegate void ExampleAction();
protected ExampleAction awakeAction;
protected ExampleAction startAction;
protected ExampleAction updateAction;
protected ExampleAction customEvent;
private void Awake()
{
if(this.awakeAction != null)
{
this.awakeAction();
}
}
private void Start()
{
if(this.startAction != null)
{
this.startAction();
}
}
private void Update()
{
if(this.updateAction != null)
{
this.updateAction();
}
}
public void CustomEvent()
{
if(this.customEvent != null)
{
this.customEvent();
}
}
}
public class Test : Example
{
public Test()
{
this.awakeAction += () =>
{
Debug.Log("Awake");
};
}
}
public class Example : MonoBehaviour
{
public delegate void ExampleAction();
protected ExampleAction awakeAction = delegate { };
protected ExampleAction startAction = delegate { };
protected ExampleAction updateAction = delegate { };
protected ExampleAction customEvent = delegate { };
private void Awake() => this.awakeAction();
private void Start() => this.startAction();
private void Update() => this.updateAction();
public void CustomEvent() => this.customEvent();
}
public class Test : Example
{
public Test()
{
this.awakeAction += () => Debug.Log("Awake");
}
}
Your answer
Follow this Question
Related Questions
Changing an argument to a var and vice-versa 0 Answers
Null reference exception instatiante? 0 Answers
NullReferenceException problems. 0 Answers