Bug Tracking for Simulation Racing Games

Simulation racing chases physical accuracy, which means the bugs are accusations of inaccuracy. A tire that should grip but slides, a force feedback wheel that goes dead in a corner, a suspension that bounces unrealistically, a setup change that does nothing: each is a claim that the simulation got physics wrong. Those claims are only debuggable against telemetry, the same telemetry a real engineer would read off a test rig. This post covers what physics and force data to capture so a sim racing complaint becomes a frame you can replay and analyze rather than a matter of opinion.

The tire model is the simulation

In a sim racer the tire model is effectively the whole game, because grip determines everything the driver feels. Bugs here are claims that the car does not behave like a real car: it snaps to oversteer too easily, it never locks the brakes, it loses grip on a surface it should hold. Capture per-tire data: vertical load, slip angle, slip ratio, contact patch temperature, and the resulting longitudinal and lateral forces. A snap-oversteer complaint is meaningless without the slip angles, but with them you can see whether the tire curve fell off a cliff where it should taper.

Tire temperature and wear add a time dimension to the bugs. Grip that degrades too fast or never recovers, a cold tire that grips like a warm one, or wear that resets between sectors are all state bugs in the tire model. Log the temperature and wear trajectory over the last several seconds, not just the instantaneous value, because the bug is usually in how the value evolved. When a driver says the car went off at turn three, the tire history shows whether a temperature spike or a wear cliff caused it.

Force feedback signal integrity

Force feedback is how a sim racer talks to the driver's hands, and a broken signal is one of the most reported and least describable bugs. The wheel goes light in a corner where it should load up, it clips and feels notchy, or it oscillates and tries to rip itself out of your hands. These are signal problems in the force feedback pipeline. Capture the raw force value the physics produced, the value after any filtering and clipping, the current force feedback gain, and the update rate of the signal.

The distinction between raw and processed force is critical for diagnosis. A wheel that goes dead might be a physics force that legitimately dropped to zero, or a clipping stage that saturated and flattened, or an output running below the device's update rate. By logging both the pre and post processing force, you can localize the fault to the simulation or to the signal path. When many drivers on the same wheel report the same dead zone in the same corner, the force trace pins it to a frame and a stage instead of a hardware guess.

Suspension, aero, and the setup screen

Suspension and aerodynamics turn the tire forces into car behavior, and they have their own bug surface. A suspension that oscillates and never settles, a damper that has no effect, an anti-roll bar that behaves backward: these show up as a car that feels unstable or wooden. Capture suspension travel and velocity per corner, the damper forces, and the current aero downforce front and rear. A car that bounces over a kerb is a damping bug, and the suspension velocity trace shows the oscillation that a video never could.

The setup screen is a notorious bug source because it promises that every slider matters. A common bug is a setup value that the physics never reads, so a driver changes the rear wing and feels nothing. Capture the full applied setup as structured data alongside the telemetry, so you can confirm the value the driver chose is the value the simulation used. When a report says the setup change did nothing, comparing the setup field to the active physics parameter immediately shows whether the slider is disconnected from the model.

Determinism, replays, and physics rate

Sim racers usually run physics at a high fixed rate, often well above the render rate, and many bugs only appear when that rate is disturbed. A frame drop that lets the physics step grow, a replay that integrates differently than live play, or a pause that does not freeze the simulation cleanly can all produce a one-off anomaly that no one can reproduce. Capture the physics step time, the number of substeps taken, and whether the frame was a catch-up frame at the moment of the report.

Determinism is your strongest debugging tool here. If your physics is deterministic given the same inputs and seed, a captured input stream replays the exact incident every time, which turns a one-in-a-thousand-laps anomaly into a reliable test case. Log enough of the input and timing state to feed that replay. When a driver reports the car snapped for no reason on a specific lap, a deterministic replay lets you step through the physics frame by frame and find the load transfer or tire event that triggered it.

Setting it up with Bugnet

Bugnet gives sim racing an in-game report button that captures full telemetry the instant a driver hits a problem, so the report that says the wheel went dead at turn six arrives with the force trace, per-tire slip and load, suspension travel, and the active setup already attached. The driver describes the symptom; the SDK carries the physics frame. Crashes, including a physics solver diverging into NaN, come with a full stack trace and device and wheel-platform context, so you can tell a content setup from a driver fault and a hardware issue from a simulation one.

Sim racing communities are detail-obsessed and report the same tire or force feedback issue many times, so Bugnet folds those duplicates into one issue with an occurrence count that tells you which physics complaint is widespread versus a single setup. Custom fields store the car and track IDs and a setup hash, while player attributes capture the wheel model and platform, since force feedback bugs are often device-specific. One dashboard lets you filter to a single car, track, or wheel and find the precise condition where the simulation diverges from what drivers expect.

Validating physics against the real world

The advantage of a simulation is that you can validate it against reality. Keep reference telemetry, whether from real-world data or from a known-good build, and compare the captured frames from bug reports against it. When a report's tire slip curve diverges from the reference at a known load, you have an objective bug rather than a subjective one, and you can fix the curve and re-run the comparison to confirm the simulation snapped back into line.

Build a regression suite of canonical laps that exercise the extremes: a high-load corner, a heavy braking zone, a bumpy kerb, and a low-grip surface, and run them every build while diffing the telemetry. Combined with field reports that carry real physics state, this keeps the simulation honest as you tune it. The promise of a sim racer is that the car behaves like a real one, and the only way to keep that promise is to debug against numbers, which is exactly what captured telemetry gives you.

Sim racing bugs are claims about physics. Capture telemetry the way an engineer reads a test rig and a vague the car felt off becomes a frame you can validate against reality.