❤️ Lesson 7.1: Health & Damage with Interfaces

Why an Interface for Damage?

Imagine an attack script that has to hurt whatever it hits. The naive version grows a tangle of type checks:

// ❌ The coupling trap — this only gets worse
if (hit.TryGetComponent<Enemy>(out var enemy))       enemy.Damage(10);
else if (hit.TryGetComponent<PlayerHealth>(out var p)) p.Hurt(10);
else if (hit.TryGetComponent<Barrel>(out var barrel)) barrel.Break();
// ...a new branch every time you add a destructible thing

Every new destructible object forces you to edit the attacker. The attacker ends up knowing about every type in the game — the exact coupling Module 2 warned against. An interface flips this around: the attacker depends on one small contract, and any object that can be hurt promises to honour it.

// ✅ The interface way — this line never changes
hit.GetComponent<IDamageable>()?.TakeDamage(10);

One line, forever. Add a new destructible barrel next year and the attacker doesn't care — as long as the barrel implements IDamageable, it just works.

The IDamageable Contract

Keep the contract tiny. The only thing an attacker truly needs is a way to deal damage. We will also expose current and max health as read-only properties, because UI and AI often want to know them.

public interface IDamageable
{
    // Read-only state anyone can query
    float CurrentHealth { get; }
    float MaxHealth { get; }
    bool IsDead { get; }

    // The one action every attacker calls
    void TakeDamage(float amount);
}

Notice what is not here: there is no Heal, no Die, no reference to a particle effect. The contract is only what a caller from outside genuinely needs. Healing is an ability of the Health component, not something an attacker asks for, so it lives on the concrete class rather than in the shared interface. Keep interfaces minimal — a small contract is easy to honour and hard to misuse.

The Health Component

Now the workhorse: a single Health MonoBehaviour that implements the contract. Drop it on any GameObject that should be hurtable. It owns the numbers, clamps them, and refuses to take damage once dead.

using UnityEngine;

public class Health : MonoBehaviour, IDamageable
{
    [SerializeField] float maxHealth = 100f;
    float currentHealth;

    // --- IDamageable contract ---
    public float CurrentHealth => currentHealth;
    public float MaxHealth => maxHealth;
    public bool IsDead => currentHealth <= 0f;

    void Awake()
    {
        currentHealth = maxHealth;
    }

    public void TakeDamage(float amount)
    {
        if (IsDead || amount <= 0f) return;    // ignore hits on a corpse

        currentHealth = Mathf.Max(currentHealth - amount, 0f);

        if (currentHealth == 0f)
            Die();
    }

    public void Heal(float amount)
    {
        if (IsDead || amount <= 0f) return;    // can't heal the dead
        currentHealth = Mathf.Min(currentHealth + amount, maxHealth);
    }

    void Die()
    {
        // death handling goes here — we'll flesh this out below
    }
}

A few deliberate choices worth calling out:

• maxHealth is [SerializeField] so you set it per-object in the Inspector — 100 for the player, 30 for a grunt, 10 for a barrel. Same script, different numbers.
• We clamp with Mathf.Max/Mathf.Min so health never goes negative or overshoots the maximum.
• Dead things ignore damage. The IsDead guard stops a barrel from "dying" five times if three bullets land in the same frame.
• The properties are expression-bodied (=>) getters — they expose the numbers without letting outside code overwrite them.

Events: OnHealthChanged & OnDied

Here is where Module 2's events pay off. When health changes, a health bar should redraw. When something dies, a score counter might tick up, a ragdoll might spawn, an enemy spawner might get told to make another. The Health component must not know about any of those systems — it just announces what happened and lets whoever is listening react.

We use C# events (the Action pattern from Lesson 2.2). OnHealthChanged passes the new fraction (0–1) so a bar can fill itself; OnDied passes the source Health so a listener knows who died.

using System;
using UnityEngine;

public class Health : MonoBehaviour, IDamageable
{
    [SerializeField] float maxHealth = 100f;
    float currentHealth;

    // Fired whenever health changes: passes a 0..1 fraction for UI bars
    public event Action<float> OnHealthChanged;
    // Fired once, when this object dies: passes itself so listeners know who
    public event Action<Health> OnDied;

    public float CurrentHealth => currentHealth;
    public float MaxHealth => maxHealth;
    public bool IsDead => currentHealth <= 0f;

    void Awake()
    {
        currentHealth = maxHealth;
    }

    public void TakeDamage(float amount)
    {
        if (IsDead || amount <= 0f) return;

        currentHealth = Mathf.Max(currentHealth - amount, 0f);
        OnHealthChanged?.Invoke(currentHealth / maxHealth);

        if (currentHealth == 0f)
            Die();
    }

    public void Heal(float amount)
    {
        if (IsDead || amount <= 0f) return;
        currentHealth = Mathf.Min(currentHealth + amount, maxHealth);
        OnHealthChanged?.Invoke(currentHealth / maxHealth);
    }

    void Die()
    {
        OnDied?.Invoke(this);
    }
}

The ?.Invoke(...) null-conditional call means "fire this only if someone is actually subscribed" — no listeners, no error. This is the same safe-invoke pattern you used in Lesson 2.2.

A health bar now becomes trivial and completely decoupled — it never looks up the player, it just listens:

using UnityEngine;
using UnityEngine.UI;

public class HealthBar : MonoBehaviour
{
    [SerializeField] Health health;   // drag any Health here
    [SerializeField] Image fill;      // the bar's fill Image

    void OnEnable()  => health.OnHealthChanged += UpdateBar;
    void OnDisable() => health.OnHealthChanged -= UpdateBar;

    void UpdateBar(float fraction) => fill.fillAmount = fraction;
}

Handling Death

Death means different things to different objects. The player triggers a game-over screen; an enemy plays a death animation then despawns; a barrel spawns splinters and is destroyed instantly. If we bake any of that into Health, it stops being reusable.

The clean split: Health only announces death through OnDied. Per-object behaviour lives in small listener scripts. Here are three, each attached alongside a Health:

using UnityEngine;

// On the barrel: pop and disappear
public class BarrelDeath : MonoBehaviour
{
    [SerializeField] Health health;
    [SerializeField] GameObject splinterVfx;

    void OnEnable()  => health.OnDied += Shatter;
    void OnDisable() => health.OnDied -= Shatter;

    void Shatter(Health _)
    {
        if (splinterVfx) Instantiate(splinterVfx, transform.position, Quaternion.identity);
        Destroy(gameObject);
    }
}

using UnityEngine;

// On the enemy: play a death anim, then clean up
public class EnemyDeath : MonoBehaviour
{
    [SerializeField] Health health;
    [SerializeField] Animator animator;

    void OnEnable()  => health.OnDied += HandleDeath;
    void OnDisable() => health.OnDied -= HandleDeath;

    void HandleDeath(Health _)
    {
        animator.SetTrigger("Die");        // from Module 1's Animator
        GetComponent<Collider>().enabled = false;
        Destroy(gameObject, 2f);           // give the animation time to play
    }
}

Same Health component on both — the difference is entirely in who is listening. This is exactly the decoupling goal of Module 2: the thing that owns the data broadcasts, and the things that care subscribe.

💡 Where should the player's game-over live? Give the player its own PlayerDeath listener that subscribes to the same OnDied event and calls into your UI/scene manager. The Health component still has no idea a "game over" screen exists — and that is the point.

One Contract, Many Implementers

Step back and look at the shape of the whole system. A single attacker talks to a single interface, and any number of objects implement it. Nothing on the left knows about anything on the right except the contract in the middle.

Figure 1: One attacker depends only on IDamageable. Every hurtable object implements it, and each reacts to death in its own listener — the attacker is oblivious to all of it.

Because Health already implements IDamageable, making a new object destructible is a two-step chore with zero code: add the Health component, set its maxHealth in the Inspector. Want a death effect? Add a small listener. The attacker code you wrote once never changes again — that is the entire promise of programming to an interface.

Hands-on Challenge

Summary

🚀 What's Next?

You have the contract and the component — but so far we have only simulated hits by clicking. In Lesson 7.2: Hit Detection: Raycasts & Hitboxes you'll deal real damage: hitscan weapons with Physics.Raycast and layer masks, melee swings with trigger colliders and OverlapSphere, and a quick look at projectiles — all funnelling into the very same GetComponent<IDamageable>()?.TakeDamage() call.