The resource game shows balance, helpers, production rate, next price, total earned, and total spent together. Prices progress through 3, 5, and 7, with a maximum of three helpers. Balance always equals earned minus spent, even when fractional production arrives between actions.
Use the worked example
Press Start, then Earn five times and Buy helper. Watch the rate change from zero to one unit per active second. Advance 1s adds an extra simulation second after settling elapsed automatic time, so three clicks need not leave exactly five units. Use the displayed totals when deciding whether the next purchase is affordable.
Trace the result step by step
Start with balance 0, helpers 0, totalEarned 0 and totalSpent 0. A fresh manual Earn activation adds one to balance and totalEarned. Press and release Enter or Space for each Earn or Buy action; holding a key does not repeat it. Pointer clicks still activate the same actions. Only Running permits Earn or Buy.
The resource-click and helper-production idea is described in GSoster's idle-game README. Here the quantities are game units. Manual clicks and helper production both increase earned, while purchases increase spent; their separate totals let you explain where the current balance came from.
For n helpers owned before purchase, one new helper costs 3 + 2n. Ownership is capped at three; production rate is n units per active simulation second.
Reaching three helpers stops further purchases but does not end the game. Production continues at three units per active second while Running. Pause freezes that production and blocks earning, buying, and manual advancement. Resume continues from the current balance; Reset returns to the zero-value Ready state.
For a clean arithmetic example, start with five manual units and no helper production. Buying the first helper costs three, leaving two. Exactly three active production seconds add three, making five available for the second helper. That purchase costs five and leaves zero; two more seconds at rate two produce four.
In that calculation, total earned reaches twelve and total spent reaches eight, so the final balance is four. In the running page, extra elapsed fractions can change the balance before the next click. This does not change the price rule or the relationship between earned and spent.
Each stage of this example satisfies balance = totalEarned − totalSpent. Purchases increase spent; they do not reduce earned history. Production increases earned and balance; it does not count as a manual click.
Before a purchase, advance the one clock to the action's accepted simulation time and credit all retained elapsed production using the old helper count. Then validate affordability and cap, charge once and increment ownership. The new rate applies only afterward.
For example, suppose one helper is active and balance 4.5. After another half active second, the old helper produces 0.5, reaching 5. A purchase can then charge 5 and add the second helper. Charging first or applying rate 2 retroactively to that half-second changes the result.
An insufficient or capped purchase leaves transaction fields unchanged after time settlement. Time that legitimately produced resources is not rolled back merely because the subsequent Buy failed. Read any production credited before the rejection separately from the failed purchase itself.
The automatic display updates around every tenth of a second. Calculations retain fractional elapsed production; only the displayed quantities are rounded to three decimal places. That prevents a helper's small contributions from being lost just because each update produces less than one whole unit.
Each clock advance retains at most one simulation second. A long stall discards excess catch-up rather than accumulating a backlog. The display can therefore advance more slowly than wall time. Hiding the page pauses it; returning does not credit the time spent away.
Copy a prompt for this example
Build one self-contained HTML resource game with Start, Earn 1, Buy helper, Advance 1s, Pause, Resume, and Reset. Display phase, balance, helper count, production rate, next cost, total earned, and total spent together.
Begin Ready with all values zero. Only Running permits earning, buying, or advancing production. Each manual Earn adds one unit to balance and earned. If n helpers are owned, the next helper costs 3 + 2n, up to three helpers. Production is n units per active simulation second.
Use one elapsed-time clock. Before a purchase, settle elapsed production at the old helper count, then check affordability and cap, charge once, and add the helper. Rejected purchases must not reverse legitimate production already settled. Balance must always equal earned minus spent.
Refresh the automatic clock around every tenth of a second, retain fractional production, and cap any individual elapsed advance at one second. Discard excess catch-up. Advance 1s first settles automatic elapsed time, then adds one extra simulation second; clearly explain that real clicks therefore need not produce exact integer balances.
For the arithmetic example, five manual units buy the first helper for three. Exactly three active production seconds then permit the second helper for five; two more seconds at rate two produce four units.
Pause and hidden-page state freeze production; Resume takes a fresh time reference. Reset returns Ready with zero values. Use large buttons, clear unit labels, and a narrow-screen layout. Return complete HTML with inline logic.
Use the earned and spent totals to explain the next helper purchase before changing its cost or timing rule. NOS can preview the HTML resource game for that discussion. Compare the live balance with elapsed production, rather than expecting the exact-time arithmetic example after an arbitrary sequence of clicks.