Quick answer: Stamina bugs come from rate and gating state: the current stamina value, the drain rate while acting, the regen rate and any delay before regen starts, and the thresholds that gate actions. Infinite sprints, frozen bars, and actions allowed at zero stamina all trace to that state. Capture the value, the active drain and regen rates, and the gating checks at the moment of the report and the fault is clear.
Stamina is the pacing system that tells players when they can sprint, dodge, climb, or swing, and when they have to wait. When it breaks, the whole feel of the game goes with it: a player sprints forever and trivializes your encounters, or gets locked out of dodging mid fight, or watches a bar that refuses to refill. Underneath the bar is a value that drains while acting and regenerates while resting, gated by thresholds that decide which actions are allowed. The bugs live in those rates, that regen delay, and those gates. This post covers capturing stamina state so a report about a broken bar tells you exactly which rate or gate failed.
Stamina is a rate problem first
Stamina is fundamentally a number changing over time, and rate problems are timing problems. Drain happens while an action is held, regen happens while it is not, and the two run on the same clock that everything else in your game depends on. If that clock pauses, stutters, or runs at the wrong rate, stamina drains too slow or regenerates too fast, producing the infinite sprint that players report as overpowered and you experience as confusing. Capturing the current value alongside the active drain and regen rates and the clock lets you check whether the number is changing at the speed it should.
The trap is that the visible bar is smoothed for feel, so it lags the real value. A player reporting that stamina did not go down may be describing the smoothed bar while the underlying value drained correctly, or the reverse. This is why you capture the raw stamina value, not the bar fill percentage, in your reports. The raw value is the source of truth your gating logic actually reads, and the bar is just a display of it that can drift, mislead, or animate at a different speed than the simulation.
The stamina state to capture
Capture the current stamina value, the maximum, the active drain rate and what action is causing it, the regen rate, whether regen is currently allowed, and the regen delay timer if you have one. Add the gating thresholds: the minimum stamina each action requires to start. With those fields you can reconstruct the exact moment of the bug. An infinite sprint shows a drain rate of zero while sprinting, or a regen that never stopped. A stuck bar shows regen disallowed with a delay timer that never expired. The numbers tell you which mechanism froze.
Include a short log of recent stamina events: action started, action ended, regen began, value clamped at zero or max. Many stamina bugs are about transitions rather than steady state, like a regen delay that should reset on every action but instead accumulates, or an action that should consume an up front cost but only drains while held. The event log shows those transitions in order, so a regen that starts too early or too late is visible as a timestamp that does not line up with the action that should have controlled it.
Gating bugs let players act on empty
Gating is the rule that you cannot dodge below a threshold, cannot sprint at zero, cannot attack while exhausted. The bug here is a check that reads stale stamina or runs at the wrong moment. If you check stamina at the start of an animation but deduct the cost at the end, a player can fire the action with insufficient stamina because the gate saw a value that the action itself was about to spend. Capturing the stamina value at the instant the gate evaluated, alongside the threshold it compared against, exposes this immediately when the value is below the threshold yet the action was allowed.
The opposite gating bug locks players out when they should be able to act, usually because the gate compares against the wrong value, like a max stamina that was reduced by a debuff but the threshold was not. Players experience this as the game feeling unresponsive or unfair, and they rarely report it precisely because it feels like input lag rather than a stamina rule. Capturing both the value and the threshold the gate used turns this fuzzy complaint into a concrete mismatch you can fix, by aligning the threshold to the current maximum rather than a hardcoded number.
Regen delay and the exhausted state
Most stamina systems have a regen delay: a pause after the last drain before the bar starts refilling, plus often an exhausted state when stamina hits zero that locks actions until a higher threshold is reached. These two mechanisms produce the trickiest reports because they are deliberately punishing, so a bug here is easily mistaken for harsh design. Capturing the regen delay timer and the exhausted flag separates the two: if the player is stuck and the exhausted flag is set with stamina above the recovery threshold, the flag failed to clear, which is a bug, not the intended punishment.
The regen delay itself causes the frozen bar reports. If the delay resets on every frame an action is held rather than only when an action fires, holding a non draining input could perpetually postpone regen. The captured delay timer reveals this as a value pinned just above zero, never counting down to completion. Once you can see the delay timer's behavior next to the action events, you can tell whether the regen pause is working as designed or whether some input is resetting it inappropriately, which is the difference between a feel complaint and a real fix.
Setting it up with Bugnet
Bugnet's in-game report button captures game state automatically, so a stamina report comes with the raw value and rates attached rather than a player describing a bar. Serialize stamina into custom fields: current value, maximum, active drain rate, the action causing drain, regen rate, regen allowed flag, regen delay timer, exhausted flag, and the gating thresholds, plus the game clock and recent stamina events. When a report says I could sprint forever, you open it and the drain rate field reads zero while the sprint action is active, naming the bug without any reproduction on your part.
Occurrence grouping folds matching stamina reports into one issue with a count, so an infinite sprint exploit or a regen freeze that hits many players surfaces as a single prioritized entry. You can filter by the action custom field to find every report tied to dodging or sprinting, and sort by occurrence to fix the most common gating failure first. With the raw value, rates, flags, and event log all in one dashboard, the smoothed bar stops misleading you and triage becomes a matter of reading the numbers the simulation actually used.
Testing stamina rates and gates
The durable fix is testing stamina against the captured state. Write tests that advance a controlled clock and assert drain and regen change the value at the configured rates, that the regen delay starts and clears on the right transitions, and that the exhausted flag sets at zero and clears at the recovery threshold. Test gates by setting stamina just below a threshold and asserting the action is blocked, then just above and asserting it is allowed, deducting the cost at the same moment the gate checks so stale reads cannot slip through.
Because your report serialization already captures the full stamina state, any strange report replays straight into a test as a regression. The teams that ship stamina systems that feel fair are the ones who can observe the raw value and rates at any instant and replay them deterministically, rather than relying on a smoothed bar and player intuition. When the rates, delays, flags, and gates are all observable and tested, the infinite sprint and the frozen bar both stop recurring and your pacing system holds together under the strange inputs players invent.
Trust the raw stamina value, not the smoothed bar. Capture the rates, delays, and gating thresholds and infinite sprints and frozen bars name themselves.