Let’s say i have a Player script attach to player and then an Enemy script which is attach to all enemies in the scene like 20 enemies. If player killed one enemy then i have to call the EnemyDied Function. If i make a delegate EnemyKillDelegate which will invoke when player killed any enemy then it will call the registered function EnemyDied, but in this case EnemyDied of every enemy will call which is definitely not what i want.
Is there a way to specifically call the EnemyDied function of the enemy script which is died.
I know i can GetComponent of Enemy which is died then call the function but is there any different way to do this
public class Player : MonoBehaviour
{
//This Scrip is attach to only Player
public static event Action EnemyKillDelegate;
void EnemyDied()
{
EnemyKillDelegate?.Invoke();
}
}
public class Enemy : MonoBehaviour
{
//This Scrip is attach to every enemy in the scene
private void OnEnable()
{
Player.EnemyKillDelegate += EnemyDied;
}
private void OnDisable()
{
Player.EnemyKillDelegate -= EnemyDied;
}
void EnemyDied()
{
Debug.Log("I am Dead");
}
}
What @Llama_w_2Ls said in the comments above essentially already answered the question. However I want to make some things clear. It seems you have the wrong idea why you would use a delegate / event and what general approach is behind an event. If the player provides an event that other objects can subscribe to, it means every subscriber gets the same event. It’s literally like a real world subscription. Say you have subscribed for a certain magazine. Every month when a new edition is published, every subscriber gets the same thing. That’s the point of such a subscription.
So in this case the “event” is raised by the magazine company when they have a new edition and each of their subscibers gets the same thing.
What you have described doesn’t sound like an event that all enemies are interested in. So it makes no sense to raise such an event if not all enemies want to know about that event. The events you talked about are individual events and the only two parties involved are the player and one particular enemy. So as Llama_w_2Ls said, having the player inform the particular enemy about its fate directly is the only logical approach. This would be similar to something like the police is calling you about the progress of a case that you filed. It makes no sense that the police calls every person in town about your case.
One could think of a reverse event that the enemy may provide. So when the enemy dies, the enemy may have an event that the player can subscribe to. So when the enemy dies, the enemy is raising the event, informing anyone who wants to know about the death of this particular enemy. Of course that means the player would have to subscibe manually to that event for each enemy individually. However since the death of an enemy is usually triggered by an action of the player, it makes more sense to use direct communication. So the player who knows who he is attacking can directly reach out to a certain script on that particular enemy and call a “Hit” or “AddDamage” method on the enemy. That method may return a bool value if the enemy died during that hit / attack so the player could react to that. Though keep in mind to keep things seperated. So anything related to the death animation of the enemy should be handled by the enemy script inside the Hit / AddDamage method which is probably called from the player’s Attack method. The enemy can return information to the caller, so the player knows if the enemy died or not.
The player script should not be responsible to tell the enemy to play the death animation. That should happen implicitly in the “Hit” method of the enemy once the HP drops to 0 (or whatever game mechanic you’re using). That’S the main point of OOP. Object oriented just means you have objects which encapsulate state (variables) as well as behaviour (methods that describe that behaviour). OOP is about constructing meaningful abstract interactions between objects and keep the object relevant code inside that object.
A common approach for many games is, that each enemy may have an OnDeath event which it raises when the enemy dies. Since the enemy is usually created by some sort of game manager, that manager could subscribe a callback to each enemy when it creates the enemy. That way the manager gets informed when an enemy dies. Note that such an event could have an argument of type Enemy. That way the dieing enemy could pass a reference to itself (this) so the manager actually knows who raised the event. The manager may wants to know about the death for statistical purposes or game mechanic purposes. So when an enemy dies it may increase the kill count and maybe spawn a new / the next enemy as a result. There are many possible usecases.