Why does my fitness game track some players worse than others?

Motion tracking has to handle every body in every room, and that variety is where it breaks. A tracker tuned for a tall adult in bright light may lose a shorter player in a dim or cluttered room. Capture the sensor source, the reported tracking confidence, and the device, so you can see whether reports cluster around conditions like low light, which points to a robustness problem rather than a counting bug.

How do I debug a rep that was not counted?

Capture the motion data around the disputed rep, not just the final count: the signal the counter watched, the start and end thresholds, and the timestamps of detected transitions. With that you can replay the rep and tell whether the threshold was too strict, the player paused in a way the detector misread, or the range-of-motion gate was wrong, turning a dispute into a signal-processing problem.

My game counts accurately early and poorly later. What is happening?

That pattern points to sensor drift. Accelerometers accumulate error and camera trackers degrade as lighting shifts during a workout, so a calibration done at the start goes stale. Capture the calibration state, when it was last done, and how far into the session the problem appeared. If reports cluster late in long sessions or improve after recalibration, periodic recalibration is the fix.

Bug Tracking for Fitness and Exercise Games

Quick answer: Fitness game bugs come from the sensing layer: motion tracking that loses the player, rep counting that misses or double-counts, and sensor drift across different bodies, rooms, and devices. Track them by capturing the sensor source, the calibration state, and the motion data around a disputed rep, so you can tell a tracking failure from a counting-logic error and account for the huge variation in real play environments.

Fitness games are judged on a single question: did it count my effort correctly. When a player does a clean rep and the game does not count it, or counts a half-rep as two, the workout feels broken and the player feels cheated of the credit they earned. These games run on sensing, whether that is a camera doing pose detection, a controller with an accelerometer, or a phone strapped to an arm, and the bugs live in that sensing layer. On top of that, every player is a different body in a different room. This post covers tracking motion, rep counting, and sensor bugs across that variety.

Motion tracking across different bodies and rooms

Motion tracking has to work for every body in every room, and that variety is where it breaks. A camera-based tracker that works for a tall adult in a bright space may lose a shorter player in a dim room, or get confused by a busy background, a pet, or another person walking through. The model is doing its best with the input it gets, and the input varies enormously. A tracking failure is not the player doing the exercise wrong; it is the system failing to see them.

Track motion bugs by capturing the sensor source and the conditions as best you can: the tracking confidence the system reported, whether it lost the player mid-exercise, and the device and camera in use. When reports cluster around low light or a particular body type, you have a tracking robustness problem rather than a counting bug. Capturing the sensing context on each report is what lets you see the patterns across the wildly different environments your players actually exercise in.

Rep counting: missed, doubled, and partial

Rep counting is the most disputed thing in a fitness game, and it fails in three ways. A missed rep does not register a clean repetition. A double count turns one rep into two, often when the player pauses at the top or bottom. A partial count rewards an incomplete range of motion. Each erodes trust differently, but a missed rep is the worst, because the player did the work and got nothing for it, which is the exact opposite of what the game promised.

To track a rep-counting bug you need the motion data around the disputed rep, not just the final count. Capture the signal the counter was watching, the thresholds it used to detect the start and end of a rep, and the timestamps of the detected transitions. With that you can replay the rep and see whether the threshold was too strict, the player paused in a way the detector misread, or the range-of-motion gate was set wrong. The raw motion around the rep is what turns a counting dispute into a tractable signal-processing problem.

Sensor drift and calibration

Sensors drift. An accelerometer accumulates error over a session, a camera tracker degrades as lighting changes during a workout, and a calibration done at the start can be stale by the end. Drift shows up as counting that is accurate early in a session and unreliable later, which players describe as the game getting worse the longer I go. Because it is gradual, a single snapshot at the moment of complaint will not reveal it; you need to see how the sensing behaved over time.

Track drift by capturing the calibration state and when it was last performed, along with how far into the session the problem appeared. If reports cluster late in long workouts, or improve right after a recalibration, you are looking at drift rather than a fixed bug. The fix is often periodic recalibration or a more robust baseline, and you can only justify and verify it by seeing the session timeline that the drift reports give you.

Safety, intensity, and accessibility

A fitness game also carries responsibility for the player body. An intensity ramp that pushes too hard, an exercise that assumes a range of motion not everyone has, or instructions that are unclear at speed can lead to strain or injury. These are not crashes, but they are serious, and they intersect with accessibility, since players come with different abilities, equipment, and space. A workout the game forces past a player limit is a real problem worth tracking.

Give players an easy way to flag an exercise as too intense, unclear, or impossible for their situation, and capture the exercise, the intensity level, and any accessibility setting in use. These reports tell you where your difficulty curve or your movement assumptions exclude or endanger real players. Treat them as a distinct class from pure tracking bugs, because the fix is often a design change, an alternative movement, or clearer guidance rather than a tweak to the sensing code.

Setting it up with Bugnet

Bugnet fits fitness games because the in-game report button captures state automatically right after a disputed rep or a tracking failure, while the context is fresh and the player is already at the screen. You can attach the sensor source, the tracking confidence, the calibration state, and the motion data around the rep as custom fields, plus player attributes like device and camera. That turns the game did not count my rep into a report you can replay, where you can see whether tracking lost the player or the counting threshold misfired.

Because the same tracking weakness affects many players in similar conditions, Bugnet folds duplicate reports into one issue with an occurrence count, so a problem that hits players in low light or on a specific device rises to the top. You can filter by sensor source, device, or your custom fields to isolate, say, every double-count on a particular exercise, and route safety and intensity reports to their own view. One dashboard with the sensing context attached lets you fix the right layer, tracking, counting, or design, from evidence.

Testing against real-world variety

The studios that get fitness games right test against the variety their players live in, not a single ideal setup. That means trying different body types, lighting conditions, room sizes, and devices, and measuring how tracking and rep counting hold up across all of them. A counting pass done by one developer in a well-lit studio proves very little about a player in a cramped bedroom at night, which is where a lot of real workouts happen.

Make the disputed rep your test case. When a counting bug comes in with its motion data, replay it, fix the threshold or the tracking robustness, and add it to a suite of real recorded reps so the fix cannot regress. Let occurrence counts guide which conditions to harden first, and keep an eye on safety reports as carefully as counting ones. A fitness game wins loyalty when every honest rep is counted and every player feels seen, and you get there by tracking the sensing layer with the same rigor you bring to the workout itself.

Fitness players just want every honest rep counted. Capture the sensor source, the calibration, and the motion around the rep, and a dispute becomes a signal you can replay.