Bug Reporting for Games With Parkour and Traversal

Parkour systems turn movement into a flowing chain of contextual moves: vault this, wallrun that, slide under, jump out, each feeding momentum into the next. Under the hood it is a state machine reading surfaces and conserving velocity through transitions. The bugs break the flow: a vault that did not trigger, a wallrun that dropped, momentum that vanished between moves, a transition that fired the wrong move. A player reporting that their flow broke is describing a state-machine transition or surface read that went wrong at speed. This post covers capturing the traversal state and momentum that makes these bugs reproducible.

Traversal is a state machine running at speed

A parkour system is a state machine where each state is a move, vaulting, wallrunning, sliding, mantling, and transitions are gated by surface reads and input timing. Because it runs at high speed, the windows are tight: a vault must trigger within a small range of approach, a wallrun must detect a wall while the player is moving fast and angled correctly. The bugs are missed transitions and wrong transitions. A vault that did not fire often means the surface read or the timing window missed by a hair; the wrong move firing means two transitions competed and the wrong one won.

Players experience these as the flow breaking, which in a parkour game is deeply felt because flow is the entire appeal. They cannot see the state machine deciding, or the surface probe missing, or the momentum being clamped. The current state, the recent transitions, and the surface reads are internal and they happen fast. Reproducing a flow bug means recreating the speed, the angle, the timing, and the surfaces, a combination players experience as a single fluid motion and cannot decompose for you.

Capturing the traversal state and transitions

Capture the current traversal state and, crucially, a short history of recent transitions with timestamps. Parkour bugs are almost always about the sequence: which move was active, what it transitioned from, and what it was trying to transition to when the flow broke. A dropped wallrun shows up as a transition out of wallrun that fired when the player did not expect it, and the history tells you what triggered it, a lost surface, a timing-out, or a competing input. A single state snapshot is not enough; the transition trace is the bug.

Capture the inputs alongside the transitions, because parkour transitions are input-and-context gated and the timing matters. A vault that did not trigger may show the jump input arrived a frame outside the window the system accepts while approaching that obstacle. Recording the inputs with timestamps against the state transitions lets you see the exact temporal relationship. When a player says the vault just did not happen, the trace shows whether the input missed the window, the surface was not detected, or the state machine was busy finishing a previous move.

Surface detection at speed

Traversal moves are gated by surface reads, and at speed those reads are easy to miss. Capture what the system detected: the surfaces in range, their normals and classifications (wallrunnable, vaultable, slidable), and the probe results that produced them. A wallrun that would not start usually shows the wall was not classified as wallrunnable from the angle the player approached, or the probe missed because the player was moving too fast for the detection cadence. The surface reads explain transitions that should have been available but were not.

Speed interacts badly with detection cadence. If surface probes run at a fixed rate, a fast player can pass an obstacle between probes and never get the read, so a vault that works at walking pace fails at a sprint. Capture the player's speed alongside the detection results so this class of bug is visible. A vault-fails-only-when-fast report is unreproducible until you see the speed and the missed probe together, at which point the fix, denser probing or speed-aware detection, is obvious rather than mysterious.

Momentum carried between moves

Flow depends on momentum surviving transitions, and momentum bugs are the most felt and least visible. Capture the velocity going into and coming out of each transition. A move that killed the player's speed shows a velocity that dropped across the transition when it should have been conserved or converted. The classic bug is a vault or mantle that resets velocity to a default instead of preserving the approach speed, turning a fluid chain into a dead stop. The before-and-after velocity names the offending transition exactly.

Conversion rules between moves are where this gets subtle. A wallrun-to-jump should convert horizontal speed into a launch, a slide-to-jump should preserve and maybe boost momentum, and each has an intended formula. A bug is when reality diverges from the formula, and the only way to tell a bug from an intended deceleration is to compare the captured before-and-after velocity to the design. Capture both, and a player complaining that a move felt like it killed their flow becomes a clear case of either a velocity-handling bug or an intended cost they are pushing back on.

Setting it up with Bugnet

Bugnet captures game state automatically through its in-game report button, which is exactly what fast traversal needs. When a player reports a broken flow, you attach the current traversal state, the recent transition history with timestamps, the inputs, the surfaces detected with their classifications and probe results, the player's speed, and the velocity before and after the transition as custom fields. The player describes the motion in a sentence while Bugnet records the state-machine trace and momentum that explain it, so a flow bug that happened in a half-second blur does not vanish before you can study it.

Occurrence grouping folds a recurring traversal bug at a particular spot or move into one issue with a count, so a transition that reliably drops flow surfaces above scattered reports. Filter by custom fields like move type, level area, or speed bucket to isolate the pattern, and crashes during a fast traversal chain arrive with stack traces and device context. The state traces, the surface reads, the momentum data, the duplicates, and the crashes all live in one dashboard you can prioritize by how many players each flow break affected.

Tuning flow with evidence

The durable practice is to make the traversal state machine and momentum observable. Keep a rolling buffer of recent states, transitions, inputs, surface reads, and velocities so any traversal report carries the trace that produced the break. Log transitions with their gating conditions so a missed vault is explainable. None of this changes how parkour feels, but all of it turns a felt-but-invisible flow break into a readable sequence you can replay and tune against.

Flow is the whole product in a parkour game, and flow bugs erode the exact feeling players came for, so they deserve evidence-based fixes rather than guesses. Capture traversal state and momentum early, and you can tune transition windows, detection cadence, and momentum conservation against real reported flows instead of running the same wall over and over hoping to feel the drop. Build the capture now, and your traversal will keep its flow under the speed and chaos where players actually push it, which is where parkour either sings or falls apart.

Parkour bugs are state-machine and momentum bugs. Capture the transition trace, the surface reads with speed, and the velocity in and out and a broken flow becomes replayable.