Guide

Game projectile clash systems explained

Harbor Brawl's beta roster had a clear problem: Ember, the zoning mage, won 71% of neutral rounds against rushdown characters without ever pressing a normal attack. Players threw fireballs; opponents threw fireballs back; both projectiles vanished in a satisfying burst of particles. Everyone assumed the system was mutual destruction — fair and symmetric. Telemetry told a different story: Ember's heavy orb carried priority tier 2 while the rushdown's light shot was tier 1. On “clash,” Ember's orb survived with one durability point and continued across the screen, often hitting a recovering opponent who believed they had traded evenly. Playtesters called it random. Designers had authored asymmetric priority without surfacing it anywhere in training mode.

Projectile clash systems define what happens when two hostile projectiles overlap: destroy both, destroy one, absorb with durability, pass through, or escalate to a cinematic beam duel. They sit between engine projectile simulation (movement, pooling, netcode) and combat zoning and neutral design. Clash rules determine whether a zoning character is oppressive or merely strong, whether reflects are mandatory, and how frame advantage after a blocked projectile compares to winning a clash outright. This guide covers clash taxonomies, priority and durability models, beam versus ballistics edge cases, interaction with reflect and parry, the Harbor Brawl refactor, a technique decision table, pitfalls, and a production checklist.

What a projectile clash is

A clash occurs when two active hostile projectiles (or a projectile and certain defensive volumes) occupy overlapping collision regions in the same simulation tick. Unlike character hitboxes, projectiles are often semi-persistent entities: fireballs, ice shards, energy discs, or continuous beams. The clash resolver runs before or after hit detection depending on engine order, but the design question is always the same: who keeps threatening space after the overlap?

Clashes are not universal. Many action RPGs simply let projectiles pass through each other; first hit on a character wins. Fighting games and arena brawlers usually implement explicit clash logic because projectiles are primary neutral tools. Without clashes, two zoners would ignore each other's space control and matches devolve into who lands the wider hitbox first — often the character with lower latency or longer limbs.

Core clash outcomes

Outcome	Behavior	Player read
Mutual destroy	Both projectiles despawn on overlap	“We traded fireballs evenly.”
Priority win	Higher-tier projectile survives; lower despawns	“My heavy beat their light.”
Durability consume	Both lose one durability; survivor continues if any remains	“My three-hit orb ate their shot and kept going.”
Pass through	No interaction; both continue	Rare in fighters; common in horde shooters
Absorb / nullify	Defender-specific aura destroys projectile without clash FX	Overlaps with super armor or projectile invuln
Reflect redirect	Ownership flips; clash may be skipped	See reflect guide; clash and reflect order matters

Priority tiers and durability

Priority (sometimes called clash level or attack level for projectiles) is an integer or enum assigned per projectile instance. When tiers differ, the higher tier wins outright unless durability rules intervene. When tiers are equal, designers choose mutual destroy, durability trade, or a random tie-break — random ties are almost always a mistake in competitive titles.

Durability counts how many clashes or hits a projectile can absorb before despawning. A slow-moving three-hit fireball might have durability 3 and priority 1. It loses one durability per clash with equal or lower tier; a higher-tier shot might wipe it entirely. Durability enables visible “big orb” fantasy without making the move invincible: each clash shrinks the visual and ticks down an internal counter.

Super-projectile and invincible flags

Supers and EX moves often spawn projectiles with super armor on the projectile entity itself — not just on the character. Flags like clash_immune, beat_all_non_super, or only_clash_with_super prevent low-risk normals from trading with high-cost specials. Document these flags in move specs; playtesters will otherwise file “my fireball lost to nothing” bugs that are intentional but opaque.

Beams (continuous line traces) need special cases: some games treat beams as infinite priority during active frames; others use tick-based durability so multiple small shots can “eclipse” a beam briefly. Beam versus ballistics is a frequent source of inconsistent feel if not specified in the clash matrix.

Clash resolution order

Implementation order affects fairness and netcode. A common pipeline per tick:

Advance projectile transforms (see ballistics integration in the projectile systems guide).
Detect projectile–projectile overlaps via swept circles, AABB, or physics layers filtered to hostile projectiles.
Sort pairs by spawn time or network sequence if multiple overlaps occur same frame.
Apply clash matrix (priority, durability, flags).
Spawn clash VFX and SFX at overlap midpoint for readability.
Run projectile–character hit detection on surviving entities.

If character hits run before clashes, a player can take damage from a projectile that should have been destroyed a millisecond earlier — especially under rollback netcode. Many fighters run clashes first for same-frame overlaps. Reflect volumes complicate ordering: if reflect triggers on the same frame as a clash, specify whether reflect or clash wins when both apply.

Neutral and zoning implications

Clash rules are a hidden half of zoning. A character with tier-2 lows and tier-1 highs forces opponents to use committal heavies to win projectile wars — which opens jump-ins and whiff punishes. Symmetric mutual destruction favors the player who recovers faster after throwing; check throw recovery frames against opponent's next spawn time.

When clashes are too symmetric, zoners cannot hold space and rushdown dominates. When priority is too skewed, one character auto-wins neutral without meter spend. Target: intentional asymmetry with clear telegraphs (bigger glow = higher tier) and training-mode clash outcomes on command.

Multi-projectile moves (shing shing shing kicks that emit three shards) need per-shard clash data. A single heavy clash should not delete an entire spread unless designed as an anti-zoning tool with explicit balance budget.

Harbor Brawl fireball clash refactor

Harbor's fix for Ember had four parts:

Published clash matrix — tier 0 (light), tier 1 (normal), tier 2 (heavy/EX). Lights mutually destroy with lights; heavies beat lights; equal heavies mutual destroy unless EX flag set.
Durability on heavy orb only — reduced from implicit infinite to durability 2 with visible shrink per clash.
Training mode clash readout — on overlap, UI shows “WIN / LOSE / TRADE” for one second; replay stores clash events.
Rushdown answer — added a tier-1 dash-attached shot with faster recovery so winning a trade enables approach before next enemy spawn.

Ember's neutral win rate vs rushdown fell from 71% to 54% without nerfs to damage or speed. Player sentiment shifted from “random” to “learnable” once the training readout shipped.

Technique decision table

Your situation	Prefer	Avoid
Symmetric footsie fireball characters	Mutual destroy on equal tier	Hidden priority on identical-looking shots
Big slow orb vs fast jab projectile	Durability on orb; jab cleans one layer	Orb immune to all clashes
EX / super projectile payoffs	Explicit super tier beating normals	Same tier as normals with higher damage only
Beam supers	Documented beam clash rules vs balls	Reusing ball clash code without beam tests
Rollback multiplayer	Deterministic clash order by tick + spawn ID	Physics engine random contact order
Reflect-heavy roster	Clash before reflect; reflect flips ownership	Clash destroying reflected projectiles silently

Common pitfalls

Asymmetric priority without player feedback. If heavies win clashes, the VFX and training UI must say so.
Same-frame ordering bugs. Clash after hit resolves unfair damage; test same-tick overlap exhaustively.
Beam treated as a single frame. Continuous beams need per-tick clash or invuln windows, not one-shot spheres.
Durability on everything. Overusing durability makes normals feel mushy; reserve for signature zoning tools.
Ignoring off-screen spawns. Clashes off-camera still consume durability and confuse spectators; cull or pause off-screen logic consistently.
Clash VFX louder than hit VFX. Players misread trade outcomes when clash particles obscure the surviving projectile.

Production checklist

Define priority tier enum and clash matrix in design doc before implementation.
Assign per-move durability, super flags, and beam vs ballistics class.
Run clash resolution before character hit when same-frame overlap is possible.
Log clash events (move IDs, tiers, outcome) for balance telemetry.
Add training mode clash outcome labels (WIN / LOSE / TRADE).
Surface tier visually on projectiles (scale, color, trail) for learnability.
Test equal-tier, +1 tier, and super-vs-normal cases per character.
Verify reflect and clash interaction order with scripted repro cases.
Regression-test rollback: two clients throw on same frame, outcomes match.
Document beam clash rules separately from spherical projectiles.
Balance neutral win rates after clash changes, not only damage numbers.
Pair clash tuning with throw recovery and frame advantage on blocked pokes.

Key takeaways

Projectile clashes decide who owns space after two shots meet — mutual destroy, priority, and durability are the main levers.
Hidden priority asymmetry feels random; Harbor Brawl fixed Ember by publishing tiers and training-mode readouts.
Clash resolution order relative to character hits and reflects is a netcode and fairness requirement, not an implementation detail.
Beams and multi-shard moves need explicit clash rules beyond the standard fireball matrix.
Zoning balance lives in clash data as much as in damage and recovery frames.