Bug Reporting for Games With Block and Counter Systems

Block and counter systems ask the player to act inside a window measured in single frames, then ask them to describe what went wrong in plain language. The result is a bug queue full of my counter did not come out and the block broke when it should not have, each one true and each one impossible to act on as written. These mechanics are pure timing and state, so the only way to make their bugs tractable is to record the timing and state. This post covers what actually breaks in block and counter systems and what to capture so a frustrated report becomes a frame-accurate repro.

What players mean by the block broke

When a player says their block broke, they are reporting an outcome without any of the state that produced it. Did the guard meter empty and force a guard break? Did the attack have a guard-crush property the player did not know about? Was the block input registered at all, or did it arrive a frame after the hit became active? Was the player in a block state or still in block-startup when the attack connected? Each of these is a separate bug or a separate intended behavior, and the player has no way to tell them apart from inside the moment.

This ambiguity is why block bugs sit in the cannot reproduce pile so often. You stand in front of the same attack, block it, and it holds, because you are not replicating the guard meter level, the exact frame of the block input, or the attack property that mattered. The report described a real failure, but the conditions that caused it were invisible. Until the report carries the guard state and the relevant timing, you and the player are describing two different events that happen to share three words of description.

The parry window is a frame range, so log it as one

A counter or parry is defined by a window: a first active frame and a last active frame during which a correctly timed input converts a block into a counter. Almost every failed counter report is really a question about that window. Did the input land before it opened, after it closed, or inside it without the right state? You cannot answer that without recording the open and close frames of the window for the move in question and the frame the input actually arrived. Two numbers and an input timestamp resolve the overwhelming majority of these reports on sight.

It helps to log the window relative to the incoming attack, not just absolute frames. A parry window is meaningful as it is N frames before impact, and the bug is usually that the player was a frame or two outside that relative window. Capturing both the attack impact frame and the parry input frame lets you compute the miss distance directly. A report that shows the input landed three frames before the window opened is not a bug in your counter code, it is feedback that your window may be too tight, which is a different and equally actionable finding.

State transitions that swallow inputs

The subtle block and counter bugs hide in transitions. An input that should have triggered a counter can be eaten because the character was still in hitstun, in a block-recovery state, or mid-transition between guard high and guard low. The player pressed the button at what felt like the right time, but the state machine was not in a state that accepts the counter input on that frame. These never reproduce by hand because you cannot reliably reproduce the exact transition overlap, and they are some of the most infuriating bugs for skilled players who know their timing was right.

To catch them, log the guard state and any active transition on the frame the counter input arrived, alongside the input itself. The pattern that emerges is usually a specific state, such as guard_recovery, that silently rejects counter inputs when players expect it to buffer them. Once you see twenty reports all carrying the same rejecting state, you have found a systemic input-eating bug rather than twenty separate complaints, and the fix is often a small buffering change rather than a rework of the timing.

Designing the block and counter report payload

Settle on a defensive-state snapshot that rides along with every block or counter report. Include the guard state, the guard meter level, the parry window open and close frames for the active threat, the frame the defensive input arrived, the frame of impact, and the property of the incoming attack such as guard-crush or unblockable. With those fields you can classify almost any report instantly: guard meter empty is a resource issue, input outside window is a timing issue, input inside window but wrong state is a transition issue.

Make the snapshot automatic rather than asking the player to recall any of it. The player should only have to say the block broke, and the frame-level truth should arrive with the report. Consistency matters here as much as completeness, because once every report uses the same fields you can aggregate them. Counting how many failed-parry reports landed just outside the window tells you whether your parry timing is too strict for the input latency real players are running, which is design feedback you would otherwise never see.

Setting it up with Bugnet

Bugnet captures the defensive game state automatically when a player taps the in-game report button, so the guard state, parry window, meter level, and impact frame arrive as custom fields with zero upload plumbing on your side. The player flags a moment that felt wrong and you receive the exact frame data a fighting engine would otherwise force you to instrument by hand. Device and platform context come along for free, which matters because input latency on a wireless controller or a particular console can shift a parry by the frame or two that decides whether it registers.

Block and counter complaints cluster heavily, and occurrence grouping turns that to your advantage. Bugnet folds duplicate reports into one issue with a count, so all the my counter did not register reports become a single prioritized issue you can sort by your guard_state custom field. Filtering by state separates true input-eating transition bugs from honest timing misses, and the occurrence count shows which window is actually too tight for your real player base rather than which one a single vocal player happens to dislike.

Turning fixes into timing regression tests

Once a block or counter bug carries its full state, you can build a frame-stepping test that replays the input against the move and asserts on the window: given this attack, a counter input on frames X through Y must convert, and inputs outside must not. Each fixed bug becomes a permanent assertion, so retuning one move cannot silently break the parry timing of another. For a small team, this is the difference between a defensive system that stays consistent and one that quietly drifts every patch.

Keep capturing state in the field even after the test passes, because real input latency varies in ways your local setup cannot fully cover. Watching where live parry inputs land relative to the window tells you whether the test assumptions still hold across the controllers and platforms your players actually use. Block and counter play is where skilled players form their opinion of your combat, so treating its bugs as measurable timing rather than disputed feel is what keeps that opinion high as the game evolves.

Block and counter bugs are timing and state in disguise. Record the window and the guard state and a disputed failure becomes a measurable, testable fact.