Bug Reporting for Fighting Games with Frame Data Issues

Fighting games are decided in individual frames, and their players are the most frame-aware audience in gaming. A move that has one frame more recovery than its data says, a hitbox that does not match its animation, a cancel that should be possible but is not, these are not minor glitches to a fighting game community, they are violations of the competitive integrity the whole genre is built on. Reporting these bugs requires capturing context at frame precision, because that should have hit is a claim you can only verify with the frame data behind it.

Why frame precision matters

In most games, a discrepancy of a single frame is imperceptible. In a fighting game it is the difference between a combo working and dropping, a punish landing or whiffing, a move being safe or punishable. Competitive players internalize frame data deeply, and they will notice and report when a move behaves even one frame differently from its documented data.

This sensitivity means fighting game bug reports operate at a level of precision no other genre demands. A player reporting that a move is unsafe when it should be safe is making a frame-data claim, and to verify it you need to see the actual startup, active, and recovery frames the game produced, not just a description of the outcome. Frame-precise capture is the foundation of fighting game QA.

Capture the move and exact frame

When a player reports a move behaving wrong, capture which move was active, which frame it was on, and the resulting frame advantage or disadvantage. This is the core data of any fighting game bug: a move whose actual frame data differs from its intended data is a clear, verifiable bug, and capturing the actual frames lets you confirm and measure the discrepancy.

Capture the state of both characters at the moment in question: their positions, their current actions, and their frame counters. A bug where a move is plus on block in one situation and minus in another depends on spacing and timing, and capturing both characters frame state reveals the conditional that produces the discrepancy, which a verbal report never could.

Capture hitbox and hurtbox state

Many fighting game bugs are hitbox and hurtbox mismatches: a hitbox that extends beyond the animation, a hurtbox that lingers after a move should be safe, a projectile whose collision does not match its sprite. These are visual-versus-logical discrepancies, and capturing the actual box geometry alongside a screenshot makes them concrete.

A report that a move hit when it looked like it should have missed is a hitbox complaint, and the box data settles it. Capture the active hitboxes and hurtboxes and their positions when a hit or whiff is disputed, so you can see whether the boxes matched the visuals or whether a box was wrong. This is the kind of bug that competitive communities obsess over, and the box data is the only way to adjudicate it definitively.

Capture the input history

A huge share of fighting game bug reports are really about inputs: a combo that dropped, a move that did not come out, a cancel that failed. Often the input was not what the player thought, a motion was sloppy, a button was a frame early, the buffer window was missed. Capturing the recent input history with frame timestamps reveals what actually happened versus what the player intended.

The input log resolves the most common dispute in fighting game QA: is it a bug or a player error. When the input history shows a clean, correct input that should have produced the move, you have a genuine bug in your input handling or cancel system. When it shows a flawed input, you can explain it and, if the window is too strict, consider whether your buffering needs tuning. Either way, the input log turns an argument into evidence.

Setting it up with Bugnet

Add an in-game report option, ideally accessible from training mode where players test frame data, and attach the active move, frame, both characters frame state, hitbox and hurtbox geometry, and recent input history as custom fields with a screenshot. Bugnet stores this frame-precise context so a frame-data bug arrives with everything needed to verify and measure it.

Group identical reports into occurrence counts, because when a competitive community finds a frame-data bug, many players report the same thing, and the cluster confirms it is real and important. With the frame context attached, you can verify the discrepancy, fix the data or the logic, and confirm the fix produces the intended frames, which is exactly the rigor a competitive fighting game audience expects.

Make training mode your QA partner

Training mode is where your most dedicated players investigate frame data, and it is also your best QA tool. A robust training mode that displays frame data, hitboxes, and input history lets players themselves localize bugs to a specific move and frame before they even report, producing extraordinarily precise reports. Lean into that by making it easy to file a report directly from training mode.

Combine player-driven training-mode investigation with your own frame-data test suite. Automated tests that execute each move and assert its startup, active, and recovery frames catch frame-data regressions instantly, and player reports catch the conditional edge cases your tests did not anticipate. Together they keep your frame data trustworthy, which in a competitive fighting game is not a nicety but the core promise to your players that the game is fair and consistent.

Fighting games are decided in single frames. Capture the frame, the boxes, and the inputs.