Listeners
There is still an issue that the HealthBar.cs
script is in charge of registering itself as a listener and at the same time defining what happens when a Event is raised. We need to seperate its concerns! This brings us to the third concept of Unity Atoms, Listeners. A Listener listens (sometimes also referred to as observes or subscribes) to an Event and responds by firing off zero to many responses. Listeners are MonoBehaviours and therefore live in a scene. They can be seen as the glue between Events and Actions.
The HealthBar.cs
script from our last example is actually a Listener, but a very specific implementation of it. We can do better than that! Lets create a Game Object in our scene and call it HealthListener
. Unity Atoms comes with some predefined Listeners. In this case we want to listen to an IntEvent
so we will press the Add Component button on our HealthListener
, create an IntEventReferenceListener
and drop in the HealthChangedEvent
:
We can now shave off some of the code in our HealthBar.cs
script to look like this:
using UnityEngine;
using UnityEngine.UI;
using UnityAtoms.BaseAtoms;
public class HealthBar : MonoBehaviour
{
[SerializeField]
private IntConstant MaxHealth;
public void ChangeFillAmount(int health)
{
GetComponent<Image>().fillAmount = 1.0f * health / MaxHealth.Value;
}
}
And then go back to our HealthListener
’s IntEventReferenceListener
component, press the +
to add an Unity Event Response, drop in the HealthBar
component (from the scene) and point out the ChangeFillAmount
function defined above:
The HealthBar.cs
script is now only responsible for what happens when our player’s health is changing. Pretty great, huh?