Game hitstop and hit pause explained

What hitstop is (and what it is not)

At the frame damage is applied, the engine pauses or slows selected entities — usually both combatants, sometimes the whole scene — for N simulation frames before resuming normal speed. Animation playback, physics integration, and AI ticks halt; VFX and audio often continue or trigger on that frozen frame so the strike reads as a single beat.

Hitstop is not the same as:

• Hitstun — the defender's recovery window after being hit; hitstop is milliseconds at impact, hitstun is the follow-on disabled state.
• Slow motion — global time scale below 1.0 for dramatic effect; hitstop is a discrete freeze, often 1–12 frames.
• Animation blending lag — unintentional stutter from bad transitions; hitstop is authored and tied to damage events.
• Frame advantage in fighters — related but distinct; hitstop extends the visual beat; frame data defines whether you can act first after.

Players rarely name hitstop, but they feel its absence immediately: combat without freeze frames reads as skating on ice; with tuned hitstop, even low-poly assets feel heavy.

Why a few frozen frames change everything

Human perception needs roughly 80–120 ms to register a causal link between action and reaction. At 60 fps, one frame is ~16.7 ms. Three frames (~50 ms) is often enough to “stick” attacker and defender together at impact; six frames (~100 ms) reads as unmistakably heavy.

Perceptual jobs hitstop performs

• Confirms contact — separates wind-up, active, and impact even when hitboxes overlap for a single frame.
• Sells weight — greatswords get longer freeze than rapiers without slowing entire movesets.
• Chunks combos — each hit in a string becomes a discrete beat instead of a smear.
• Amplifies critical moments — boss staggers, parry ripostes, and finishers get extra frames so players savor the payoff.
• Masks net latency — a brief freeze on confirmed hits gives rollback fighters time to reconcile without visible teleporting (when used carefully).

Attacker vs defender asymmetry

Not every game freezes both sides equally. Common patterns:

• Symmetric freeze — both combatants pause for N frames. Default in fighting games and many action RPGs; simplest to tune and network.
• Defender-only — attacker animation continues while defender freezes in hit react. Reads as bullying through weak enemies; can feel unfair in PvP unless telegraphed.
• Attacker bias — attacker gets 100% of hitstop, defender 50%. Preserves combo flow while still selling impact on the victim.
• Scene freeze — entire simulation including projectiles pauses. Maximum drama for supers; dangerous in multiplayer if overused.

Harbor Ruins uses symmetric freeze for normal hits, 150% duration on the defender during guard break, and a 12-frame full scene freeze on boss stagger — three tiers players learn to recognize without UI prompts.

Scaling hitstop: damage, weapons, and attack types

Flat hitstop on every attack makes light jabs feel sluggish and heavies feel weak. Most teams scale duration with one or more axes:

Encode curves in data: hitstopFrames = baseWeapon + floor(damage / damagePerFrame), clamped to [min, max]. Designers tune one table per weapon class instead of per-move animation.

Implementation: frame counters, not timers

Hitstop must be deterministic and framerate-independent in intent. The robust pattern:

1. On OnDamageApplied, set remainingHitstopFrames on affected entities from attack metadata.
2. Each simulation tick, if remainingHitstopFrames > 0, skip physics/AI/animation advance for that entity; decrement counter.
3. Fire VFX/SFX on frame 0 of hitstop; they may play during freeze.
4. Queue input during hitstop; resolve on first active frame after (fighters call this buffering).

Avoid Time.timeScale = 0 for per-hit feedback — it pauses UI, audio ducking, and unrelated systems. Prefer entity-local freeze flags integrated with your combat tick. For fixed-timestep engines, hitstop consumes simulation steps without advancing animation clocks, or advances animation at 0× speed — pick one convention and document it for animators.

Pairing with juice: shake, flash, and audio

Hitstop is the spine; other feedback hangs on it:

• Screen shake — start on frame 0 of hitstop, decay during or after release. Shaking during freeze sells impact; shaking after feels like aftermath.
• Hit flash / white sprite — one-frame material swap visible because simulation paused.
• Audio — punchy transient at freeze start; avoid stretching sounds across paused frames unless using unscaled time.
• Camera zoom — micro zoom-in (2–5%) on heavies; coordinate with camera collision so walls do not clip.
• Controller rumble — short impulse matching hitstop duration; sync matters more than intensity.

Stagger effects so they do not compete: hitstop first, then shake peak, then damage number float. When everything spikes the same frame, readability drops.

Combos, poise, and defensive systems

Hitstop interacts with systems documented in adjacent guides:

• Combo strings — total hitstop per string adds up; cap cumulative freeze per second so 10-hit juggles do not turn into slideshows.
• Poise break — bonus hitstop on stagger gives players time to notice the opening.
• Parry riposte — extended freeze on perfect parry frames the counter as a cinematic beat without a cutscene.
• Super armor — attacker may ignore defender's hit-react freeze while still applying hitstop to victim, or vice versa for hyper-armor trades.

Document whether hitstop extends the defender's hitstun clock or runs in parallel. Extending hitstun makes freeze feel punitive; parallel keeps competitive frame data stable.

Multiplayer and rollback

In networked fighters and action games, hitstop must be agreed by both clients:

• Apply hitstop only on confirmed hits (server or rollback prediction with correction), not on whiff visuals.
• Keep durations integer frames so lockstep and rollback resim match.
• Scene-wide freeze in PvP is rare; prefer per-entity freeze to avoid stalling unrelated players.
• Log hitstop events in replay files for dispute resolution in esports titles.

Rollback netcode can use a few frames of hitstop as implicit buffer while reconciling — but hiding systematic latency behind freeze trains players to distrust responsiveness. Use sparingly.

Accessibility and reduced motion

Hitstop, screen shake, and flash together trigger vestibular symptoms for some players. Ship a reduced combat effects toggle that:

• Halves or removes hitstop duration (keep audio/haptic confirmation).
• Disables camera shake and zoom independently.
• Replaces full-screen flash with outline highlight.

Competitive integrity modes may cap hitstop rather than remove it entirely so frame data stays teachable — document the tournament preset separately from the accessibility preset.

Harbor Ruins brawler refactor (worked example)

Problem: Six weapon classes shared one damage callback with no freeze. Combos at 60 fps looked like a single smeared animation; heavies did not feel heavier than lights.

Changes:

1. Added HitstopProfile ScriptableObject per weapon: base frames, damage scalar, crit bonus, block multiplier.
2. Central CombatFeelSystem.ApplyHitstop(attacker, defender, profile) called from the existing damage pipeline after poise resolution.
3. Tiered scene freeze on boss stagger (12f) and riposte (8f) only.
4. Paired 0.15 s camera shake (scaled by weapon) starting on freeze frame 0.
5. Cumulative cap: max 18 frames hitstop accumulated per defender per second.

Results: Average combo readability score +38% in blind tests; heavy weapon pick rate rose from 12% to 27% because weight was finally legible. No change to raw DPS numbers — only feel.

Genre decision table

Common pitfalls

• Uniform hitstop everywhere: lights feel mushy; differentiate or remove freeze on rapid jabs.
• Too many frames: beyond ~12f at 60 fps players blame performance; test on 30 fps consoles where frame doubles.
• Global timeScale abuse: pauses menus, timers, and other players; use entity-local flags.
• Hitstop without hit confirm: freezing on whiff breaks trust; tie to damage event, not animation notify alone.
• Unbounded combo freeze: juggles become unwatchable; enforce per-second caps.
• Ignoring accessibility: mandatory heavy shake + flash + long freeze excludes players; provide independent toggles.
• Desync in multiplayer: fractional timers or float durations cause rollback mismatches; stick to integer frames.

Practitioner checklist

• Wire hitstop to confirmed damage events, not animation wind-ups alone.
• Define per-weapon HitstopProfile with base, damage scale, crit bonus, block multiplier.
• Implement entity-local frame counters integrated with combat tick and animation.
• Cap cumulative hitstop per defender per second for juggle strings.
• Pair with screen shake, flash, audio, and rumble on a staggered timeline.
• Document whether hitstop extends hitstun or runs in parallel for frame-data docs.
• Blind test heavies vs lights after tuning; players should rank weight correctly without UI.
• Add reduced combat effects toggle (hitstop, shake, flash independent).
• Verify integer-frame behavior under rollback or server-authoritative netcode.
• Profile worst-case 8-enemy brawls; scene-wide freeze is O(n) design debt.

Key takeaways

• Hitstop is a brief simulation freeze at damage registration — the cheapest way to sell impact.
• Scale duration by weapon weight and attack tier; flat values flatten combat readability.
• Use entity-local frame counters, not global time scale, for precise control.
• Pair freeze frames with shake, flash, and audio on a deliberate timeline.
• Cap cumulative freeze, support reduced-motion toggles, and keep multiplayer frames deterministic.

Related reading

• Game melee combat systems explained — hitboxes, poise, knockback, and weapon archetypes
• Game combo systems explained — string structure, juggle rules, and cancel windows
• Game combat systems explained — damage pipelines, i-frames, and team-wide combat architecture
• Game camera systems explained — follow cameras, shake, and collision-safe zoom