Game special cancel systems explained

Cancel taxonomy: what can cancel into what

Most fighters implement cancels as a directed graph: source move type, target move type, and conditions (hit, block, whiff). Document every edge explicitly; implicit cancels become balance bugs.

Separate cancel eligibility from frame data: a move can have 12 active frames but only allow cancel from frame 3–6 on hit. Publish both in your movelist export.

Cancel windows and gating conditions

A cancel window is the inclusive frame range during which the engine accepts a cancel input for the current move. Three gating dimensions matter:

• Temporal window — usually starts on first active frame or first hit confirm, ends before recovery. Some games allow late cancel on whiff for safety (SF-style late cancel into fireball).
• Contact condition — hit-only, block-only, or both. Hit-only cancels prevent safe blockstring extension into specials. Block-only cancels are rare (defensive escapes).
• Resource gate — meter segment, drive gauge, or stamina required before the cancel executes. Failed gate should fail visibly, not silently eat input.

struct CancelEdge {
  MoveId from;
  MoveId to;
  int window_start;      // relative to move start
  int window_end;
  CancelContact contact; // Hit, Block, Both, Whiff
  int meter_cost;
}

bool try_cancel(Character& c, MoveId target) {
  auto& move = c.current_move;
  if (c.frame < move.cancel_start || c.frame > move.cancel_end) return false;
  if (!contact_matches(move.last_contact, edge.contact)) return false;
  if (!spend_meter(c, edge.meter_cost)) return false;
  c.transition_to(target, inherit_velocity=true);
  return true;
}

Inherit velocity and facing on cancel transition unless the target move explicitly resets momentum — dropping velocity causes visible pops and online desync when animation blending differs.

Input buffer and cancel priority

Cancel systems interact tightly with input buffers. When a player presses special during a normal's startup, the buffer should resolve at the first legal cancel frame, not on the press frame. Common production rules:

• Buffer depth — 3–8 frames for cancel inputs; shorter buffers feel strict, longer buffers enable accidental cancels.
• Cancel vs chain priority — if both a chain and a cancel are valid, define precedence (usually cancel wins on hit, chain on whiff).
• Negative edge — releasing a button can trigger cancels in some engines; document whether release cancels share the same window as press cancels.
• Duplicate input suppression — mashing special during a cancel window should not queue three fireballs; consume buffer on success.

Pair cancel buffers with confirm training: players learn to press special only after seeing hit spark, but the engine should still honor early buffers for accessibility and online latency compensation.

Damage scaling and meter on cancel routes

Cancels often trigger proration or scaling rules separate from the base move:

• Cancel proration — damage after cancel may apply 0.8×–0.9× per cancel hop. Stack with combo scaling so multi-cancel routes do not one-touch kill.
• Meter gain on cancel — some games award bonus meter for cancel confirms; others tax meter on every cancel edge. Align with super meter economy.
• Hitstun extension — canceling early can truncate active frames and reduce total hitstun; simulate full routes in your combo lab before shipping cancel window changes.

Blockstring cancels into specials need extra scrutiny: if blockstun is long enough and cancel is block-valid, you have created a safe pressure loop. Either make the special minus on block or restrict cancel to hit-only.

Harbor Brawl refactor: cancel table as source of truth

Pre-patch Harbor Brawl stored cancel flags per move in scattered JSON blobs. Problems:

1. Three normals shared one animation but different cancel lists — skin swaps changed cancel routes.
2. Fireball cancel was block-valid from medium punch, enabling unpunishable blockstring chip loops.
3. Cancel window used a global constant (frames 4–18) instead of per-move active alignment — lights canceled before active on low-FPS clients.

The refactor:

• Central cancel_graph.csv exported from the combat design doc; build step validates every edge references real move IDs.
• Hit-only gating on all projectile cancels from normals; block-valid cancels limited to invincible reversal specials with high meter cost.
• Cancel windows authored as animation markers (cancel_open/cancel_close) synced to active frames.
• Training mode overlay: green bar for cancel window, red when contact condition fails (e.g., blocked when hit-only required).

Blockstring damage dropped because chip loops disappeared; confirm damage rose because players routed hits into intentional special sequences instead of mashing cancel on block.

Technique decision table

Common pitfalls

• Block-valid into unsafe specials. If cancel works on block and the special is -2, you have built an unpunishable loop — audit block advantage after every cancel edge.
• Cancel before active. Windows that open before hitboxes encourage pre-emptive mashing and break counter-hit neutral.
• Implicit cancels from animation reuse. Shared rigs must not inherit cancel lists; use move IDs, not clip names.
• Scaling blind spots. Multi-cancel routes bypass damage caps if each hop applies full damage before proration.
• Online rollback drift. Cancel acceptance must be deterministic from inputs and frame counters, not animation blend state.
• Whiff cancel safety without cost. Late cancel into projectile on whiff is fine if the projectile is punishable or costs meter.

Production checklist

• Author cancel graph (source, target, window, contact, meter) in a single validated table.
• Mark cancel_open and cancel_close on every cancelable move in the animation pipeline.
• Define hit-only vs block-valid per edge; audit block advantage after cancel.
• Apply cancel proration and combo scaling on every hop in the route simulator.
• Configure input buffer depth and cancel-vs-chain priority in the combat spec.
• Inherit velocity and facing on cancel transition unless target move resets.
• Suppress duplicate cancel inputs during the same window.
• Expose cancel windows and contact failures in training mode overlays.
• Test skin/animation variants for accidental cancel list inheritance.
• Validate rollback netcode reproduces cancel acceptance frame-perfectly.
• Publish cancel graph alongside frame data for tournament and mod communities.
• Re-run blockstring safety suite after any cancel window or gating change.

Key takeaways

• Special cancels are authored edges in a graph — source move, target move, frame window, and contact condition.
• Hit-only gating on projectile cancels prevents unpunishable blockstring loops.
• Cancel windows must align to animation active frames, not global constants.
• Buffer depth and cancel priority determine whether cancels feel intentional or accidental.
• Harbor Brawl's centralized cancel table cut blockstring chip abuse while raising intentional confirm damage.

Related reading

• Game hit confirm systems explained — reacting to contact before committing cancels
• Game frame data explained — startup, active, and recovery markers
• Game combo damage scaling explained — proration across cancel hops
• Game super meter and ultimate systems explained — meter cost on super cancels