Guide

Fighting game input notation explained

Harbor Brawl's closed beta logged thousands of “failed special” events on the same three moves. The quarter-circle fireball worked in the lab but failed in matches because each programmer had encoded a different notion of “down-forward.” One build required a cardinal down frame; another accepted diagonals only; a third counted simultaneous down+forward as a single tick. Players called the game inconsistent; telemetry showed a 34% success rate on 236+P (quarter-circle forward + punch) for intermediate testers. The combat refactor adopted standard numpad notation, published motion sheets beside frame data, and rebuilt the command reader with shared diagonal leniency and a 12-frame motion buffer. Special-move success on those three attacks rose to 75% with no animation changes.

Fighting game input notation is the shared language designers, players, and wiki authors use to describe motion commands — the directional sequences that trigger specials, supers, and cancels. It pairs with input buffering (when a press is accepted) and combo systems (what happens after the move starts). This guide covers numpad directions, common motion families (quarter circle, dragon punch, half circle, charge), button naming conventions, leniency and SOCD rules, command-reader implementation, the Harbor Brawl refactor, a technique decision table, pitfalls, and a production checklist.

Numpad notation basics

Imagine a numeric keypad mapped to a joystick or D-pad, with the character facing right (player one default):

7 = up-back 8 = up 9 = up-forward
4 = back 5 = neutral 6 = forward
1 = down-back 2 = down 3 = down-forward

A motion is written as a digit string, often followed by a button. Example: 236P means down (2), down-forward (3), forward (6), then punch. When the character faces left, “forward” in notation still means toward the opponent — implementations mirror hardware input or transform by facing; document which you use.

5 is neutral: no direction held. Tap motions like 6P (forward + punch) are throws or command normals in many games. [4] or (4) in wiki notation sometimes means “hold back” for charge moves (see below).

Button labels

Capcom-style six-button layout:

LP / MP / HP — light, medium, heavy punch
LK / MK / HK — light, medium, heavy kick

SNK four-button games often use A B C D or LP LK HP HK. Anime fighters may use A B C D with different strength tiers. In notation, P or K alone means “any punch” or “any kick”; PP can mean two punches or a specific super input. Always define your shorthand in the movelist.

Common motion families

Quarter circle forward (QCF) — 236

The fireball motion: down, down-forward, forward + button. Used for projectiles, some dashes, and rekka-style specials. Lenient readers often accept 2356 or treat 2 and 3 as satisfied by a single down-forward diagonal held for one frame.

Quarter circle back (QCB) — 214

down, down-back, back + button. Common for reverse charges, certain sweeps, and cross-up tools. Mirror leniency rules from QCF.

Dragon punch (DP) — 623

forward, down, down-forward + button — the invincible anti-air arc. Historically strict: missing the cardinal 2 frame causes accidental QCF. Modern games often allow 63214 shortcuts or count 3 as fulfilling both down and down-forward requirements within a short window.

Half circle (HC) — 41236 or 63214

Back to down to forward (or the reverse) for throws, command grabs, or mid-tier supers. Longer sequences need wider input buffers (often 15–20 frames per step).

Full circle — 360

Complete rotation. Competitive implementations use shortcut 360 rules: four cardinals within a window without requiring clean diagonals, or accept 6248-style zig-zags. Document whether up counts as part of the circle or is optional.

Charge moves — [6]8 or [4]6

Hold back (or down-back) for a duration (often 40–60 frames), then press forward (or up-forward) + button. Notation: [4]6P = hold back, then forward + punch. Charge characters need visible charge timers in training mode. Buffer the release: holding forward early while still charged should still fire on the first legal frame.

Double quarter / double tap

236236P = two QCFs for supers; 22P = down-down + punch for some invincible reversals. Repeat segments share one motion buffer; define whether partial overlap counts.

Leniency, SOCD, and reader design

Notation describes intent; the command reader decides what actually registers. Key policies:

Motion buffer — how many frames each directional step stays valid (typical 8–15 for specials, longer for supers).
Diagonal forgiveness — whether 3 satisfies 2 then 6, or 1 satisfies 2 then 4.
Negative edge — special fires on button release instead of press; rare today but document if used.
SOCD cleaning (simultaneous opposite cardinal directions) — left+right or up+down on keyboard/stickless: last-win, neutral, or prefer forward for charge characters. Arcade standards differ; pick one and test on hitbox controllers.
Priority when multiple motions match — longer motions usually win over shorter subsets (DP vs QCF when both end in 3).
Button buffer — punch pressed during the last directional frame should still link; pairs with input buffering.

A practical reader keeps a ring buffer of recent directions (normalized to numpad digits), scans registered move definitions each frame, and marks the highest-priority match. Store definitions as digit strings in data, not hard-coded if-chains — Harbor Brawl's refactor moved 140 specials to JSON so designers could diff notation changes in version control.

Harbor Brawl refactor (worked example)

Harbor Brawl is a 2.5D roster fighter with six-button layout and rollback netcode. Pre-refactor pain points:

Three programmers, three DP implementations — beta fireball vs DP collision on the same 623 prefix.
Keyboard hitbox players hit SOCD neutrals; charge back lost during blockstun.
Training mode showed animations but not the digit buffer, so players could not see why a motion failed.

The refactor shipped:

Unified notation doc — every move listed as numpad + button with frame startup from frame sheets.
Shared CommandReader — 12-frame per-step buffer, DP shortcut 63214, QCF diagonal merge, supers require full 236236 with no skipped cardinals.
SOCD = last input wins on keyboard; stick uses hardware resolution.
Training overlay — rolling 20-frame digit strip + green/red match indicator.
Deterministic replay tests — recorded input streams assert expected moves for regression.

Special success on 236P, 214K, and 623P rose from 34% to 75% in beta telemetry; tournament players reported movelists finally matched fighting game wiki conventions.

Technique decision table

Approach	Best for	Tradeoff
Numpad motion commands	Traditional fighters, anime fighters, skill expression	Steep learning curve; reader bugs feel like betrayal
Single-button specials (cooldown)	Accessibility-first brawlers, mobile	Less execution skill; harder to balance depth
Context-sensitive actions (direction + attack)	Character action, platform fighters	Hard to document; ambiguous with fightsticks
Icon / timing rhythm inputs	Party fighters, narrative action	Poor fit for frame-precise PvP
Charge-only specials	Defensive archetypes, zoning	Needs charge UI; awkward on rushdown matchups

If your game advertises traditional fighting game depth, adopt numpad notation internally even if the UI shows icons — players will wiki-translate anyway.

Pitfalls

Inconsistent diagonal policy — DP works but QCF fails on the same stick hardware; fix globally.
Forward-relative vs screen-relative — cross-up after switching sides breaks motions if you cache screen digits.
Shorter motion steals input — QCF eating DP when 623 should win; define priority explicitly.
No training feedback — players blame netcode when notation mismatch is local.
Keyboard without SOCD — charge characters become unplayable on WASD hitboxes.
Different leniency online vs offline — rollback must simulate identical reader state per frame.
Movelist uses different names than code — “Shoryuken” in UI but qcf_p in repo; use one notation source of truth.
Over-leniency — accidental supers from scrubbed inputs; cap buffer length per move tier.

Production checklist

Adopt numpad 1–9 notation in design docs and movelists.
Define button labels (LP/MP/HP/LK/MK/HK or project-specific).
List every special as digit string + button in data-driven tables.
Implement ring-buffer command reader with per-move priority.
Set motion buffer frames per move class (normal, special, super).
Document diagonal forgiveness and DP shortcuts explicitly.
Choose and test SOCD policy on keyboard and hitbox.
Mirror facing correctly for player two and cross-ups.
Pair button buffer with directional buffer on the last step.
Ship training-mode input display (digit history + match highlight).
Add replay unit tests for canonical and lenient motion paths.
Sync reader behavior with rollback simulation layer.
Publish frame data and notation on the same reference page.

Key takeaways

Numpad notation maps joystick directions to digits 1–9, with 5 neutral and 6 forward toward the opponent.
Common motions include QCF (236), QCB (214), DP (623), half circle, 360, and charge [4]6.
Players experience notation through leniency rules, SOCD cleaning, and motion priority — not just the digit string.
Harbor Brawl fixed inconsistent specials by unifying the command reader and exposing digit buffers in training mode.
Data-driven motion tables plus replay tests keep notation, code, and movelists aligned across patches.