Bug Reporting for Games With Parry and Block Timing

Parry and block timing is where a game feels either crisp and fair or cheap and broken, and the bugs are correspondingly raw. A player insists they parried in time and took a hit anyway. Another lands a parry that the game seems to reward inconsistently. These disputes are about a handful of frames: the parry window, the attack's active frames, and the frame the input actually registered, all filtered through input and display latency. Players cannot measure frames, and you cannot reproduce a frame-perfect parry by feel. The only way to settle it is to capture the timing data around the parry attempt. This post covers exactly which frames to record and why latency complicates everything.

Parries are won and lost in a few frames

A parry succeeds when the defensive input is active during a specific window relative to an incoming attack, often just a few frames wide. Block works similarly but with a wider or always-on window and different reward. The whole system is a frame-level overlap test: was the parry window open during the attack's active frames. Because the window is so narrow, the difference between a clean parry and a hit can be a single frame, which is roughly sixteen milliseconds and entirely beneath human perception. Players experience the outcome as fair or unfair, but the cause is a precise frame relationship they cannot see.

This is why parry complaints are so contentious and so hard to act on without data. A player who took a hit after a parry attempt genuinely believes they were on time, and from their seat they were. But their input may have registered two frames late due to latency, or the attack's active frames may differ from what the animation suggested, or the window may have been defined incorrectly. Each of these is a real, fixable bug, but they are indistinguishable from the player's chair and from a video. Frame-level capture is the only thing that tells them apart.

Capture the input frame and the windows

Record the exact simulation frame on which the parry or block input was registered, and the frames during which the parry window was open. Then record the incoming attack: which attack it was and its active frames, the window during which it can connect. With these three pieces you can directly see whether the input frame fell inside the parry window and whether that window overlapped the attack's active frames. If the input was one frame too late, you will see it immediately. This frame-level alignment is the entire diagnosis, and it is impossible without capturing the frames themselves.

Capture the state of the defensive action too. Was the player already in block and transitioning to parry, which some systems disallow. Was there a recovery period from a previous action that ate the input. Was the parry on cooldown. Many parry bugs are not about the window at all but about a state that prevented the parry from being attempted in the first place, while the animation still played and led the player to believe it should have worked. Recording the defensive state machine alongside the timing separates a window bug from a state bug, which are fixed in different places.

Latency is the hidden variable

Input latency turns a deterministic frame test into a moving target. The player presses the button, but the input travels through the controller, the operating system, and your input polling before it reaches the simulation, and several frames can pass. On top of that, display latency means the player reacts to a frame that is already old. So a player can press at the perceptually correct moment and have the input register late through no fault of theirs or yours. Capturing the input latency, or at least the path from physical press to processed frame, is essential to understanding parry disputes honestly.

Because latency varies by hardware, display, and even wireless versus wired controllers, the same parry timing succeeds on one setup and fails on another. This is why you must capture device and platform context with parry reports, and ideally a latency measurement. A parry that drops only on certain configurations points at a latency budget that is too tight, which you might address with a slightly more generous window or input prediction. Without latency data you will chase a window bug that does not exist, when the real issue is that your timing assumes latency you cannot guarantee across the hardware your players actually use.

Make timing deterministic and replayable

Run your combat simulation on a fixed time step so a parry window is always the same number of frames regardless of rendering frame rate. If combat advances at a variable rate, a window defined as three frames means different real durations on different machines, and parry timing becomes inconsistent in ways that look like bugs. With a fixed step, the captured input frame and window frames have stable meaning, and you can replay them. Build an input playback tool that injects the recorded input at the recorded frame against the recorded attack, so you watch the parry resolve exactly as it did for the player.

Once you can replay, parry debugging becomes precise. Step frame by frame through the overlap of the parry window and the attack's active frames and the conclusion is unambiguous: the input was in the window and should have parried, so the bug is in the resolution logic; or the input was a frame late, so the bug is in latency or the window width. Save each fixed case as a regression test that injects the input at the captured frame and asserts the parry outcome. Your suite then guarantees that the frame relationships you tuned stay correct as you add new attacks and adjust windows.

Setting it up with Bugnet

Bugnet's in-game report button captures device and platform context automatically, which is exactly the data parry bugs need, since input and display latency depend on hardware. You add custom fields for the frame the input registered, the parry and block window frames, the incoming attack and its active frames, the defensive state, and any measured input latency. Because the button snapshots state when the player reports an unfair hit, you get the real frame alignment of that specific parry attempt, not a heated description of what should have happened. That snapshot ends the dispute and points straight at the cause.

Occurrence grouping shows which parry problems are real and widespread. If many players take hits after on-time parries against one particular attack, Bugnet folds those reports into one issue with a count, revealing an attack whose active frames are mistuned or a window that is too tight for real-world latency. Filter by platform to catch latency-sensitive failures, filter by the attack using a custom field, and keep every frame snapshot in one dashboard. The most subjective category of combat complaints becomes objective frame data you can confirm, prioritize, and fix between patches.

Tune fairness and prove it

Parry and block timing is a fairness contract with the player, and breaking it quietly erodes trust faster than almost any other bug. Use the captured frame data to tune windows against real latency, not against your wired controller on your monitor. Consider a small input buffer or slightly wider windows to absorb the latency variance across the hardware your players actually own, and verify the change against the captured timelines that previously failed. Every parry you fix should leave a regression test that replays the input at the captured frame and asserts the correct outcome.

Treat the parry system as a deterministic, frame-level machine whose outcome is a function of input frame, window, attack frames, and latency, all of which you can capture and replay. Once reports carry that frame data, you build input playback, and you grow a timing test suite, the bitter I parried that and still got hit arguments become objective, solvable bugs. Players feel a combat system that is honest about its windows, you feel confident adjusting them, and the fairness contract holds across every patch and every piece of hardware your game runs on.

Parries are won in a few frames. Capture the input frame, the windows, the attack frames, and latency and the unfair-hit dispute becomes objective frame data.