How do I prove whether a dropped input was the player or the game?

Capture the raw input history with per-frame timestamps, exactly what was pressed and released on each frame leading up to the move. With the frame-by-frame log you can see whether the motion completed inside the buffer window and whether the interpreter accepted it. That replaces a heated dispute with a precise finding, such as the input was held two frames too long, pointing at the parsing rule responsible.

What context does a hitbox or frame data bug report need?

At minimum the move involved and the exact frame the disputed interaction happened on, ideally with the hitbox and hurtbox state on that frame. Frame data bugs are meaningless without knowing which frame, since a move is active for specific frames. A report that an attack hit when the player should have been safe becomes actionable once you can see the hitbox was still active on a recovery frame.

How do I track a rollback netcode desync?

Capture the rollback context: the number of frames rolled back, the input delay, the ping, and a checksum of the game state. A desync, where the two clients diverge into different states, is the most serious rollback bug, and a state checksum that diverges pinpoints the frame where they split. The rollback frame count and network conditions let you separate an ordinary correction from a genuine netcode bug.

Bug Tracking for 1v1 Fighting Games

Quick answer: Fighting game bugs are frame-precise: dropped or misread inputs, hitboxes that do not match the animation, frame data that disagrees with the design, and rollback netcode desyncs. Track them by capturing the input history with frame timestamps, the move and frame the issue occurred on, and the rollback context, so you can reconstruct a dropped command or a desync to the exact frame.

Fighting games operate at a precision no other genre demands. A move is active for a specific frame, a combo links because one move recovers exactly in time for the next, and a match can turn on a single input read correctly or dropped. Players at every level develop an intuition for these frames, so when an input does not come out, a hitbox does not match what they see, or rollback rewrites a moment they thought they won, they feel it immediately. This post covers tracking the four pillars of fighting-game bugs: frame data, hitboxes, inputs, and rollback netcode.

Inputs: the dropped command problem

The most common and most infuriating fighting-game bug is the dropped input. The player executes a motion, a quarter-circle, a dragon-punch, a tight link, and the move does not come out. Sometimes the input was genuinely imprecise, but often the input buffer, the interpretation window, or the negative-edge handling misread a perfectly valid command. Because the player knows their execution, they blame the game, and at high level they are frequently right, because the margins are a few frames wide.

Track input bugs by capturing the raw input history with per-frame timestamps, exactly what was pressed and released on which frame, leading up to the move that should have come out. With the frame-by-frame input log you can see whether the motion was complete within the buffer window and whether the game interpreter accepted it. This turns a heated my dragon-punch did not come out into a precise the down-forward was held two frames too long for the buffer, which points straight at the input-parsing rule responsible.

Hitboxes, hurtboxes, and frame data

A fighting game is a negotiation between hitboxes and hurtboxes resolved every frame, and players expect what they see to match what hits. When a hitbox extends past the visible attack, or a hurtbox lingers after a move should have recovered, an attack connects or whiffs in a way that contradicts the animation, and players call it wrong. Frame data, the startup, active, and recovery frames of each move, is the contract; if the implementation disagrees with the intended frame data, the move behaves differently than players learned.

Track these by capturing the move involved and the exact frame the disputed interaction occurred on, along with the hitbox and hurtbox state on that frame if you can. A report that an attack hit me when I should have been safe becomes actionable when you can see that the hitbox was still active on a frame the move should have recovered. The move plus the frame is the minimum context, because frame data bugs are meaningless without knowing which frame, and a fighting game lives or dies on individual frames.

Combos, cancels, and timing windows

Combos are the expressive core of a fighting game, and they depend on precise cancel and link windows. A bug here can manifest as a combo that should connect dropping, a cancel that the game refuses, or worse, an unintended combo, an infinite or a link that was never supposed to exist. Both directions are problems: a missing cancel frustrates players who learned the combo, while an unintended infinite can break the competitive balance of the entire game until it is patched.

Track combo bugs by capturing the sequence of moves and the frame each was input relative to the previous one. A combo is a timing relationship, so you need the inter-move timing, not just the list of moves. With it you can see whether a cancel was attempted inside its valid window and whether the game allowed it, distinguishing a too-strict cancel window from a genuine execution error. For unintended combos, the same data lets you find the cancel or link that should not have been permitted and tighten the rule that allowed it.

Rollback netcode and desyncs

Modern fighting games rely on rollback netcode, which predicts the opponent inputs and rewinds to correct when a real input arrives that differs from the prediction. It is what makes online play feel close to offline, and it introduces a distinct class of bugs. A visible rollback that rewinds a hit the player thought landed, a desync where the two clients diverge into different game states, or a prediction that produces a jarring teleport all break the illusion that you are playing the person in front of you.

Track rollback bugs by capturing the rollback context: the number of frames rolled back, the input delay in effect, the ping, and ideally a checksum of the game state that can reveal a desync. A desync is the most serious rollback bug, because the two players are no longer in the same match, and a state checksum that diverges pinpoints the frame where they split. With the rollback frame count and the network conditions, you can tell an ordinary correction from a genuine netcode bug, and reproduce the conditions that caused it.

Setting it up with Bugnet

Bugnet fits fighting games because the in-game report button captures state automatically the moment a player hits a dropped input, a wrong hitbox, or a rollback desync, while the match context is still present. You can attach the frame-stamped input history, the move and frame of the issue, and the rollback context as custom fields. That turns the worst kind of report, an emotional my input did not come out, into something frame-precise, so you can verify against the buffer rule rather than dismissing a player who, at high level, is usually describing a real margin.

Because the same input-buffer quirk or hitbox error gets reported by many players who all hit the same frame-perfect situation, Bugnet folds duplicate reports into one issue with an occurrence count, so a genuine frame-data bug rises above isolated execution mistakes. You can filter by the move or by network conditions using your custom fields to isolate, for instance, every rollback desync above a certain ping. One dashboard with the frame and input data attached lets you fix bugs at the frame level, which is the only level a fighting game cares about.

Earning trust in a frame-perfect community

Fighting game communities are exacting and will scrutinize every frame, which makes them the best bug reporters you could ask for if you give them a way to report with precision. The studios that earn this community trust treat frame data as a published contract, instrument inputs so disputes carry frame-level data, and verify rollback under real network conditions. When players can point to a frame and you can confirm it, the relationship shifts from blame to collaboration.

Lock every fix in at the frame level. A confirmed dropped-input bug, captured with its frame-stamped history, becomes a test that replays the exact inputs and asserts the move comes out. A hitbox fix becomes a frame-by-frame check against the intended frame data. Build these into your release gate, let occurrence counts surface the bugs hurting the most matches, and verify rollback against simulated ping. A fighting game is won and lost on frames, and you keep players trust by tracking, fixing, and protecting it one frame at a time.

A fighting game is won and lost on frames. Capture the frame-stamped inputs and the exact move and frame, and a heated input dispute becomes a precise, checkable fact.