In the last article, we learned the distinctions between Triggers and Collisions. This time around, we’re going to learn how to communicate between scripts. Enabling our scripts to communicate with one another allows us to, for example, make better use out of the triggers we just learned about! Let’s get started.
Setting the scene
To begin, I have created a scene with two game objects. The first game object is a cube. I have set the cube to be a trigger, and I have also applied a material to make it transparent so that we can see things happening as they happen. The other game object is a sphere. The sphere has a rigid body, and gravity is being applied.
The sphere has been placed above the cube, so at this point when the game is started, the sphere just drops and passes right through the cube trigger.
Triggering an effect
The next thing we need is a script on our trigger object. Create a script in the usual fashion, apply it to the trigger object, then open the script. Next we create a new method in this script to take advantage of being a trigger. To do this, in the class create a void type method with the name OnTriggerEnter and a parameter of type Collider.
Whatever code is put within this method will now run every time a game object enters the trigger. The parameter of type Collider represents that game object entering the trigger. So with this we can do some very cool things.
Within this method, we are going to use the GetComponent method of the Collider object to access a specific component within that object. Components are the various features you can add to a game object, such as a RigidBody or Script.
For now, we’re going to do something relatively simple — we’re going to change the color of the triggering object. To do this, we need to access the Renderer component of the object and then assign a new color to the material.
Let’s dissect this line real quick. So “other” is the triggering object; the object that has entered our trigger and caused the OnTriggerEnter method to be called. We use the GetComponent method to get the Renderer component. Once we have that, we access the material of the renderer, and then the color of the material, which we then change to yellow. Let’s see this in action.
Great, it works! But there’s a problem — we didn’t actually do what we set out to do! We wanted to communicate between two scripts, but right now what we’re doing is manipulating the triggering object through the trigger’s script. Let’s do things properly now.
How to communicate
So for a script to communicate with another script, we need at least two scripts. Create another script, this time for the triggering object. Assign the script to the object and open it in the editor.
Within this script, we’re going to create a very simple method that again just changes the color of the triggering object. Create a new method of type void. Within this method, we’re going to put in virtually the same code we did before.
Note the public modifier on the method. This is a very important aspect, because if we do not set our method to public access we cannot call this method from another script. Which is the entirety of what we’re trying to do, so like I said — this is very important.
Now we need to modify the script on our trigger object. Go ahead and get rid of the previous code for changing the color, and instead of accessing the Renderer component we want to access our script. To do that, we need to know the name of the class we created in our triggering object’s script. This will be the type of component we get with the GetComponent method.
Once we have that, we then just simply call the method we created earlier.
As you can see, I have named the script on the triggering object to TriggeringObject, and I have named the method ChangeColor. These could be different for you, but I hope that you can see how it can be applied to your own code/projects.
Now the trigger’s script is actually communicating with the triggering object’s script. Let’s see the communication at work.
Once again, we see the color change upon entering the trigger. Exactly as intended!
So I’m guessing now you’re wondering — “What’s the point?” If I could get the effect I wanted with the first method, why bother with the script communication?
That’s a good question, but there are good reasons to do it this way. Here are a couple for you to think about:
- First, notice that this is a very simple example. When you’re working on a real project it can rapidly become very complex. Imagine if you wanted to perform more complex actions on the triggering object, or if you wanted different classifications of triggering objects, or if you wanted the effect of the trigger to change at different times or under different conditions. The code in the trigger could very quickly become unmanageable.
- Also, you may have certain properties of an object that you did not want to expose to the public. A script on that object could view and manipulate that data without exposing it.
Now we are really starting to access the power of scripting in Unity. In the next article, we’re going to explore that even further by taking our first look at Coroutines. Until then, good luck and happy coding!