Bug Reporting for Games With Temperature Systems

Temperature systems promise that the world has consequences: stand near a fire to warm up, seek shade in the desert, dress for the cold. When they bug out, the world stops making sense, and players freeze to death beside a roaring campfire or take heat damage standing in a snowstorm. Temperature is the sum of many inputs, ambient climate plus nearby heat and cold sources plus insulation from gear, resolved into a single body temperature that crosses thresholds into damage. The bugs hide in how those sources are gathered, weighted by distance, and compared to thresholds. This post is about capturing that calculation so an absurd temperature report names the input that went wrong.

Temperature is a sum, and sums lose terms

A player's temperature at any moment is the result of adding up contributions: a base ambient value from the climate or time of day, positive contributions from heat sources like fires and the sun, negative contributions from cold sources like water and snow, and a modifier from insulating gear. Each contribution is usually weighted by distance or exposure. When this sum is wrong, it is almost always because a term was dropped, double counted, or weighted incorrectly, and the player experiences the nonsensical result without any way to see which term misbehaved.

The classic freezing by a fire report is a heat source that failed to contribute. Maybe the fire's warmth check uses line of sight and a tiny obstacle blocked it, or the distance falloff dropped to zero just inside the radius the visual flames imply. Capturing the list of sources the system actually summed, with each one's magnitude and the distance weighting applied, turns this into a visible omission. You see the fire in the world but not in the summed sources, and you immediately know the gathering step, not the math, is the culprit.

The temperature state to capture

Capture the player's current body temperature, the ambient base for their location, the full list of contributing sources with each source's type, raw magnitude, distance, and the weighted value it actually added, the total insulation from gear, and the resulting net temperature. Add the threshold values for cold damage, heat damage, and any comfort band. With those fields the report becomes an audit of the sum. You can add up the contributions yourself and check they equal the net temperature, and any discrepancy points at a term being mishandled between gathering and totaling.

Capture the gear insulation separately from the sources, because insulation bugs are common and distinct. Insulation should reduce the magnitude of temperature swings, and a bug often makes it apply to only heat or only cold, or apply twice, or not update when gear changes. Seeing the insulation value next to the net temperature lets you tell whether a player froze because the heat source was missed or because their cold weather gear was not counted. These are different fixes in different parts of the code, and only the captured breakdown distinguishes them.

Sources, distance falloff, and occlusion

Heat and cold sources contribute based on proximity, and the distance falloff is a frequent bug source. A linear falloff, an inverse square falloff, and a hard radius cutoff all feel different and break differently. A cutoff set slightly smaller than the visual effect means players standing in the obvious warmth get nothing, which reads as the system being broken when it is merely mis tuned. Capturing each source's distance and weighted contribution lets you see the falloff curve in practice and confirm whether a source that should help is contributing the amount the player expects from its appearance.

Occlusion adds another layer. If warmth requires line of sight to the fire, then a wall, a rock, or even a dropped item can block it, and players will not understand why standing behind a thin barrier freezes them. Capturing whether each source passed its occlusion check, and against what, makes these reports tractable. A fire present in the world but marked occluded in the captured sources tells you the line of sight test is too strict or testing against the wrong geometry, which is a far more precise diagnosis than the player report of the fire stopped working.

Damage thresholds and delayed effects

Temperature damage triggers at thresholds, and like all threshold systems it breaks when the check reads the wrong value or fires on the wrong cadence. A player taking cold damage at a temperature the report shows inside the comfort band means the damage trigger compared against an unmodified temperature that ignored insulation, or against a stale value from before they warmed up. Capturing the net temperature the damage check actually evaluated, alongside the threshold, confirms the mismatch and points at whether insulation or staleness caused it.

Temperature also tends to have momentum: the body warms and cools gradually rather than snapping to the ambient. That smoothing is good for feel but creates lag between the environment and the effect, and a bug in the smoothing can leave a player taking damage long after they reached safety. Capturing both the instantaneous environmental temperature and the smoothed body temperature lets you see this gap. When the environment reads warm but the body temperature lags far behind, the smoothing rate is too slow, and the report of I kept freezing after reaching the fire becomes an obvious tuning fix.

Setting it up with Bugnet

Bugnet's in-game report button captures game state automatically, so a temperature report comes with the full source breakdown attached rather than a player describing the weather. Serialize the calculation into custom fields: body temperature, ambient base, the list of contributing sources with magnitudes and weighted values, gear insulation, net temperature, and the damage thresholds, plus the location. When a report says freezing next to a fire, you open it and the source list omits the campfire entirely, or shows it occluded, naming the gathering bug without you ever loading the save.

Occurrence grouping folds matching temperature reports into one issue with a count, so a falloff or occlusion bug affecting a whole biome surfaces as a single prioritized entry rather than scattered confusion. You can filter by the location or source type custom field to find every report near a given heat source, and compare the weighted contributions across reports to spot a falloff curve that is tuned wrong. With the entire temperature sum, the insulation, and the thresholds in one dashboard, the impossible weather reports become an audit you can read instead of a phenomenon you struggle to reproduce.

Testing temperature in controlled scenes

The durable fix is testing the temperature sum in controlled scenarios against the captured state. Build test scenes with a known fire at a known distance and assert the contribution matches the falloff curve, with and without occlusion, with and without insulating gear. Assert that insulation reduces swings symmetrically unless designed otherwise, and that the damage thresholds fire on the net temperature including insulation, not the raw environmental value. Because your report serializes the full source list, any odd report replays into a test as a deterministic regression case.

Add a test for the smoothing rate so that reaching a heat source clears cold damage within the intended time, preventing the lingering damage reports. The teams that ship believable temperature systems are the ones who can see the entire sum at any moment, every source, its weight, the insulation, and the threshold, rather than inferring it from a single body temperature number. When the calculation is fully observable and testable, freezing by a fire stops being a baffling player story and becomes a missing term you can point to in the captured breakdown.

Temperature is a sum of weighted sources. When a term goes missing the player freezes by a fire. Capture the whole sum and the missing term shows itself.