Bug Reporting for Games With Hunger and Thirst

Survival games live and die on their need meters. Hunger and thirst are supposed to create tension, sending players to forage and cook and find water, but when they bug out the tension collapses into frustration: a player dies of starvation with a full inventory, or wanders for hours and never gets hungry, or watches a thirst meter that drops impossibly fast. Each meter is a value that decays over time, modified by activity and environment, with thresholds that trigger penalties and eventually death. The bugs hide in those rates and thresholds. This post is about capturing need meter state so a survival death report tells you which meter and which rule failed.

Need meters are slow, which hides their bugs

Hunger and thirst decay slowly by design, often over many minutes, which makes their bugs uniquely hard to catch. A drain rate that is slightly too high will not be obvious in a thirty second test; it only manifests as an unexpected death an hour into a session. By then the player has done a hundred things and cannot tell you what caused it, so the report reads I randomly starved. The slow timescale also means these bugs interact with saving, loading, and time skipping, where a meter might decay during a load or fail to decay while a menu is open.

Because the meters are slow and persistent, they accumulate error. A decay applied per frame instead of per second runs at the frame rate, so a player on a fast machine starves faster than one on a slow machine, which is maddening to debug from reports alone. Capturing the current meter value, its decay rate, and the real elapsed time it has been decaying lets you compute whether the value matches the time, and a mismatch points straight at a per frame versus per second error or a decay that kept running through a pause it should have respected.

The need meter state to capture

For each need meter capture the current value, the maximum, the base decay rate, any active modifiers to that rate, and the elapsed time since the meter was last full or last replenished. Include the threshold values: where penalties begin, where damage begins, and the death threshold. With those fields a starvation death report becomes arithmetic. If the captured hunger value is well above the death threshold yet the player died of starvation, the death trigger compared against the wrong meter or the wrong threshold, which is a different bug from the meter draining too fast.

Capture the modifiers explicitly, because environment and activity stack onto the base decay. Sprinting, cold weather, and combat might each raise thirst decay, and a bug is often a modifier that applies and never removes, leaving the meter draining at a sprint rate while the player stands still. Seeing the active modifier list with the resulting effective decay rate exposes this instantly, where the effective rate is far above base while no activity justifies it. Without the modifier breakdown you cannot tell a too fast meter caused by a stuck modifier from one caused by a wrong base rate.

Decay rate bugs and the frame rate trap

The most common need meter bug is a decay rate computed wrong, and the most insidious version is decay tied to frame rate. If you subtract a fixed amount each frame rather than scaling by delta time, the meter drains proportionally to how fast the machine renders, so the bug only reproduces on certain hardware. Capturing the effective decay rate and the player's frame rate in the same report makes this visible, because a high decay rate correlating with a high frame rate across reports is a fingerprint of the delta time mistake that no single report would reveal.

Decay also breaks around time discontinuities. Sleeping through the night, fast traveling, or loading a save should advance the meters by the elapsed game time, and the bug is usually applying too much or too little. Capturing the elapsed game time alongside the meter delta across such events lets you check the math: did eight hours of sleep drain the meter by eight hours of decay, or did it apply real seconds, or nothing at all? These transition bugs are common precisely because they are special cased in code, and the special case is where the rate logic diverges from the steady state path.

Death thresholds and starving with a full plate

The death threshold is where need meters turn lethal, and the worst reports come from it firing wrong. A player who dies with a meter that the report shows well above the death threshold is hitting a trigger that read the wrong value, perhaps thirst when the death message said hunger, or a cached value that did not refresh after eating. Capturing both meter values and the cause of death in the report lets you confirm the mismatch directly, which is the only way to distinguish a genuine starvation from a death trigger reading stale or swapped state.

The opposite failure is a meter that crosses the death threshold without killing the player, leaving a survival game with no stakes. This usually means the threshold check is not running, perhaps gated behind a state the player is stuck in, or the meter is clamped above zero so it never reaches the lethal value. Capturing whether the death check ran and what value it saw separates these. A survival system that never kills is as broken as one that kills unfairly, and both are invisible without the threshold and the checked value recorded in the report.

Setting it up with Bugnet

Bugnet's in-game report button captures game state automatically, so a survival death report arrives with both need meters and their rates attached rather than a player guessing why they died. Serialize the meters into custom fields: per meter value, maximum, base decay rate, active modifiers, effective decay rate, and the penalty and death thresholds, plus the frame rate, the game clock, and the cause of death. When a report says starved with full food, you open it and the hunger value reads near maximum while the death cause names hunger, proving the trigger read the wrong state.

Occurrence grouping folds matching survival reports into one issue with a count, so a decay bug that quietly kills many players surfaces as a single prioritized entry instead of scattered death complaints. You can filter by the effective decay rate custom field to find meters draining too fast, and correlate against the captured frame rate to catch the delta time trap across reports. With meters, rates, modifiers, thresholds, and platform context in one dashboard, the slow and confusing survival bugs become a quick read of the numbers the simulation actually used.

Testing need meters across time and hardware

The reliable defense is testing meters against the captured state at varied timescales. Write tests that advance a controlled clock and assert each meter decays by the configured rate scaled by real time, not by frames, so the delta time trap cannot regress. Test the time discontinuities explicitly: sleeping, fast travel, and loading a save should advance the meters by the elapsed game time and no more. Test the death threshold by driving a meter below it and asserting the correct death fires with the correct cause, and another meter being full does not prevent it.

Run a soak test that simulates a long session and asserts no meter drifts due to accumulated per frame error, because these bugs only appear over time. Because your report format already serializes the meter state, any odd survival report replays straight into a test as a regression. Survival games earn their tension from need meters that behave consistently, and the teams that ship that consistency are the ones who can observe and replay the meter state at any point in a long session rather than trusting a slow moving bar that hides its own errors.

Need meters are slow, so their bugs hide for an hour. Capture value, rate, modifiers, and thresholds and the unfair starvation death explains itself.