Bug Tracking for Precision Platformers

Precision platformers ask players to execute frame-perfect inputs and trust that the game will respond identically every single time. That contract makes the genre unusually sensitive to bugs that other games could shrug off. A few milliseconds of extra input latency, a collision that registers a hit a pixel early, or movement physics that behave differently at one hundred and forty-four frames per second than at sixty, any of these breaks the precision the whole experience depends on. Players will feel the wrongness even when they cannot name it. This post covers the bugs specific to the genre and the context needed to reproduce timing-sensitive failures.

Input latency and the feel of control

In a precision platformer, the delay between a button press and the on-screen response is part of the core feel, and players are remarkably sensitive to it. Bugs that add latency are subtle: an input polled once per rendered frame instead of per fixed update, a frame of buffering introduced by a UI layer, or vsync interacting badly with the input pipeline. The player does not see a broken animation, they just feel that the character is slightly behind their thumb, and they miss jumps they know they should make.

Because latency is felt rather than seen, the only way to debug it is to measure the input timeline. Capture the timestamps of input events relative to the frames and fixed updates that consumed them, along with the frame rate and whether vsync is on. A report that the controls feel laggy is unfalsifiable on its own, but an input timeline showing a press consumed two updates after it arrived is concrete. Recording the device and display configuration matters too, since latency can come from a specific controller or a high-refresh display the input code did not handle.

Collision detection at speed

Precision platformers move the player fast and demand pixel-accurate collision. Two failure modes dominate. Tunneling, where a fast-moving player passes through a thin platform or spike between frames because the collision check sampled positions on either side of it, and phantom collisions, where the player snags on a corner or registers a hit from a hitbox that extends a pixel beyond the sprite. Both are catastrophic in a genre where a single unfair death erodes trust, because the player knows their input was correct.

Debugging collision needs the player's velocity, position, and collision state at the moment of the report, plus the frame rate, since tunneling is frame-rate dependent. A player who died to a spike they clearly cleared is describing a phantom hitbox or a tunneling miss. Capturing the velocity tells you whether the speed exceeded what discrete collision sampling can handle, pointing at a need for swept collision. Capturing the exact position and the collider involved lets you set up the same approach in a test and watch the false hit or the pass-through happen frame by frame.

Movement physics across frame rates

The most insidious genre bug is movement that changes with frame rate. If physics are stepped per rendered frame rather than on a fixed timestep, jump heights, run speeds, and the precise window for tricks all shift between a player on a sixty hertz display and one on a high-refresh monitor. A jump that clears a gap at sixty fails at one hundred and forty-four, and a frame-perfect trick has a different window on each machine. This silently makes the game harder or easier depending on hardware, which is unacceptable in a precision genre.

These bugs require the frame rate and the timestep configuration to even detect. A player reporting that a jump is impossible needs their frame rate captured, because the bug may simply not exist at the frame rate the developer tested. Capturing the actual delta time the physics used, the target fixed timestep, and the display refresh rate reveals whether physics are properly decoupled from rendering. If two reports of the same failing jump carry different frame rates and different outcomes, you have proven a frame-rate-dependent physics bug without ever touching the player's machine.

Coyote time, buffering, and forgiveness windows

Good precision platformers add small forgiveness mechanics: coyote time that lets a player jump a few frames after leaving a ledge, and input buffering that registers a jump pressed slightly before landing. These windows are precisely tuned, and bugs in them feel deeply unfair because they break the implicit promise of fairness. A coyote window that is a frame too short eats jumps the player expected to land, and a buffer that does not clear correctly fires a jump the player did not intend on the next surface.

These bugs are entirely about timing, so the input timeline is again the key. Capture the frames between the triggering event, leaving a ledge or landing, and the input, measured against the configured window. A player reporting a stolen jump off a ledge is describing a coyote window that closed too early, and the frame count between the ledge-leave and the press proves it. Recording these windows in real player frames, rather than trusting the configured values, often reveals that the implementation drifts from the design under certain frame rates or input timings.

Setting it up with Bugnet

Bugnet's in-game report button captures game state automatically, and for a precision platformer the decisive captures are the input timeline and the frame timing. When a player reports an unfair death or a stolen jump, the report can carry the recent input events with timestamps, the frame rate and timestep, the player velocity and collision state, and the device and display. Instead of an unfalsifiable complaint that the controls feel off, you get the timing data that turns feel into a measurable discrepancy you can reproduce on a matched configuration.

Occurrence grouping and platform context together are what make frame-rate bugs visible. Grouping folds many reports of the same failing jump into one issue with a climbing count, and the captured frame rates and devices let you see the pattern: the same death clustering on high-refresh displays points straight at frame-dependent physics. Custom fields let you filter by frame rate or device, so a collision bug that only tunnels above a certain speed, or a physics bug that only bites at high refresh, surfaces as a clean cluster instead of a scatter of disputed deaths.

Testing the feel objectively

The most effective practice for the genre is to make timing measurable rather than subjective. Build automated tests that replay recorded input sequences against the physics at multiple fixed and rendered frame rates, asserting that jump heights, distances, and forgiveness windows are identical across all of them. This catches frame-rate-dependent physics and drifted coyote windows deterministically, before any player feels the unfairness, and it removes the it feels fine to me argument from the room entirely.

Pair that with a feedback loop from captured input timelines. When a player's report shows a tunneling death or a stolen jump, turn that input sequence and approach velocity into a fixed regression test so the same unfair moment can never ship again. Because precision matters so much here, treat every reproducible timing discrepancy as a real defect rather than player error, and verify fixes on the high-refresh hardware your players actually use. That objective, hardware-aware discipline is what keeps the tight, trustworthy feel the genre is judged on.

In precision platformers, feel is data. Capture the input timeline, frame rate, and velocity, and an unfalsifiable complaint becomes a reproducible defect.