Estimating Calories From a Webcam: How CamPlay’s Tracker Works

CamPlay shows a live calorie counter while you play. A camera cannot measure energy expenditure — it can only see movement — so that number is necessarily an estimate, and estimates are only as honest as their documentation. The plain-language methodology lives on the how calorie tracking works page; this article is the engineering companion: how the counter is actually computed, frame by frame, and why it was designed conservative-by-default.

The core loop: integrate METs over time

The tracker is a numerical integrator over the MET scale. A MET (Metabolic Equivalent of Task) expresses an activity’s energy cost as a multiple of resting metabolism, with one enormously convenient property: 1 MET ≈ 1 kcal per kilogram of body weight per hour. That collapses the whole problem into one line, run every frame:

kcal += MET(currentActivity) × weightKg × dt / 3600

where dt is the frame time in seconds. Everything interesting is in MET(currentActivity) — a function of what the pose engine currently sees your body doing:

flowchart LR
  POSE["Pose signals<br/>jog speed · duck · lean · jump"] --> MET["MET lookup<br/>highest wins, never summed"]
  MET --> INT["Integrate each frame<br/>MET × kg × dt ÷ 3600"]
  KG["Body weight<br/>20–250 kg, default 70"] --> INT
  INT --> HUD["Live flame counter"]
  INT --> SAVE["Run saved<br/>daily + lifetime stats"]

The values are rounded from the Compendium of Physical Activities — the reference catalogue exercise science uses to standardize activity intensities. The jog mapping is the important one: because it consumes the engine’s continuous speed signal (itself built from arm-pump cadence and head bob — see how movement detection works), working harder raises your burn rate smoothly and immediately, rather than in coarse steps. The effort you feel and the number you see stay connected.

Max, not sum

When states overlap — you duck while still moving fast — the tracker takes the maximum applicable MET, never the sum. Physiologically, concurrent movements don’t stack their full costs; and product-wise, a tracker should never be flatterable by gaming its rules. Wherever the estimate must choose, it chooses to undercount. That principle repeats throughout:

• No camera, no calories. The integrator runs only while pose tracking is live and confident. Keyboard play credits exactly zero, and stepping out of frame pauses the count.
• The idle floor (1.8 METs) applies only while you are actually tracked standing in frame — it is light-standing-activity cost, not free income.
• Jump bonuses are per-detected-hop, and jump detection itself requires nose and hips rising together, so bouncing your head does not cash in.

The one personal input: body weight

Energy cost scales nearly linearly with mass, so weight is the single highest-leverage personal input. You can set it on any game page or in your profile (kg or lb); it is accepted between 20 and 250 kg and defaults to 70 kg when unset — meaning your numbers are generic until you enter it. It stays in your browser’s local storage and, if you sign in, in your profile, and is never shown to other players. Age, sex and fitness level also affect true expenditure, but their effect is second-order next to mass, and each added input raises the privacy cost of a free game — a trade-off we resolved toward asking for less.

From counter to history

When a run ends, the game emits a result event and the platform saves it atomically: the play itself (score, calories, distance, duration), your daily rollup (calories, sessions, active seconds, per game), and your lifetime total. That is what powers the stats page, the calorie side of the leaderboard, and shared run cards. The in-game counter is session-cumulative; each run’s delta is banked separately, so warm-up movement between runs shows on the live flame but never inflates a saved run.

What a camera can and cannot know

A webcam sees kinematics — what your body does. It cannot see physiology — what that motion costs you. It has no heart rate, no oxygen uptake, no body composition, no fatigue state. Two players of identical weight get identical credit for identical movement, even though their true burn differs. MET values themselves are population averages measured in laboratories, applied here to living-room approximations of those activities.

So calibrate expectations by use case. For comparing your own sessions — did I work harder than yesterday, is my streak honest — a consistent, documented estimator is exactly the right tool, and arguably fairer than gadget numbers you cannot inspect. For clinical decisions it is the wrong tool: CamPlay is not a medical device, and its estimates are not medical or dietary advice. Chest-strap heart-rate monitors and lab calorimetry exist for a reason. Where a webcam beats a wrist tracker, and where it loses, gets a full treatment in webcam games vs fitness trackers.

A worked session

A 70 kg player runs a five-minute Rune Run session at a solid pace — speed hovering around 0.6, so roughly MET 6 — with twenty jumps along the way. The continuous term contributes 6 × 70 × 300 / 3600 ≈ 35 kcal; the jumps add 20 × 0.005 × 70 = 7 kcal. Call it ~42 kcal in five minutes. Scaled to a half hour, that is in the same territory a fitness tracker credits for steady jogging — which is the sanity check that matters: the movement is real jogging, so the estimate should land in real-jogging range. Not because the number is precise, but because it is derived from the same physiology, transparently.