Game combat systems explained

What a combat system is

A combat system is the runtime pipeline that answers four questions every frame: Can this attack connect? How much damage does it deal? What state does the target enter? What feedback does the player receive? The pipeline typically runs as: input → animation/state machine → active hitbox spawn → overlap test against hurtboxes → damage calculation → apply hitstun/knockback → trigger VFX/SFX/camera shake.

Real-time vs turn-based combat

Real-time combat resolves collisions every simulation tick (usually 30 or 60 Hz). Frame data, input buffers, and latency compensation dominate design. Turn-based combat resolves actions in discrete phases — initiative order, action points, or speed stats determine who acts when. Turn systems still need damage formulas and status effect rules, but timing is measured in turns rather than frames. Hybrid systems (real-time-with-pause, ATB bars) borrow from both; document which clock authority uses to avoid desync bugs.

Genre wrappers change presentation, not fundamentals. A fighting game light punch, a soulslike r1 swipe, and a twin-stick basic shot all traverse the same pipeline with different hitbox shapes, frame counts, and damage curves.

Hitboxes, hurtboxes, and collision layers

Hitboxes are offensive collision volumes attached to attacks — sword arcs, projectile paths, explosion radii. Hurtboxes are defensive volumes on characters and destructibles — body capsule, head sphere, weak-point patches. An attack connects when a hitbox overlaps a hurtbox on the same collision layer (e.g., player attacks hit enemy hurtboxes but not ally hurtboxes).

Shapes and trade-offs

• Axis-aligned boxes (AABB) — cheap to test, common in 2D fighters and retro games. Fast but imprecise on diagonals.
• Capsules and spheres — smooth body representation, standard for 3D character controllers. Easier to tune than mesh-accurate collisions.
• Oriented boxes and polygons — tighter fit for sweeps and precise weapons. Higher CPU cost; worth it for competitive fighters.
• Raycasts and hitscan — instant line tests for firearms. No travel time; latency-sensitive in multiplayer.

Debug visualization (toggle hitbox/hurtbox overlay in dev builds) is non-negotiable. Designers cannot tune fairness blind. Publish frame-data overlays in training modes for competitive titles.

Priority and clash rules

When two attacks overlap the same frame, define explicit priority rules: higher-priority moves win, both trade, or clash cancels. Without documented priority, players perceive randomness. Common patterns: supers beat normals, anti-airs beat jump-ins, projectiles clash at equal priority.

Frame data and invincibility

In real-time combat, actions are measured in frames (1/60 second at 60 fps). Every move has three phases:

• Startup — wind-up before the hitbox activates. Vulnerable; whiff punish window for opponents.
• Active — frames where hitboxes exist. The move can deal damage.
• Recovery — follow-through after active ends. Often punishable if the move missed.

Frame advantage measures who acts first after a block or hit: if your +5 light attack beats their 8-frame startup move, you win the exchange. Frame data is the grammar of fighting games; action RPGs use coarser timing (i-frames on dodge rolls) but the same math applies.

Invincibility frames (i-frames)

During certain actions — dodge rolls, backsteps, wake-up reversals, respawn invulnerability — hurtboxes are disabled or set to a “no damage” layer. I-frames must be short enough to require skill (3–12 frames typical) and telegraphed by animation. Granting i-frames on every attack creates unpunishable spam; withholding them from defensive tools makes dodging feel useless.

Input buffering

Buffer windows (5–10 frames) store inputs during recovery so combos feel responsive. Buffer too long and accidental inputs fire; too short and links feel stiff. Document buffer length per action class in your combat spec.

Damage formulas and scaling

Raw damage rarely equals displayed damage. Production systems apply a chain of modifiers:

final = floor(base * comboScaling * critMult * (1 - defenseReduction) * elementalMult)

Key design levers:

• Base damage — per-move constant tuned against target HP pools.
• Combo scaling — each hit in a chain deals less (e.g., 100%, 80%, 60%, 40% floor). Prevents infinite loops from one-shotting.
• Defense and armor — flat reduction, percentage reduction, or poise/stagger meters that gate hit reactions.
• Critical hits — probability-based spikes; cap crit rate and multiplier to keep variance readable.
• Damage types — physical, elemental, true damage that bypasses armor. Rock-paper-scissors adds build diversity but needs UI clarity.

Keep formulas in data tables (CSV, ScriptableObjects, JSON) so designers tune without recompiling. Log damage breakdowns in debug builds when QA reports “that hit felt wrong.”

Hit reactions, combos, and knockback

When damage lands, the target enters a hit reaction state: flinch, hitstun, knockdown, launch, or stagger. Reaction choice defines game feel:

• Hitstun — target locked in place, enabling combo chains.
• Knockback — displacement vector; essential for platform fighters and crowd control in brawlers.
• Launch / juggle — aerial state with gravity and air combo limits; cap juggle count to prevent infinite loops.
• Poise break — cumulative stagger before a critical hit reaction; common in soulslike design.

Hitstop (brief global freeze on impact) sells weight. Longer hitstop on heavy hits; shorter on light jabs. Overuse makes combat feel sluggish; underuse makes impacts feel floaty. Tune hitstop, camera shake, and audio transients together — they are one feedback system.

Enemy telegraphs and readability

Players can only respond to attacks they can read. Telegraphs are wind-up cues before damage: color flashes, audio stingers, ground markers, boss roars. Telegraph length should scale with damage — a 40-frame overhead that one-shots needs a longer wind-up than a 6-frame jab.

Telegraph tiers

• Tier 1 (reactable) — 20+ frames warning; teaches the move and rewards observation.
• Tier 2 (commitment test) — 10–20 frames; punishes panic rolling, rewards pattern knowledge.
• Tier 3 (pressure) — under 10 frames or mixed with feints; reserved for late-game or multiplayer human opponents.

Animation canceling telegraphs is a common fairness bug. If the wind-up animation plays but the hitbox spawns early, players learn the wrong timing. Sync active frames to the visual “impact frame” in the animation timeline.

Multiplayer authority and latency

Single-player combat runs one simulation clock. Multiplayer must decide who is authoritative for hit detection:

• Server authoritative — server validates hits; clients predict locally then reconcile. Best for competitive integrity; requires low server tick rate and lag compensation.
• Host authoritative — peer host decides; simpler but vulnerable to host advantage and cheating.
• Rollback (GGPO-style) — predict both sides, rewind on mismatch. Gold standard for fighting games; complex to implement.

Lag compensation rewinds hurtbox positions to match when the attacker pressed the button, not when the packet arrived. Without it, high-ping players cannot land hits they visually connect with. Cap rewind window (e.g., 150 ms) to prevent absurd edge cases.

Worked example: Harbor Arena duel

Harbor Arena is a 1v1 action duel with three weapons: Rapier (fast, low damage), Halberd (slow, high reach), and Shield + Mace (defensive, guard-break focus). Design targets: average duel 45–90 seconds, no single combo over 35% HP.

Rapier light attack

• Startup 4f / Active 3f / Recovery 8f on block (+2 advantage)
• Capsule hitbox: 0.8 m reach, 0.15 m radius
• Base damage 8; combo scaling 100/85/70/55%
• Hitstop 3 frames; minimal camera shake

Halberd heavy sweep

• Startup 18f / Active 6f / Recovery 22f (-8 on block, punishable)
• Arc hitbox: 2.4 m sweep, poise damage 40 (breaks light stance)
• Base damage 28; launches on counter-hit
• Telegraph: red ground arc at frame 6, audio cue at frame 10

Shield bash (counter tool)

• Startup 6f with i-frames 2–8 during bash
• Guard-breaks blocking opponents; 12 damage, +12 advantage on hit
• Whiff recovery 20f — high risk if baited

Netcode: server authoritative at 60 Hz with 120 ms lag compensation. Training mode shows frame data overlay and hitbox ghosts. Result: rapier players win neutral with speed; halberd players punish whiffs; shield players condition aggression then bash. No weapon exceeds 52% win rate in internal playtests after poise tuning.

Combat archetype decision table

Common pitfalls

• Animation without hitbox sync — damage before or after the visible swing; players distrust the system permanently.
• Invisible hitboxes — ranges larger than sprites; feels like unfair hits. Keep hitboxes within silhouette plus ~10% tolerance.
• Unbounded combo scaling gaps — one infinite loop destroys PvP and speedrun integrity. Cap scaling floor and juggle count.
• Same telegraph for different speeds — feints and mix-ups need distinct audio/visual cues or players guess.
• Client-side damage in multiplayer — trivial to cheat; always validate on server or host with checksums.
• Ignoring defensive scaling — HP pools grow but enemy damage stays flat; fights become tedious. Scale both sides.
• Hitstop on every projectile in horde modes — 50 enemies each causing 3-frame freeze = slideshow. Gate hitstop by attacker importance or cap concurrent hitstop.

Production checklist

• Document hitbox/hurtbox shapes per move in a shared combat spec sheet.
• Publish startup/active/recovery frame counts for every player action.
• Implement debug overlay toggles for hitboxes, frame advantage, and damage log.
• Store damage formulas and scaling curves in designer-editable data tables.
• Define collision layers and priority rules before first enemy ships.
• Sync active frames to animation impact markers in the authoring pipeline.
• Tune hitstop, camera shake, and SFX as a single impact feedback pass.
• Assign telegraph tiers to every enemy attack; playtest with fresh users.
• Choose netcode model early; prototype rollback or lag comp before art lock.
• Run automated regression tests for combo scaling caps and invincibility windows.

Key takeaways

• Combat systems are the shared pipeline from input to collision to damage to feedback — genre wrappers sit on top.
• Hitboxes and hurtboxes on explicit collision layers define what can connect; debug visualization is mandatory.
• Frame data and i-frames govern real-time fairness; turn-based systems trade frames for action economy.
• Damage formulas need combo scaling floors and data-driven tuning to prevent burst and infinite loops.
• Telegraphs and hitstop sell readability and impact; multiplayer needs authoritative hit validation with lag compensation.

Related reading

• Fighting game design explained — neutral, mixups, and roster balance on top of frame data
• Shooter game design explained — hitscan, TTK, and cover applied to ranged combat
• Health and damage systems explained — HP pools, shields, and survivability layers
• Encounter design explained — composing enemies and arenas around combat verbs