Using constructors in Unity (C#)

Questions & Answers
1

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?

4

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.

5

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.

2

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

6

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");
        };
    }
}
3

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

7

In my opinion:

Start() and Awake() are not equivalent to the constructor because ExecuteInEditMode + Serialization + closing/reopening Unity will result in calling Start/Awake 2+ times.

I tried multiple things (many of which crashed Unity) until I found out that initializing fields where they are defined seems to work perfectly.

Example:

class EditorObject : MonoBehaviour
{
    private void mutate() // callers of this code expect changes to be persistent (e.g. when Unity quits/reopens)
    {
        mutable_in_editor.Add(1);
    }

    private void Awake()
    {
        // mutable_in_editor = new List<int>(); // Bad: overwrites serialized object when Unity is reopened
    }

    [SerializeField] private List<int> mutable_in_editor = new List<int>(); // Good: initializing a field immediately results in constructor-like behaviour.
}
8

@hiltonvarian1 You can use Constructors in unity as long as you do not use it when classes inherit MonoBehavier or Scriptable Objects. I have Used Constructors in unity and it works perfectly Fine. No Problem at all. You also can use interfaces in unity to and abstract classes also and switch expression . You can also Make your own classes in Unity I Hope it Helps you all