Guide

Game plink and input priority systems explained

Harbor Brawl's combo designer shipped a bread-and-butter string: jab links into medium on exactly one frame of advantage. Frame data was correct. Training mode displayed the green link window. Yet pad players landed the confirm only 12% of the time in live matches while keyboard hitbox players cleared 38%. The gap was not skill — it was input sampling. A controller button press and release can straddle two frames; without a priority rule, the medium input registered one frame late and the link broke. The engineering fix was not widening the link window (that would buff damage routes); it was adding a plink window that treats near-simultaneous attack inputs as intentionally linked.

Plinking (priority linking) and broader input priority systems decide which command wins when players press multiple buttons in the same frame or when hardware sampling blurs timing. They sit beside input buffering as the second pillar of fighting-game leniency: buffering forgives early inputs; plinking forgives simultaneous or overlapping ones. This guide covers plink windows, simultaneous button resolution tables, 1-frame link enablement, SOCD and diagonal cleaning, rollback netcode determinism, interaction with frame data and hit confirms, the Harbor Brawl combo refactor, a technique decision table, pitfalls, and a production checklist.

What plinking is and why it exists

In tournament Street Fighter culture, plinking originally meant drumming two buttons so the second press's rising edge lands on the exact frame needed for a link. Engine designers later formalized the technique as an optional system feature so pad players are not locked out of 1-frame routes that keyboard and arcade parts execute reliably.

Plinking addresses a hardware truth: consumer controllers poll at variable rates and digital buttons have mechanical bounce. A player intending one-frame spacing may produce:

Button A down on frame n, button B down on frame n (true simultaneous).
Button A down frame n, button B down frame n+1 (one frame late due to finger roll).
Button A down and up within frame n, button B down frame n+1 (release noise interpreted as gap).

Without priority rules, case two fails a 1-frame link even though the player's intent was correct. Plink systems collapse cases one and two into a successful link when buttons fall inside a defined priority window.

Plink windows vs input buffers

Designers often confuse plinking with buffering. They solve different timing errors:

System	Forgives	Typical window	Example
Input buffer	Early input before state allows action	3–10 frames pre-active	Special during jump landing
Plink / priority link	Simultaneous or near-simultaneous inputs	Same frame or ±1 frame overlap	Jab into medium 1-frame link
Negative edge	Release timing instead of press	Release frame counts as input	Charge back-then-forward on release
Reversal buffer	Early reversal during knockdown	Wake-up minus 1–3 frames	DP on wake-up

Use both: buffering helps special moves and cancels; plinking helps grounded links and tight chains. Stacking excessive leniency on both axes can trivialize combo routes that were meant to be character-specific strengths.

Simultaneous input priority tables

When two commands register the same frame, the engine needs a deterministic winner. Common policies:

Strength priority (most fighting games)

Heavy beats medium beats light; kick may beat punch at equal strength depending on game. Example table:

Simultaneous press	Resolved action
LP + MP	MP
MP + HP	HP
LP + LK	LK (kick priority) or LP (game-specific)
Attack + throw	Throw (Grappler titles) or attack (neutral tools)

Chronological priority (plink)

Within a plink window, the later button in the strength order wins even if both edges occur within one frame. This matches the player intent of “jab then confirm with medium” when both signals arrive in the same 16.67 ms slice.

Motion priority

When a motion input (QCF+P) and a normal attack register together, motion commands usually win because they require more stick data. Document this explicitly in your command reader spec so QA can regression-test overlaps.

Enabling 1-frame links without buffing frame data

A 1-frame link requires the next move's startup to begin exactly one frame after the previous move's hitstun ends. Human reaction cannot hit this reliably; muscle memory and plink leniency can. Design steps:

Publish true advantage — show link tier (e.g., “1F”) in movelist and training overlay.
Define plink window — typically same-frame only, or same-frame plus one frame of slack for pad.
Match strength order to route — if jab → medium is the route, medium must win plink over jab when both present.
Disable plink on unintended overlaps — jab + throw should not plink into throw unless that OS is designed (see option select systems).
Cap damage on tight links — use combo scaling so 1-frame routes reward execution without dominating damage.

Harbor Brawl added a 1-frame plink window for grounded normals only; air links kept strict timing to preserve aerial skill expression. Pad link success on the flagship jab → medium route rose from 12% to 47% without changing hitstun values.

SOCD, diagonals and controller cleaning

Plinking sits inside a broader input hygiene stack. Tournament fighters and PC ports often implement:

SOCD cleaning — simultaneous opposite directions (left + right) resolve to neutral or last-win depending on game rules; prevents charge characters from holding both charges.
Diagonal resolution — down-left + down may count as down for crouch-blocking while still allowing QCF motion reads from SOCD-neutral states.
Dash macro vs plink — double-tap forward for dash must not consume plink windows meant for links; separate tap thresholds.
Keyboard ghosting — matrix keyboards may drop simultaneous key presses; test 1-frame links on common hardware or document n-key rollover requirements.

Rollback netcode requires identical priority resolution on all peers. Serialize input processing: raw device input → cleaning → plink resolution → buffer consumption → state machine. Changing order between builds desyncs matches silently.

Harbor Brawl combo refactor (worked example)

Harbor Brawl's input stack before refactor:

8-frame global buffer for specials and jumps.
No plink; strict first-come-first-served per frame.
Strength priority only on literal same-frame presses.

Post-refactor pipeline:

Split leniency by context — 8-frame buffer for specials; 1-frame plink for grounded normals; 0-frame plink for air links.
Published priority table in combat design doc and training mode “input debugger” overlay.
SOCD neutral on keyboard; last-win on pad (configurable).
Telemetry — log failed links with per-button frame timestamps to distinguish bad spacing from system gaps.
AI lab bots trained with human-like ±1 frame jitter to validate plink windows before patch.

Result: overall combo completion rate up 19%; esports viewership on combo-heavy characters rose without patch-note damage buffs. Player surveys cited “my inputs registered” as the top feel improvement.

Technique decision table

Your goal	Prefer	Avoid
Pad-friendly 1-frame links	Grounded plink window + strength priority	Widening hitstun to fake leniency
Strict aerial skill ceiling	No air plink; keep buffer for landings only	Global plink on all states
Readable throw OS design	Explicit throw+attack plink rules per game	Accidental throw priority on plink
Rollback-safe multiplayer	Deterministic cleaning → plink → buffer order	Platform-specific priority branches
Motion + normal overlap	Motion wins when stick history satisfies threshold	Arbitrary coin-flip resolution
Accessibility without auto-combos	Configurable plink window in assists menu	Hidden engine-only leniency players cannot learn

Common pitfalls

Plink + buffer double leniency — 10-frame buffer and wide plink trivialize entire movelists.
Throw plink accidents — medium + throw plinking into throw frustrates offensive players.
Inconsistent pad vs keyboard — different priority without disclosure reads as platform imbalance.
Changing priority mid-season — esports players encode muscle memory; version priority tables.
Netcode order drift — cleaning after buffer on one build and before on another causes desyncs.
Hidden plink on reversals — unintentional 3-frame reversal plink breaks oki math.
No training feedback — players cannot diagnose plink vs spacing failures without input timestamps.
Macro overlap — dash macros eating link plinks when double-tap threshold is too loose.

Production checklist

Document strength priority and motion priority tables in the combat bible.
Define plink window per state (grounded, air, wake-up, blockstun cancel).
Implement input debugger overlay showing frame timestamps per button.
Test 1-frame links on top three pad and keyboard devices used in your community.
Verify SOCD and diagonal rules match advertised tournament settings.
Run rollback desync tests after any input pipeline reorder.
Telemetry: log failed links with advantage frame and input edges.
Separate dash, special, and link plink policies explicitly in code comments.
Balance tight links with combo scaling, not inflated hitstun.
Publish plink settings in patch notes when accessibility options change.

Key takeaways

Plinking resolves near-simultaneous attack inputs so 1-frame links work on pad without widening frame advantage.
Input buffers forgive early presses; plink windows forgive overlapping presses — use both deliberately, not maximally.
Strength priority, motion priority, and throw overlap rules must be deterministic and documented for fair multiplayer.
SOCD cleaning and diagonal resolution belong in the same pipeline as plink, before rollback serialization.
Harbor Brawl raised pad link success 35 points by adding grounded plink only — execution fairness without damage creep.