To vibe code a stamina meter in an AI game prototype, prompt one stamina cost, one recharge rule, one visible exhausted state, and one route that changes when the player spends energy. If stamina only slows the player down, you have not made a mechanic yet. You have made waiting.
Stamina is one of those systems that sounds like design because it has a bar. Dangerous trap. A bar can make a prototype look finished while the actual play gets worse.
The first stamina meter should not ask, "How long can the player sprint?" It should ask, "Which path becomes possible, risky, or expensive when the player spends energy here?"
This is a first-playable workflow piece for browser-playable AI game prototypes and small-engine drafts. MDN is cited for game-loop context, Godot for visible progress bars, GDevelop for timer-based recharge rules, and Phaser for arcade movement and collision context.
Godot
A general game engine where a ProgressBar, player state, and movement script can make stamina costs visible and tunable.
GDevelop
A no-code and low-code builder where timers and variables are enough for sprint cost, cooldown, and recharge tests.
Phaser
A JavaScript framework for browser prototypes where movement speed, collision checks, and recharge logic can be tuned directly.
PICO-8
A tiny fantasy console that forces stamina feedback to stay readable with only a few pixels and inputs.
Stamina Is a Door, Not a Tax
Bad stamina is a tax on movement. The player sprints, the bar empties, and then the game tells them to wait before doing the fun thing again. That is not tension. That is a parenthesis.
Good stamina is a door. It opens one route and closes another. It lets you cross the spike gap now, but leaves you tired near the enemy. It lets you climb the shortcut, but removes your panic dodge at the top. The meter matters because the route changes.
If stamina never changes the route, cut the bar and make the movement faster.
Weak Prompt vs Route Prompt
| Prompt shape | Likely result | Sharper version |
|---|---|---|
| Add a stamina bar for sprinting | The player runs, waits, then runs again | Add one sprint meter that lets the player cross a short hazard route but leaves them unable to dash for 2 seconds afterward |
| Make movement more realistic | Slower traversal with a decorative meter | Make stamina drain only during one meaningful action: sprint, climb, dodge, or shove |
| Add exhaustion | A punishment state with no choice attached | When stamina hits zero, show a visible tired state and force the player onto the safer route until recharge starts |
| Make the level bigger | More empty walking between decisions | Keep one room and add two routes: a safe loop and a risky stamina shortcut |
Prompt One Spend and One Recovery
Do not start with sprinting, climbing, dodging, swimming, blocking, heavy attacks, and oxygen all fighting over the same meter. That is six arguments wearing one UI element.
Start with one spend. Sprint across danger. Climb a wall. Push through wind. Dodge through a laser. Then add one recovery rule that the player can read without a manual: stand still, touch safe ground, leave combat, collect a breath marker, or wait after landing.
Shortcut spend
Put a short route behind a stamina cost and make the long route safer but slower.
If the shortcut is always correct, it is a toll booth. If it is always wrong, it is decoration.
Panic reserve
Let the player sprint freely, but keep one dodge or jump unavailable when stamina bottoms out.
If players cannot see the empty-state consequence, they will call the hit unfair.
Recharge position
Make stamina recharge only in safe pockets so route planning matters before the chase starts.
Do not hide the recharge zone. The player should understand why the bar came back.
Greed climb
Place an optional pickup or platform above the safe path and make reaching it cost most of the meter.
If the pickup is just score, the test overlaps with collectible design. Tie it to route, timing, or safety.
The Empty Bar Needs a Face
A stamina meter fails when the only feedback is a tiny rectangle shrinking. Give exhaustion a face. Change the run pose. Drop the shoulder. Add a short puff. Mute the sprint trail. Make the recharge pulse obvious.
The point is not realism. The point is blame. When the player misses the shortcut, they should know whether they spent too early, waited too long, chose the wrong route, or ignored the recharge window.
- There is one stamina spend in the prototype, not a shared meter for every action.
- The stamina spend changes route, timing, hazard exposure, or recovery.
- The player can see the meter before the first spend matters.
- Empty stamina has a visible character state, not just a missing bar segment.
- Recharge has a rule the player can explain after one attempt.
- The safe route still works when the player wastes stamina.
- A tester can say why they saved, spent, or regretted stamina on the second run.
Drain rate
Players understand the route choice but the shortcut is too free or too punishing.
Tuning how expensive the brave path feels.Recharge delay
Players spend correctly once but cannot plan the second spend.
Controlling rhythm without adding more mechanics.Meter size
The route idea works and you need to support two linked decisions instead of one.
Extending the loop after the first choice earns it.FAQ
How do I vibe code a stamina meter in an AI game prototype?
Prompt one stamina cost, one recharge rule, one visible exhausted state, and one route decision that depends on spending energy. Test that route before adding more stamina actions.
Should stamina make the player slower?
Only if slowness creates a choice. If stamina just interrupts movement, the prototype will feel worse without teaching you much.
What is the best first stamina test?
A risky shortcut is the cleanest first test. Give the player enough stamina to take it, then make the recovery cost visible before the next hazard.