Quick answer: Arcade racers live or die on feel, and bugs in the handling model, drift mechanic, boost system, or collision response break that feel in ways players struggle to describe. Capture the vehicle velocity, grip state, drift charge, boost timer, and the surface and collision contacts at the moment something felt wrong. With that snapshot you can replay the exact handling state instead of trusting a player's it felt slippery.
Arcade racing is the art of a handling model that feels great while ignoring real physics. Cars drift on a knife edge of grip and slide, boost rewards risk, and collisions are forgiving but punchy. When any of these systems glitches, players rarely say grip transitioned to slide a frame early; they say the car felt wrong. That gap between subjective feel and the underlying state is where arcade racing bugs hide. This post covers what vehicle and physics state to capture so a handling complaint becomes a reproducible moment you can actually debug.
The handling model and grip transitions
The handling model is the heart of an arcade racer, usually a simplified tire model that blends grip and slide based on speed, steering angle, and surface. Bugs here are insidious because they manifest as feel: a car that suddenly understeers, a turn-in that hitches, a grip level that does not match the surface. Capture the current velocity, the steering input, the computed grip coefficient, and the slip angle at each wheel. A handling complaint without these numbers is unfalsifiable; with them you can see whether grip dropped when it should not have.
Grip transitions are the sharpest edge. The instant a car crosses from grip into slide is what gives arcade drifting its snap, and a one-frame error there feels like the car betrayed you. Log the grip state machine, which gear or mode the handling is in, and the threshold values that triggered the last transition. When many players report the car spins out of nowhere on the same corner, the transition data shows whether the threshold is mistuned or a surface query returned the wrong material.
Drift, charge, and boost systems
Drifting and boosting are tightly coupled in arcade racers: hold a drift to build charge, release for a boost. This loop has a rich set of bugs. A drift that does not register charge, a charge that resets when it should hold, a boost that fires at the wrong tier or does not fire at all. Capture the drift state, the accumulated charge, the boost tier reached, and the timestamp of the last drift input. A player who says my boost did not trigger is usually hitting a charge-reset bug, and the charge timeline reveals exactly when it dropped.
Boost itself adds physics bugs. A boost should apply a forward impulse and a speed cap override for its duration, and bugs appear when the impulse stacks, the cap fails to restore, or the boost timer runs while paused. Log the active boost timer, the speed cap currently in effect, and the impulse applied this frame. A car that stays inexplicably fast after a boost ends is a cap-restore bug, and the boost timer plus speed cap fields make it obvious instead of leaving you to guess from a top-speed screenshot.
Collision response and recovery
Arcade collisions are designed to feel punchy but recoverable: clip a wall and you lose speed and get nudged, but you should not flip or get stuck. Bugs break this contract. A car that flips on a glancing wall touch, one that gets wedged in a corner, or one that launches off a barrier all stem from collision response applying too large an impulse or the wrong contact normal. Capture the collision contact points, the surface normals, the relative velocity at impact, and the impulse the solver applied.
Recovery logic is its own source of bugs. Many arcade racers auto-correct a car that is upside down or off-track by respawning it on the racing line after a delay. That logic can fire when it should not, respawn the car facing backward, or place it inside another vehicle. Log the recovery state, the trigger that fired it, and the chosen respawn transform. When a player reports it teleported me into a wall, the recovery fields show whether the off-track detector tripped early or the respawn point was badly placed.
Surfaces, weather, and dynamic conditions
Arcade tracks love variety: tarmac, dirt, wet patches, ice, and weather that changes grip mid-race. Each condition feeds the handling model different values, and the bugs cluster at the seams. A wet patch that does not reduce grip, a dirt section that applies tarmac handling, or a rain state that fails to clear all produce handling that contradicts what the player sees. Capture the current surface material, the weather state, and the grip modifier each contributed at the moment of the report.
Dynamic conditions also interact with the boost and drift systems in ways that compound bugs. Drifting on ice should behave differently than drifting on tarmac, and if the surface modifier is read a frame late, the drift charge accrues at the wrong rate. By logging surface and weather alongside the handling state, you can separate a genuine physics bug from a player simply not expecting reduced grip in the rain, which is the difference between a fix and a tooltip.
Setting it up with Bugnet
Bugnet puts an in-game report button right in the car, so a player who just spun out unfairly can report it in the moment, and the SDK captures the vehicle state automatically. You wire that capture to include velocity, grip coefficient, slip angles, drift charge, boost tier and timer, surface material, and the last collision contacts. The player describes the feel; the snapshot carries the numbers. Crashes during a physics-heavy pileup arrive with a full stack trace and device and platform context, so you can separate a content bug from an engine fault immediately.
Because the same handling complaint arrives from many players on the same corner, Bugnet folds duplicate reports into one issue with an occurrence count, and that count is your tuning priority. A grip-transition bug with two hundred reports on one turn outranks a rare collision flip. Custom fields store the track ID and surface type, player attributes track platform and input device, and a single dashboard lets you filter to one track or surface to find exactly where the handling model misbehaves rather than reading every report by hand.
Tuning by data, not by vibes
The temptation in arcade racing is to tune by vibes, adjusting grip and boost values until the loudest tester stops complaining. Captured state replaces that with evidence. When every handling report carries velocity, grip, and surface, you can build a heatmap of where on each track the car misbehaves and tune the specific corners and surfaces that produce reports rather than blindly nudging global values and breaking what already felt good.
Keep a set of reference replays that capture the feel you are aiming for, and run new builds against them to catch regressions in the handling model before they ship. Combined with field reports that carry real vehicle state, you converge on a car that feels intentional everywhere. The goal of an arcade racer is a handling model players trust, and trust comes from a car that behaves the same way every time, which is exactly what reproducible state lets you guarantee.
Arcade racing is all feel, but feel is just state you have not captured yet. Log the grip, drift, and boost numbers and tune by evidence instead of vibes.