Script Communication in Unity using GetComponent

This is just an article on communicating with other scripts in Unity by using the GetComponent method, as well as a couple ways of handling any exceptions which might arise.

By creating an instance of a class (an ‘object’, such as an instance of a custom class deriving from Monobehaviour on a GameObject) we can create a reference to it in order to, for instance, call one of the class’s public member methods or read (or edit) one of its public variables. For instance the following variables and methods on one script would be accessible to another script because of the ‘public’ access modifier we’ve provided:

All we need to do is to create a reference to the script on the object in question. If we know objects with the tag ‘Player’ should have a Monobehaviour script on them called ‘Player’, then we can use GetComponent to get a reference to it and perform some logic on it:

We can, however, use GetComponent for most of the components available in Unity. The only exception from my understanding is the Transform component as this is accessible by default (i.e. other.gameobject.transform is used rather than other.GetComponent<Transform>()). This means we can access, for example, an image or sprite renderer component in order to change an GameObject’s sprite, or perhaps access and adjust the settings of its AudioSource component. The logic hinges, however, on the specified component actually being on the GameObject, so we’ll typically get a null reference exception if the method is unable to retrieve the desired component. In order to get around this, we can perform a quick and easy null check such as this one:

An alternative would be to use a try and catch statement instead, which will first attempt the code within the ‘try’ block and then attempt to run the ‘catch’ block if it runs into any errors/exceptions:

The try and catch statement, for better or worse, will equally catch other types of exceptions (perhaps if we could successfully find the component, we might still run into a different error when we try to access or manipulate something with it).

I also recommend leaving a debug message using Debug.Log(“Message here”), Debug.LogWarning(“Message here”), or Debug.LogError(“Message here”) depending on the severity of what’s just gone wrong/what the code’s been unable to find. We can leave this in a subsequent else statement (after an if statement) or within the catch statement.

Finally, it’s also generally good practice to create a shorter reference to the component we’re after once we’ve successfully retrieved it:

In this example, ‘player.MyAccessibleFunction()’ and ‘other.GetComponent<Player>().MyAccessibleFunction()’ are functionally the same, it’s just a shorter and cleaner to create a reference you can repeatedly use rather than writing out the method each time. It also, I suppose, allows for a level of abstraction, as once I’ve retrieved the component I want I’m really not that interested in ‘other’ anymore.

And with that, I think that’s most of what I’d like to jot down and/or teach about using the GetComponent method in Unity 😉

// nb. do also take a look at the TryGetComponent method to see if that’ll suit your needs: Unity — Scripting API: Component.TryGetComponent (unity3d.com)