Combat

One claim, one judge

Every hit in the kit — melee, thrown, hazard — is filed as a DamageClaim: a target, an amount, who dealt it, which sides it may hit, and optional knockback or stat-effect payloads. Nothing applies damage directly. A claim goes to CombatArbiter.FileClaim, and the arbiter — one per level scene, installed next to the round controller — is the only thing that ever calls IDamageable.ApplyDamage. That is what keeps friendly fire, self-hits and duplicate hits consistent regardless of which system detected the hit.

A claim that fails validation is rejected, not silently dropped — CombatArbiter.OnClaimRejected reports why:

// Add the arbiter to a level-root object at runtime
gameObject.AddComponent<CombatArbiter>();
// (The Setup window's Install places one in every generated level)

The CombatArbitercomponent is hidden from the Add Component menu on purpose because the Setup window's Install owns it — hand-placing one bypasses the installer's initialization.

What you see when it lands is a separate concern from whether it lands: CharacterFeedback watches the same accepted claim and health change every other system reacts to and plays a particle, a camera shake and a beat of hit-stop for it — see Feedback for the four stock definitions and how to wire your own.

Two kinds of target

Anything hit needs an IDamageable. The kit ships two: DamageableObject for scenery that keeps its own health with no CharacterStats involved (crates, breakable props, the shipped Target Dummy), and CharacterDamageable for characters, which routes every hit onto the existing health stat — so the HUD, the alive/dead event and multiplayer replication all follow with nothing extra to wire.

CharacterDamageable requires CharacterStats on the same object and adds no health field of its own — see Stats & Effects for how the health stat itself is configured. Add DamageReactionAnimator beside either kind of target to fire a Hit Animator trigger on every landed hit (it does nothing if the object has no Animator).

Melee

MeleeAttack reads the Attack action, runs a windup, then opens a child MeleeHitboxfor its active window. The hitbox is a trigger volume — parented under the character so Unity's own rule that colliders sharing a rigidbody never trigger each other keeps the attacker safe from their own swing by construction, not by filtering. Anything the hitbox overlaps while open takes one hit, once per swing.

The CombatShowcase level pairs both target kinds with the same swing: punch the shipped Target Dummy (a DamageableObjectwearing the goblin visual, health bar included) and a plain crate side by side, then pick up the floor sword to see the attacker's own stat move the number rather than the swing itself.

Thrown props

ChargeThrowInteractable is the pickup-and-throw half: holding Attack while carrying charges a throw from a lob up to a full-power arc, shown live by a ghost trajectory line, and releasing launches the prop. ThrownDamageSource is the in-flight half: it watches its own impact speed and files a claim — attributed to whoever threw it, not to the prop — on any collision fast enough to count as a hit rather than a bump. The two halves are never wired up separately in practice — ChargeThrowInteractable requires a ThrownDamageSourceon the same object, and Unity adds one automatically if it's missing.

A Building placeable can opt into this same stack via its Throwable When Placed flag, so a crate placed with the hammer can also be picked up and thrown.

The CombatShowcaselevel's Payload Zone lines up three pads whose only difference is what their damage carries — pure knockback, an effect, or nothing at all — so the payload half of a claim is easy to see in isolation from the damage half.

Multiplayer: server arbitrates, owner applies

CombatReplicatorplays the equivalent role for the arbiter itself (routing a client's claim to the server), and ThrownReplicatorkeeps a thrown prop's instigator and flight state in agreement across machines. All three are installed automatically — they never appear in the Add Component search, so a half-wired network stack can't be assembled by hand. See the Networking Dashboardto check whether a given player's combat rows are installed and, in Play mode, live.

Combat without code

The same arbiter backs three low-code nodes, so a hazard volume or a scripted trap deals damage through the identical pipeline a weapon hit does — armour, invulnerability and death all apply the same way. Apply Damage (an instruction) deals damage with the same amount/mask/knockback/effect shape as a claim; Launch gives an object a velocity change with an arc, mass-independent; Took Damage(a condition) watches a character's replicated health and passes for a configurable window after it drops — the one combat hook that fires identically on every peer, unlike the code-level CharacterDamageable.OnDamaged event, which only fires on the machine that resolved the claim. Full field-by-field reference lives on Stock Conditions & Instructions.

Worked example: a damage source of your own

Nothing about a damage source is special-cased — a hazard, a spike trap, a custom projectile all follow the same two steps: resolve a target, then file a claim.

1. Resolve the target

   DamageTargets.Resolve(collider.gameObject) walks up from any part (a limb collider, a child mesh) to the IDamageable on the whole object, or returns null — scenery walking into your volume is normal, not an error.

2. File a claim

   Build a DamageClaim and hand it to CombatArbiter.Active.FileClaim. The arbiter validates and, if accepted, delivers it — your code never calls ApplyDamage directly.

void OnTriggerEnter(Collider other)
{
    IDamageable target = DamageTargets.Resolve(other.gameObject);
    if (target == null) return;

    CombatArbiter.Active.FileClaim(new DamageClaim(
        target, amount: 10f, instigator: gameObject,
        CharacterGroupMask.Everyone, canHitInstigator: false));
}