Why does a hit land on my screen but miss on my opponent's?

Online play splits the interaction across two clients with latency, and the netcode reconciles their inputs into one reality. When it slips, the attacker and defender see different outcomes. The bug lives in the divergence between clients, so capture each client's netcode state and a shared match ID to reconstruct what each side actually saw.

How do I resolve a disputed hitbox bug?

Capture the active hitboxes and hurtboxes and the character positions on the exact frame of the disputed hit. A visual of the box geometry at that moment usually settles it instantly, showing whether the boxes overlapped. Frame-level collision data turns a that should have hit argument into a concrete question you can answer from the report.

What makes rollback netcode bugs so hard to track?

Rollback predicts the opponent's inputs and rewinds to correct mispredictions, so a state that does not restore cleanly or a prediction that desyncs the simulation produces artifacts that look like cheating but are reconciliation faults. You need the netcode state, input delay, rollback frames, and predicted versus confirmed inputs, to tell a real desync from normal correction.

Bug Tracking for Arena Brawlers

Quick answer: Arena brawlers are decided in frames: netcode that must reconcile inputs across latency, hitboxes and hurtboxes that have to agree on every client, and knockback physics that propagate from each hit. A few frames of desync or a wrong collision reads as cheating and breaks competitive trust. Track these by capturing the input history, the frame and positions at the hit, the netcode state, and a shared match ID so you can reconstruct what each client saw.

Arena brawlers are unforgiving about frames. A match is decided by hits that land or whiff on the order of sixteen milliseconds, knockback that sends a player into a wall or just past it, and netcode that has to make two players on two connections agree about all of it in real time. When something goes wrong, it is rarely a crash. It is a hit that connected on your screen and missed on theirs, a combo that dropped because a frame desynced, a knockback that launched the wrong way. Players experience these as unfairness or cheating, and in a competitive game that perception is fatal. This post is about tracking the netcode, hitbox, and physics bugs that decide whether your brawler feels fair.

The game is decided in frames

A brawler runs on a tight simulation where a few frames change everything. An attack has startup, active, and recovery frames; a hit connects only if the active hitbox overlaps the opponent's hurtbox on the right frame; a block, dodge, or counter is a window measured in single frames. This precision is what makes the genre competitive and what makes its bugs so consequential. A one-frame error in when a hitbox activates, a rounding difference in a position, a physics step that runs slightly off, all produce outcomes that feel wrong to players who are reading the game frame by frame and will notice instantly.

Because everything is frame-precise, the bugs are too, and they cannot be diagnosed without frame-level data. A player reporting that an attack should have hit is describing a specific frame where they believe a hitbox and hurtbox overlapped. To check that, you need the positions and active boxes on that exact frame, not a vague after-the-fact description. The genre demands that your bug tracking operate at the same resolution as the gameplay, capturing the frame, the inputs, and the collision state, because anything coarser throws away the very information the bug is made of.

Netcode turns one bug into two views

Online play splits every interaction across two clients with latency between them, and the netcode, whether rollback or delay-based, has to reconcile their inputs into a single agreed reality. When it works, both players see the same hit. When it slips, they see different games: a hit that connected for the attacker and whiffed for the defender, a rollback that snaps a character to a position that feels like teleporting, a combo that the netcode resolved differently on each side. The bug exists in the divergence between clients, and like other multiplayer issues it cannot be understood from one player's view alone.

Rollback netcode in particular creates its own class of bugs. To hide latency it predicts the opponent's inputs and rolls back to correct when predictions are wrong, and a bug in that rollback, a state that does not restore cleanly, a prediction that desyncs the simulation, produces visual artifacts and outcomes that look like cheating but are really a reconciliation fault. Diagnosing these requires the netcode state: each client's input delay, the rollback frames, the predicted versus confirmed inputs, and the connection quality. A report that just says it desynced is the start of the investigation, not the end.

Hitboxes, hurtboxes, and knockback

Collision is the heart of a brawler and a dense source of bugs. Every attack carries hitboxes that must align with the animation, every character carries hurtboxes that must match its silhouette, and a mismatch produces hits that land where nothing visible is or whiff where everything looks connected. These bugs are reported as the hitbox is wrong or that should have hit, and they are concrete and reproducible if you have the box geometry and positions on the frame in question. A visual of the boxes at the moment of the disputed hit usually settles the question instantly.

Knockback physics propagate from every hit and are a second tangle. The direction, distance, and trajectory of a launch depend on the hit, the move, the position, and the state, and edge cases abound: knockback into a corner that behaves wrong, a launch that sends a character through geometry, momentum that carries oddly across a stage boundary. Because knockback chains into combos and stage interactions, a small error compounds into a wildly wrong outcome. Capturing the hit, the resulting knockback vector, and the positions lets you reproduce the launch exactly and find whether the bug is in the collision, the physics, or the stage geometry.

Inputs and the resolution of the dispute

A huge share of brawler complaints are really about inputs. A move that did not come out, a dash that registered as a walk, a combo that dropped because a button press was eaten, all of these feel like the game ignoring the player. Sometimes the cause is a genuine input-buffering or interpretation bug, and sometimes it is the player mistiming a frame-tight window, but you cannot tell which without the actual input stream. The player's memory of what they pressed is unreliable at this resolution, because they are reconstructing a sequence that happened in fractions of a second.

This is why the recorded input history is the single most important thing to capture for a brawler. With the exact buttons and the frames they landed on, you can replay the sequence and see whether the move should have come out, settling whether it was a buffer bug or a missed window. Combine the input log with the frame-level positions and netcode state and almost every dispute becomes answerable from data rather than argument. In a competitive game where trust depends on the engine being fair, the ability to definitively reconstruct an input sequence is what lets you defend the cases you got right and fix the ones you got wrong.

Setting it up with Bugnet

Integrate the Bugnet SDK and the in-game report button captures the frame-level context a brawler needs: the recent input history, the frame and character positions at the disputed moment, the active hitboxes and hurtboxes, the netcode state including latency and rollback frames, and recent state, all attached automatically. Instead of a player insisting an attack should have hit, you get the exact frame and box geometry to confirm or deny it, turning a fairness argument into a concrete collision question you can answer from the data.

Set a shared match identifier as a custom field on every client so a disputed hit produces reports from both players that you can join and compare, reconstructing what each client saw and locating the netcode divergence. Occurrence grouping folds many players hitting the same desync or hitbox bug into one issue with a count, and filtering by latency or region exposes whether a netcode bug tracks connection quality. From one dashboard you can replay the captured frame and inputs, separate genuine collision bugs from netcode reconciliation faults, and protect the competitive trust your brawler depends on.

Test the frames and the connection

Testing a brawler means testing at frame resolution and under real network conditions, because that is where the bugs live. Build tools to step the simulation frame by frame and visualize hitboxes, hurtboxes, and knockback vectors, so collision disputes are resolved by looking rather than arguing. Verify frame data against your design, that every move's startup, active, and recovery frames are what they should be, and assert that hitboxes track their animations. The frame-level tooling you build for debugging doubles as the tooling that keeps your balance honest as the game evolves.

Then hammer the netcode under conditions that match real play, not a LAN. Inject latency, jitter, and packet loss, force rollback by predicting wrong inputs, and run cross-region matches to surface the desyncs that only appear off a perfect connection. Replay captured matches from the field to reproduce reported divergences deterministically. A team that tests at the frame level and under realistic latency, and that captures frame-precise reports from real matches, can keep the one promise a competitive brawler must keep: that the same hit looks the same to both players, every time it matters.

A brawler is decided in frames, and a hit must look the same to both players. Capture frame-level inputs and boxes plus a shared match ID, or fairness disputes stay unanswerable.