Guide

Game option select combat systems explained

Harbor Brawl's mixup character — codename “Latch” — dominated low-tier casual lobbies with a single sequence: jump forward, press throw on landing. Defenders who crouch-block ate the throw. Defenders who tried to anti-air ate a low-profile crossup. Defenders who jumped got hit by an invincible reversal on the way up. The community called it broken until replay review showed each branch was a deliberate option select (OS): one timed input that resolves differently depending on opponent state, spacing, and frame alignment. Randomness was not the engine — undocumented coverage was.

An option select is not a cheat code. It is a design pattern where a single player action covers multiple defensive responses because the game resolves priority, proximity, and state checks in a predictable order. OS routes power high-level high/low mixups, safe jumps, and throw loops — but they only feel fair when designers publish the coverage map, tune spacing so each branch is punishable on a read, and avoid accidental OS from sloppy input priority. This guide covers OS taxonomy, jump and throw OS, reversal and meaty OS, conditioning loops, the Harbor Brawl refactor, a technique decision table, pitfalls, and a production checklist.

What an option select is (and is not)

Formally, an option select is one offensive sequence that produces different optimal outcomes against different defensive choices, without the attacker needing to react mid-sequence. The attacker commits once; the game's resolution rules pick the winning branch.

This differs from:

Reacting mixups — attacker chooses high or low after seeing defense; requires frame-perfect reads.
Gimmicks — one-time bugs or unclear priority that players cannot reproduce in training mode.
Yomi (mind games) — psychological layer on top of OS; the OS is the mechanical substrate.

Good OS design makes mixups readable in hindsight: replays show which branch fired and why. Bad OS design hides branches behind ambiguous VFX or input priority spaghetti. Pair OS documentation with frame data so players know when each branch is plus, minus, or punishable.

Jump option selects

Jump OS is the most common family. The attacker jumps toward the opponent and inputs a secondary action on landing or during jump arc. Resolution depends on defender position and state:

Throw OS on landing

Jump-in that becomes throw if the defender is standing or crouch-blocking within throw range on landing, but becomes a normal or special if they are airborne or outside throw range. Beats crouch block (throws ignore block) and catches delayed anti-air startup. Loses to jump escape, backdash out of range, or throw tech if the defender expects it.

Safe jump OS

Timed jump attack that is plus on block if the defender blocks, but beats reversal invincibility if they mash DP on wake-up — because the jump attack lands after invincibility ends but before their reversal active frames. Requires precise meaty timing documentation per knockdown type.

Crossup OS

Jump arc that can cross up or stay same-side depending on whether the defender walks forward, back, or stands still. The attacker does not choose side at jump start; spacing at jump apex selects the branch. Works with crossup facing rules and empty-jump conditioning.

Designers should log jump OS branches in movelist metadata: OS_THROW_LAND, OS_SAFE_JUMP, OS_CROSSUP with required spacing bands in body-widths.

Throw, shimmy, and strike OS

Ground-based OS covers defensive layers without leaving the floor:

Strike/throw OS — forward walk plus delayed throw input: if in throw range, throw; if opponent backdashes, whiff into forward medium that catches the escape. Central to shimmy pressure.
High/low OS — one input sequence that is overhead if opponent crouches (e.g., delayed hop kick) but mid if they stand (normal hits crouch). Distinct from true 50/50 if coverage is spacing-dependent.
Frame trap OS — stagger string where the next input is special on hit confirm but frame trap on block mash; see blockstring pressure.
Tick throw OS — plus-on-block jab into immediate throw attempt; beats mashing jab, loses to throw tech or jump.

Throw OS requires explicit throw proximity windows and tech input priority. If strike startup wins over throw when both are in range, your OS collapses into accidental whiffs. Publish resolution order in combat docs: throw check before strike or the reverse — never leave it implicit.

Reversal and meaty option selects

Defensive OS also exists — one input that covers multiple offensive patterns on wake-up:

Reversal OS

Back-rise input that is invincible reversal if the opponent meaties or throws, but safe back-roll if they empty jumps or delays pressure. Common in games with hold-back and down-back on the same frame for wake-up options.

Delay tech OS

Delayed throw tech that beats tick throw OS but loses to frame trap stagger into combo. Teaches attackers to respect delayed defense without making throws free.

Auto-block OS (guard system games)

In titles with dedicated guard buttons, one guard input can auto-select high, mid, or low block based on incoming attack height — designer choice whether this is skill expression or OS to limit; document explicitly.

Reversal OS must respect throw immunity frames on wake-up and avoid invincibility that covers every branch without meter cost.

Spacing, conditioning, and the coverage map

OS without conditioning is a slot machine. The loop is:

Establish threat — show the branches that hurt (throw damage, safe jump combo, low confirm).
Force a habit — repeat until defender defaults to one answer (always crouch block, always tech throw, always reversal).
OS into the habit — same input sequence punishes the conditioned response.
Reset — when defender adapts, return to honest mixups.

Build a coverage map per OS route: rows are defender actions, columns are OS branches, cells mark win/lose/trade. Example for Latch jump throw OS at mid spacing: crouch block loses to throw, stand block loses to low, jump loses to anti-air, backdash escapes, throw tech trades. Empty cells mean untested branches — fill them before shipping.

Spacing bands matter as much as inputs. An OS that works at throw range but whiffs at max footsie range is a different tool than the same input at close range. Tag OS entries with min/max distance in combat data.

Implementation: priority stack and training mode

Engine-side, OS resolves through ordered checks each frame:

Proximity and facing (throw range, crossup side).
Defender state (blocking, airborne, hitstun, wake-up).
Attacker move phase (jump arc, landing, recovery cancel window).
Input buffer contents (throw vs strike priority).

Log which check selected the branch in replay metadata (os_branch=THROW_LAND). Training mode should offer:

OS drill: cycle defender responses, show which branch won.
Coverage overlay: color-code win/lose cells at current spacing.
Frame display on meaty OS and safe jump windows.

Rollback netcode must simulate the same priority stack; desync on throw vs strike resolution is a common OS bug. Test with input buffer lengths identical on client and server.

Harbor Brawl mixup refactor

Harbor Brawl's Latch OS pass turned accidental coverage into teachable systems:

OS registry — every intentional OS tagged in movelist; accidental priority collisions removed or promoted to registry.
Coverage maps published — in-game glossary shows jump throw OS win/lose table at three spacing bands.
Punish windows on each branch — throw OS throw branch minus on whiff tech; low branch punishable by 4f jab on block.
Throw tech buffer unified — 3f tech window on wake-up and tick OS; delay tech OS documented separately.
Replay OS tags — spectator UI labels branch name on connect for esports clarity.
Bot training scenarios — defender bot cycles responses; attacker grades OS success rate.

Latch win rate in Platinum dropped 6% while player satisfaction with “I know why I lost” rose 41% — fewer free OS wins, more readable conditioning wars.

Technique decision table

Your situation	Prefer	Avoid
Throw-heavy character	Jump throw OS with published spacing bands	Infinite throw range on ambiguous jump
Safe jump knockdown game	Meaty OS with per-knockdown frame chart	One global meaty timing for all knockdowns
Teaching intermediate players	Coverage map in training mode	Hidden input priority without docs
Defensive OS on wake-up	Meter or readable telegraph on best branch	Free invincible covering throw and jump
Rollback fighter	Deterministic throw-vs-strike priority stack	Client-only OS resolution
OS feels unbeatable	Add escape branch and punishable whiff state	Nerf damage without fixing coverage holes

Common pitfalls

Accidental OS from priority bugs. Players discover unintended coverage; either document or fix — do not leave ambiguous.
OS with no escape. Every defender response loses; add backdash, jump, or tech branch.
Spacing-independent throw OS. Works at all ranges; neutral becomes jump throw only.
Same VFX on all branches. Replays cannot teach which OS fired.
Ignoring wake-up throw immunity. Tick OS beats everything on knockdown unfairly.
Buffer length mismatch online. OS works in training, desyncs in ranked.
Overloading one character with OS. Spread coverage tools across roster archetypes.

Production checklist

Tag intentional OS routes in movelist metadata with branch names.
Build coverage map: defender action vs OS branch win/lose/trade.
Document spacing min/max per OS in body-widths or throw units.
Publish throw-vs-strike input priority order in combat docs.
Ensure each OS branch has punish window on wrong read or whiff.
Ship training drill that cycles defender responses and grades OS.
Log os_branch in replay for spectator and QA review.
Test safe jump and meaty OS per knockdown type separately.
Verify rollback determinism on OS priority stack.
Remove or promote accidental OS from priority collisions.
Playtest conditioning loop: threat, habit, punish, reset.
Update in-game glossary when OS spacing or branches change.

Key takeaways

Option selects cover multiple defensive answers with one committed input — resolution comes from spacing, state, and priority rules, not luck.
Jump throw OS, safe jump OS, and strike/throw shimmy OS are the core families — each needs spacing bands and punish windows on every branch.
Coverage maps and training drills make OS teachable; hidden priority stacks feel like bugs even when they are technically consistent.
Conditioning loops (threat, habit, punish, reset) turn OS from slot machines into readable mixup games.
Harbor Brawl cut Latch's cheap OS wins 6% by publishing coverage tables, tagging branches, and punishing whiffed throw OS on tech.