6.3 Combat & Ability Systems

You have already built characters that move, collide, and react to input. This chapter is about giving those characters a combat system: a way to deal damage, take damage, die, cast abilities like fireballs or heals, and apply effects like poison or a speed buff. This is the core loop of almost every action or gacha game — HoYoverse titles like Genshin Impact and Honkai: Star Rail are built on exactly the pieces in this chapter, just with a lot more content stacked on top.

The goal here is not just "make numbers go down." The goal is to build it so a designer (someone who is not a programmer) can add a brand new skill by filling in some numbers in the Unity Editor, with zero new code. That one idea — data-driven design — shapes almost every choice in this chapter.

1. What a combat system is, and why we decouple it

Break "combat" into small, separate jobs. Each job should be its own piece of code that barely knows the others exist:

• Health — how much damage something can take before it dies, and telling the rest of the game when it got hit or died.
• Hit detection — deciding what got hit, using colliders, raycasts, or a query of a region.
• Abilities — the actual skills: a fireball, a heal, a dash-strike. Their cost, cooldown, damage, and effects.
• Status effects — temporary changes applied to a character: poison ticking damage, a slow, a damage buff.

The word for keeping these jobs separate is decoupling (removing direct, hard-wired dependencies between pieces of code, so each piece can change without breaking the others). A coupled combat system might have a Fireball() method written directly inside your PlayerCharacter class, checking if (target is EnemyGoblin) and doing something special for that one enemy type. A decoupled one has a generic Ability that works on anything with a Health component, cast by anything with an AbilityRunner component — player, enemy, or boss, it does not matter. This chapter builds it the decoupled way from the ground up.

Keep that picture in your head. Every section below builds one box in it. By section 10 you will see the whole thing wired together with real code.

2. Health: taking damage, dying, and telling other systems about it

Every damageable thing in the game — the player, an enemy, a destructible crate — needs the same small set of behavior: hold a current HP, lower it when hit, clamp it at 0, and know when it has died. We start with an interface (a contract listing methods a class promises to have, no code inside, from an earlier chapter) so anything can be a valid target, not just one specific class.

public interface IDamageable
{
    void TakeDamage(float amount, GameObject source);
}

Now the real Health component. It lives on any GameObject that can be hurt, and it fires events (a way for one object to announce "something happened" so others can react, from the delegates/events chapter) so UI, animation, and AI can respond without Health knowing they exist.

using UnityEngine;
using System;

public class Health : MonoBehaviour, IDamageable
{
    [SerializeField] private float maxHp = 50f;
    private float currentHp;

    public bool IsDead { get; private set; }
    public float CurrentHp => currentHp;

    // other systems subscribe to these; Health never asks who is listening
    public event Action<float, float> OnDamaged;   // (amount, hpAfter)
    public event Action OnDied;

    void Awake()
    {
        currentHp = maxHp;
    }

    public void TakeDamage(float amount, GameObject source)
    {
        if (IsDead) return;              // dead things don't take more damage

        currentHp = Mathf.Max(0f, currentHp - amount);
        OnDamaged?.Invoke(amount, currentHp);
        Debug.Log(gameObject.name + " took " + amount + " dmg, hp = " + currentHp);

        if (currentHp <= 0f)
        {
            IsDead = true;
            OnDied?.Invoke();
            Debug.Log(gameObject.name + " died");
        }
    }
}

Trace what happens when a Goblin GameObject with maxHp = 50 takes two hits:

// somewhere else, e.g. a weapon script
Health goblinHealth = goblin.GetComponent<Health>();
goblinHealth.TakeDamage(20f, null);
goblinHealth.TakeDamage(40f, null);

Console output:

Goblin took 20 dmg, hp = 30
Goblin took 40 dmg, hp = 0
Goblin died

Notice hp stopped at 0, not -10 — Mathf.Max(0f, ...) clamps it. Notice also the if (IsDead) return; guard at the top: without it, a third hit after death would fire OnDamaged and possibly OnDied again, which confuses anything listening (a death animation playing twice, for example).

Any script can now listen without Health ever knowing it exists:

void Start()
{
    Health h = GetComponent<Health>();
    h.OnDied += () => Debug.Log("Play death animation, disable AI, drop loot");
}

3. Hit detection: hitboxes, raycasts, and overlap queries

Health.TakeDamage only fires once something decides who got hit. That decision is hit detection, and Unity gives you three common approaches. Each one fits a different kind of attack.

Hitbox colliders — good for melee swings, weapon trails

A hitbox is a Collider marked as a trigger (a collider that detects overlap but does not physically push things), attached to a weapon or a bone, that you turn on only while the attack should be able to connect. Unity calls OnTriggerEnter automatically whenever something enters it.

using UnityEngine;

[RequireComponent(typeof(Collider))]
public class HitboxController : MonoBehaviour
{
    public float damage = 10f;
    private Collider hitboxCollider;

    void Awake()
    {
        hitboxCollider = GetComponent<Collider>();
        hitboxCollider.isTrigger = true;
        hitboxCollider.enabled = false;      // off until the attack says so
    }

    public void Activate()   { hitboxCollider.enabled = true;  }
    public void Deactivate() { hitboxCollider.enabled = false; }

    void OnTriggerEnter(Collider other)
    {
        IDamageable target = other.GetComponent<IDamageable>();
        if (target != null)
        {
            target.TakeDamage(damage, gameObject);
        }
    }
}

The important part is Activate() / Deactivate() — the collider only exists, for hit purposes, during a short window. That window is exactly what section 4 is about.

Raycasts — good for hitscan and precision checks

A raycast fires an invisible line from a point in a direction and reports the first thing it hits. It costs one call, resolves instantly, and needs no collider glued to a weapon. It fits guns, arrows that travel too fast to simulate, or "is there a clear line to the target."

public void FireHitscan(Vector3 origin, Vector3 direction, float range, float damage)
{
    RaycastHit hit;
    if (Physics.Raycast(origin, direction, out hit, range))
    {
        IDamageable target = hit.collider.GetComponent<IDamageable>();
        if (target != null)
        {
            target.TakeDamage(damage, gameObject);
        }
        Debug.Log("Raycast hit " + hit.collider.name + " at distance " + hit.distance);
    }
    else
    {
        Debug.Log("Raycast hit nothing");
    }
}

Overlap queries — good for AoE bursts, ground slams

An overlap query (Physics.OverlapSphere, OverlapBox) asks "what is inside this shape right now?" and returns every collider it finds in one call. There is no swing, no travel time — it checks a single instant, which is exactly what an explosion or a ground-slam wants.

public void GroundSlam(Vector3 center, float radius, float damage)
{
    Collider[] hits = Physics.OverlapSphere(center, radius);
    foreach (Collider col in hits)
    {
        IDamageable target = col.GetComponent<IDamageable>();
        if (target != null)
        {
            target.TakeDamage(damage, gameObject);
        }
    }
    Debug.Log("Ground slam hit " + hits.Length + " colliders");
}

4. Timing a hit: active frames and windup/recovery

An attack is not "on" the whole time it plays. Fighting games split an attack into three phases, and the same idea applies to any action game:

• Windup — the character winds up (raises the sword). No hit can land yet. The attacker can sometimes still be hit or interrupted here.
• Active frames — the short window where the attack can actually connect. This is when the hitbox is turned on, the raycast fires, or the overlap query runs.
• Recovery — the follow-through. The attack can no longer land, and the character is often briefly vulnerable or unable to act.

Here is a melee attack built as a coroutine (a method that can pause and resume across frames using yield, which you have used before for timed sequences). It turns the hitbox from section 3 on only during the active window.

using System.Collections;
using UnityEngine;

public class MeleeAttacker : MonoBehaviour
{
    public HitboxController weaponHitbox;
    public float windupTime = 0.15f;
    public float activeTime = 0.15f;
    public float recoveryTime = 0.25f;
    private bool isAttacking = false;

    public void Attack()
    {
        if (isAttacking) return;          // ignore input mid-swing
        StartCoroutine(AttackSequence());
    }

    private IEnumerator AttackSequence()
    {
        isAttacking = true;

        Debug.Log("Windup start");
        yield return new WaitForSeconds(windupTime);

        Debug.Log("Active frames start");
        weaponHitbox.Activate();
        yield return new WaitForSeconds(activeTime);
        weaponHitbox.Deactivate();
        Debug.Log("Active frames end");

        yield return new WaitForSeconds(recoveryTime);
        Debug.Log("Recovery end, can act again");

        isAttacking = false;
    }
}

Trace an Attack() call with the numbers above (0.15s windup, 0.15s active, 0.25s recovery):

Windup start                       (t = 0.00s)
Active frames start                (t = 0.15s)
Active frames end                  (t = 0.30s)
Recovery end, can act again        (t = 0.55s)

Anything that enters the hitbox between t = 0.15s and t = 0.30s gets hit. Before or after that window, the hitbox is off — walking into the character during windup or recovery does nothing at all.

5. Why abilities should be data, not code

Now the interesting part. Say you hard-code a fireball:

public class PlayerCharacter : MonoBehaviour
{
    public void CastFireball(GameObject target)
    {
        if (mana < 30f) return;
        mana -= 30f;
        target.GetComponent<IDamageable>()?.TakeDamage(25f, gameObject);
        // ...cooldown logic, effects, all written by hand, right here...
    }
}

This works for one ability. Add ten more and PlayerCharacter grows a method for each one, all copy-pasted with slightly different numbers. Want a designer to try "Fireball does 40 damage instead of 25, and costs 45 mana"? They need to find you, you need to edit code, recompile, and hand it back. In a real studio that is hours of wasted time, every single day, for every tuning pass.

The fix is a ScriptableObject (a Unity class that holds data and lives as an asset file in your project — not attached to a GameObject in a scene, just sitting in your Project window like a texture or a prefab). One Ability script, written once, can produce unlimited different ability assets — Fireball, Heal, Dash Strike — each just a different set of numbers filled in through the Inspector. No new code for a new ability.

Concretely: instead of one PlayerCharacter script full of if-statements, you get one AbilityData class (next section) and one AbilityRunner component (section 7) that can play back any ability asset a designer drags into a list. New skill = new asset, filled in through the Inspector, zero new lines of code.

6. The Ability asset: cost, cooldown, damage, effects

The [CreateAssetMenu] attribute adds a right-click menu entry in the Unity Editor ("Create > Combat > Ability") so a designer can make a new ability asset without touching a script at all.

using UnityEngine;

[CreateAssetMenu(menuName = "Combat/Ability", fileName = "NewAbility")]
public class AbilityData : ScriptableObject
{
    [Header("Identity")]
    public string abilityName = "New Ability";

    [Header("Cost and timing")]
    public float manaCost = 10f;
    public float cooldown = 2f;

    [Header("Effect")]
    public float damage = 15f;
    public StatusEffectData[] appliedEffects;   // buffs/debuffs/DoT this ability applies (section 9)
}

(StatusEffectData is another small ScriptableObject, covered fully in section 9 — for now just know it is a data asset describing one buff, debuff, or damage-over-time effect, the same way AbilityData describes one ability.)

Once this script exists, a designer right-clicks in the Project window, picks Create > Combat > Ability, and fills in the Inspector — no code involved:

Make a second asset, Heal.asset, with a separate negative-damage convention or a dedicated healAmount field, and you already have two abilities using the exact same code. This is the whole point: the class is code, written once by a programmer; the asset is data, made as many times as needed by a designer.

7. The Ability Runner: spending resources and starting cooldowns

The AbilityData asset is just numbers — it has no idea who is casting it, how much mana they currently have, or what is on cooldown. That live, per-character state belongs on a MonoBehaviour attached to the caster: the Ability Runner (sometimes called an ability "caster" or "executor").

using System.Collections.Generic;
using UnityEngine;

public class AbilityRunner : MonoBehaviour
{
    public float currentMana = 100f;
    public float maxMana = 100f;

    // per-instance cooldown state: which ability, how much time is left
    private Dictionary<AbilityData, float> cooldowns = new Dictionary<AbilityData, float>();

    void Update()
    {
        if (cooldowns.Count == 0) return;

        // snapshot the keys first -- you cannot modify a Dictionary
        // while a foreach is walking over it
        List<AbilityData> keys = new List<AbilityData>(cooldowns.Keys);
        foreach (AbilityData key in keys)
        {
            float remaining = cooldowns[key] - Time.deltaTime;
            if (remaining <= 0f) cooldowns.Remove(key);
            else cooldowns[key] = remaining;
        }
    }

    public bool CanCast(AbilityData ability)
    {
        if (cooldowns.ContainsKey(ability)) return false;
        if (currentMana < ability.manaCost) return false;
        return true;
    }

    public bool TryCast(AbilityData ability, GameObject target)
    {
        if (!CanCast(ability))
        {
            Debug.Log("Cannot cast " + ability.abilityName + " (on cooldown or not enough mana)");
            return false;
        }

        currentMana -= ability.manaCost;
        cooldowns[ability] = ability.cooldown;

        target.GetComponent<IDamageable>()?.TakeDamage(ability.damage, gameObject);

        StatusEffectController statuses = target.GetComponent<StatusEffectController>();
        if (statuses != null && ability.appliedEffects != null)
        {
            foreach (StatusEffectData effect in ability.appliedEffects)
                statuses.ApplyEffect(effect);
        }

        Debug.Log(gameObject.name + " cast " + ability.abilityName + " on " + target.name
                   + " (mana left: " + currentMana + ")");
        return true;
    }
}

Trace it: a Wizard has 50 mana and a Fireball asset with manaCost = 30, cooldown = 4, damage = 25. Cast it on a 50-hp Goblin at t = 0, then try again at t = 1:

// t = 0
runner.TryCast(fireball, goblin);   // succeeds

// t = 1  (only 1 second has passed, cooldown is 4)
runner.TryCast(fireball, goblin);   // fails

Goblin took 25 dmg, hp = 25
Wizard cast Fireball on Goblin (mana left: 20)
Cannot cast Fireball (on cooldown or not enough mana)

8. Keeping abilities decoupled from the character

Look back at TryCast: it never once wrote Player, EnemyGoblin, or any concrete character class. It only asked target.GetComponent<IDamageable>() and target.GetComponent<StatusEffectController>(). This is the barrel-and-goblin idea from the interfaces chapter, applied to combat: if it implements IDamageable, it is a legal target — the ability system does not care what it actually is.

// three completely different classes, none related by inheritance,
// all valid Fireball targets because all implement IDamageable
public class Health : MonoBehaviour, IDamageable { /* section 2 */ }

public class DestructibleCrate : MonoBehaviour, IDamageable
{
    public void TakeDamage(float amount, GameObject source)
    {
        Debug.Log("Crate smashed open!");
        Destroy(gameObject);
    }
}

public class ShieldGenerator : MonoBehaviour, IDamageable
{
    public float shieldHp = 200f;
    public void TakeDamage(float amount, GameObject source)
    {
        shieldHp -= amount;
        Debug.Log("Shield generator hp: " + shieldHp);
    }
}

The same AbilityRunner.TryCast(fireball, someTarget) line now works whether someTarget is a player, a goblin, a crate, or a boss's shield generator, with zero changes to AbilityRunner. That is what "decoupled" buys you in practice.

The other half of decoupling is: who calls TryCast? AbilityRunner does not know or care. A player-controlled character calls it from an input script; an enemy calls it from an AI script. Both simply sit on top of the same AbilityRunner component.

// player side
public class PlayerInput : MonoBehaviour
{
    public AbilityRunner runner;
    public AbilityData fireball;

    void Update()
    {
        if (Input.GetKeyDown(KeyCode.Q))
        {
            GameObject target = FindClosestEnemy();
            runner.TryCast(fireball, target);
        }
    }
}

// enemy side -- same AbilityRunner, different decision-maker
public class SimpleEnemyAI : MonoBehaviour
{
    public AbilityRunner runner;
    public AbilityData fireball;
    public GameObject player;

    void Update()
    {
        if (runner.CanCast(fireball) && DistanceToPlayer() < 10f)
        {
            runner.TryCast(fireball, player);
        }
    }
}

AbilityRunner has no if (isPlayer) anywhere in it. The input script and the AI script are the only pieces that know who is deciding when to cast. Swap a player for an AI-controlled boss and the whole ability system keeps working, unchanged.

9. Status effects: buffs, debuffs, and damage over time

A status effect is a temporary change applied to a character: damage over time (DoT) like poison or burn, a debuff that weakens them (a slow, reduced damage), or a buff that strengthens them (haste, a damage boost). Like abilities, we want these to be data, not a hard-coded class per effect.

using UnityEngine;

[CreateAssetMenu(menuName = "Combat/StatusEffect", fileName = "NewStatusEffect")]
public class StatusEffectData : ScriptableObject
{
    public string effectName = "Poison";
    public float duration = 5f;
    public float tickInterval = 1f;        // how often it deals damage
    public float damagePerTick = 4f;       // 0 for a pure buff/debuff with no DoT
    public float moveSpeedMultiplier = 1f; // 1 = no change, 0.5 = half speed
}

Applying it needs some runtime state per active effect (how much time is left, when the next tick fires) — that lives in a plain C# class, not the ScriptableObject, for the same reason cooldowns live on the runner and not on AbilityData.

using System.Collections.Generic;
using UnityEngine;

public class ActiveEffect
{
    public StatusEffectData data;
    public float timeRemaining;
    public float tickTimer;
}

public class StatusEffectController : MonoBehaviour
{
    private List<ActiveEffect> active = new List<ActiveEffect>();
    private IDamageable damageable;

    void Awake()
    {
        damageable = GetComponent<IDamageable>();
    }

    public void ApplyEffect(StatusEffectData data)
    {
        active.Add(new ActiveEffect { data = data, timeRemaining = data.duration, tickTimer = data.tickInterval });
        Debug.Log(gameObject.name + " gained " + data.effectName);
    }

    // a simple modifier system: multiply every active effect's speed modifier together
    public float GetMoveSpeedMultiplier()
    {
        float multiplier = 1f;
        foreach (ActiveEffect effect in active)
            multiplier *= effect.data.moveSpeedMultiplier;
        return multiplier;
    }

    void Update()
    {
        // walk backwards so RemoveAt does not skip the next item
        for (int i = active.Count - 1; i >= 0; i--)
        {
            ActiveEffect effect = active[i];
            effect.timeRemaining -= Time.deltaTime;
            effect.tickTimer -= Time.deltaTime;

            if (effect.tickTimer <= 0f && effect.data.damagePerTick > 0f)
            {
                effect.tickTimer = effect.data.tickInterval;
                damageable?.TakeDamage(effect.data.damagePerTick, gameObject);
            }

            if (effect.timeRemaining <= 0f)
            {
                Debug.Log(gameObject.name + " lost " + effect.data.effectName);
                active.RemoveAt(i);
            }
        }
    }
}

Trace a Burn effect (duration = 3, tickInterval = 1, damagePerTick = 4) applied to a 50-hp Goblin at t = 0:

Three ticks of 4 damage each over 3 seconds, then the effect removes itself. Because damagePerTick and moveSpeedMultiplier are just numbers on an asset, the exact same StatusEffectController code handles a poison DoT, a burning debuff, and a "Haste" buff with moveSpeedMultiplier = 1.5 and damagePerTick = 0 — no new classes needed.

10. Putting it together: the full data flow

Here is every piece from this chapter in one picture, following a single button press from input to the target reacting.

Follow the arrows and notice what talks to what: AbilityRunner talks to the target only through IDamageable and StatusEffectController — two small, generic contracts. Health never talks to AbilityRunner at all; it just fires events into the void and lets whoever cares subscribe. The AbilityData and StatusEffectData assets are read many times by many characters but never written to at runtime. Every arrow in that picture is a small, specific connection — nothing needs to know the whole diagram to do its own job.

11. Combos: chaining abilities in a short window

A combo just means: if the player presses attack again soon enough after the last one, chain into the next step instead of restarting. The whole mechanism is a timestamp and a short window.

using UnityEngine;

public class ComboController : MonoBehaviour
{
    public float comboWindow = 0.6f;   // seconds allowed between hits to keep the combo alive
    public AbilityData[] comboSteps;   // e.g. [ Slash1, Slash2, Slash3 ]

    private int comboIndex = 0;
    private float lastAttackTime = -999f;
    public AbilityRunner runner;

    public void OnAttackInput(GameObject target)
    {
        float sinceLastAttack = Time.time - lastAttackTime;

        if (sinceLastAttack > comboWindow)
        {
            comboIndex = 0;                     // too slow: combo reset to the start
        }

        AbilityData step = comboSteps[comboIndex];
        runner.TryCast(step, target);
        Debug.Log("Combo step " + comboIndex + ": " + step.abilityName);

        comboIndex = (comboIndex + 1) % comboSteps.Length;
        lastAttackTime = Time.time;
    }
}

Trace three attack presses at t = 0.0s, t = 0.3s, and t = 1.5s, with comboWindow = 0.6s and three combo steps:

The second press landed inside the window (0.3s <= 0.6s), so it advanced to step 1. The third press came 1.2 seconds after the second — past the window — so it reset back to step 0 instead of continuing to step 2. Notice each combo step is just a different AbilityData asset cast through the same AbilityRunner from section 7: the combo system decides which ability to cast next, and needs no damage or cooldown logic of its own at all.

12. Glossary

• Combat system — the set of systems that deal and take damage, cast abilities, and apply effects.
• Decoupling — removing direct, hard-wired dependencies so pieces of code can change independently.
• IDamageable — an interface with a TakeDamage method; anything implementing it is a valid combat target.
• Event (Action) — a way for an object to announce something happened without knowing who is listening.
• Hitbox — a trigger collider, usually attached to a weapon, turned on only while an attack can connect.
• Raycast — an instant line test that reports the first thing it hits; good for hitscan and line-of-sight checks.
• Overlap query (OverlapSphere/OverlapBox) — finds everything inside a shape at one instant; good for AoE bursts.
• Active frames — the part of an attack's timeline where the hit detection is actually turned on.
• Windup / recovery — the phases before and after the active frames, when no hit can land.
• Data-driven design — building systems that read behavior from data (assets, numbers) instead of hard-coding it per case.
• ScriptableObject — a Unity class whose instances live as asset files in the project, good for shared, read-mostly data.
• Ability asset — a ScriptableObject instance describing one skill's cost, cooldown, damage, and effects.
• Ability Runner (caster) — the per-character MonoBehaviour that spends resources, tracks cooldowns, and applies an ability's effects.
• Cooldown — the time an ability is unusable after being cast.
• Resource cost — a stat (mana, stamina, energy) spent to cast an ability.
• Status effect — a temporary change applied to a character: a buff, a debuff, or damage over time.
• Damage over time (DoT) — a status effect that deals damage repeatedly on a timer instead of once.
• Stat modifier — a value that changes a base stat, such as a move speed multiplier from a slow or a haste effect.
• Combo window — the short time after an attack during which the next input chains into the next combo step instead of resetting.

13. Exercises

Health h = enemy.GetComponent<Health>();
h.TakeDamage(15f, null);
h.TakeDamage(10f, null);
h.TakeDamage(20f, null);
h.TakeDamage(5f, null);

Enemy took 15 dmg, hp = 25
Enemy took 10 dmg, hp = 15
Enemy took 20 dmg, hp = 0
Enemy died

That is a full combat and ability system: a decoupled Health/IDamageable pair for taking damage, three hit detection tools picked by the shape of the attack, active-frame timing so hits only land in the right window, AbilityData assets so designers add skills without code, an AbilityRunner that owns the live cooldown/resource state, a StatusEffectController for buffs/debuffs/DoT built from the same data-driven idea, and a small combo layer on top that just picks which ability asset to cast next. Every piece talks to the others only through an interface or an event — that is what makes it possible to add ability number fifty without touching ability number one.