Start with a working loop, then make its progress reliable
An idle game needs more than a counter that increases while a page is open. Players expect purchased upgrades to survive a refresh, a return visit to award sensible progress, and later updates not to erase their work. Treat saving, offline settlement, and compatibility as separate behaviors with separate checks.
This workflow continues an illustrative greenhouse design, not an existing generated or tested project. Clicking earns fictional coins; each purchased gardener produces one coin per second. The next gardener costs ceil(10 × 1.15^n), where n is the number already owned. Begin with a working earning-and-buying loop. You will define a save contract, calculate a capped return award, and preserve progress through one later edit without confusing local storage with cloud saving.
Specify what the game needs to remember
Write the save contract before requesting code. A minimal version includes a schema version, current coin balance, gardener count, purchased upgrades, and the time through which earnings have already been settled. Keep production-rate rules alongside upgrade definitions. Save the purchases behind the displayed balance, not contradictory copies of derived state.
Ask for a readable save summary during development so you can compare game state with the stored state. Avoid exposing private information in diagnostic output. Also distinguish a local save from an account-based save. Browser storage belongs to a browser profile and may be cleared. It does not promise cross-device progress, secure competitive balances, or recovery after the player deletes site data.
Use this bounded request:
Add a versioned local save for coins, gardeners, purchased upgrades, and the last settled time. Restore the state before showing a playable screen. Validate loaded values. If no save exists, start a new game. If a save is invalid, explain the recovery behavior instead of silently producing impossible balances. Keep existing artwork and earning rules unchanged.
Save after meaningful purchases and define periodic saving if the game needs it. Do not rely exclusively on a page-close event: a browser or device can stop without delivering the final event you expected.
Calculate away rewards once, with a clear cap
Offline progress usually means calculating an award when the player returns. It does not require the game script to run continuously after the browser is closed. A transparent rule is:
award = eligible saved production rate × min(max(return time − last settled time, 0), eight hours)
Decide what the eligible rate means before implementation. In this simple design it is the production rate from the saved gardeners and upgrades at departure. Defer complex simulations until basic settlement works.
For an expected-value check, two gardeners producing one coin each per second would earn 1,200 coins over a controlled ten-minute interval. Ten hours away would use only eight hours under the example cap. Use the calculation as the expected value in your run log.
After awarding progress, the game must update the settlement state so a refresh does not award the same absence again. Request a return message showing the duration used and reward granted. Describe the calculated award without implying a continuously running server.
Worked examples: offline rewards
These examples assume a fixed production rate, fictional coins, and a two-hour cap where stated. They describe expected calculations, not measured results from a tested game.
| Scenario | Calculation | Expected award |
|---|---|---|
| 1 gardener, away 10 minutes | 1 coin/second × 600 seconds | 600 fictional coins |
| 2 gardeners, away 30 minutes | 2 coins/second × 1,800 seconds | 3,600 fictional coins |
| 1 gardener, away 3 hours, 2-hour cap | 1 coin/second × min(10,800, 7,200) seconds | 7,200 fictional coins |
| Reload immediately after settlement | Previously settled interval is not counted again. | 0 additional coins for that interval |
Test saving separately from time settlement
First earn a known balance, buy one gardener, and refresh. Confirm the balance and purchase survive. Next close the browser, wait a measured interval, and return. Record the starting state, elapsed real time, observed award, and final state. Refresh immediately and check that the same award is not repeated.
Use a controlled test clock for long intervals and a genuine close-and-return check for the normal path. Test a negative elapsed interval, an implausibly large interval, an empty save, and a damaged save. State how each should behave before looking at the outcome. A negative interval should not subtract earned currency. A large interval should not bypass the cap.
Local device time can be changed by the player. Clamping elapsed time helps prevent obvious errors; it does not turn a local economy into a tamper-resistant one. Competitive or paid economies need a separate authoritative settlement and security design.
Return-visit test matrix
| Action | Expected behavior | If the check fails |
|---|---|---|
| Purchase an upgrade, then refresh | The saved balance and purchased upgrade return together. | Inspect which fields were saved and when the save occurred. |
| Return after a measured interval | Award follows the documented rate and time cap. | Compare the stored settlement timestamp, rate, and elapsed time. |
| Reload immediately after the return award | The same interval is not awarded twice. | Check that the settlement timestamp advances with the award. |
| Open another browser or device | Behavior matches the stated local or account-based save model. | Check whether a cross-device synchronization mechanism exists. |
| Load an older save after a rule change | Purchases and balance follow the documented migration. | Inspect the save version and migration or recovery path. |
Make a later upgrade without resetting the player
Once saving works, request a small content change:
Change the base gardener price from ten to eight coins for future purchases, keeping the 1.15 growth factor. Preserve existing coins, gardeners, owned upgrades, visuals, and offline settlement. Support the current saved-data version. Show how an older save is migrated if the new state requires additional fields.
Keep an actual pre-change save and a working build before making this request. Load that save into the revised version and compare the resulting balance, purchases and production rate. Adding a new field should not cause the whole state to be discarded simply because the old save lacks it. Decide whether earlier purchases retain their benefits before changing the economy.
If upgrades disappear, inspect migration and loading before adding features. A new button is not evidence of save compatibility.
Use SEELE for bounded persistence edits
SEELE provides a prompt-led workflow for creating games and requesting subsequent changes. Here, the relevant input is the working economy plus a specific save contract; the desired output is a candidate revision whose loading and settlement behavior you can inspect. Ask for the smallest persistence change before requesting migration or new upgrades.
Keep a working build and a baseline save outside the edit you are evaluating. Report exact state differences when a check fails, including whether the problem occurred on load, return, or purchase. Product positioning alone does not establish cloud saves, secure clocks, migration guarantees, or the reliability of a particular local-storage implementation.
Continue only after the return visit makes sense
A reliable idle game should explain where its numbers come from: what produced the reward, which absence interval counted, and which purchases remain owned. Use AI assistance for bounded changes to those rules, then judge each change in the running game. Do not trade a working save for a larger feature list.
Use SEELE to request one local save and one capped return award in your existing project. Preserve a known working version before requesting another economy change. The next milestone is not a bigger promise; it is a verified return visit with the player's previous progress intact.
FAQ
Does offline progress mean the game runs while my browser is closed?
Not necessarily. A common approach stores the state and settlement time, then calculates an award on the next visit. That can support an offline-reward design without a continuously running browser process. Check the actual implementation before describing it. Server-side simulation is a different architecture and should not be implied by a locally calculated reward.
Will a browser save move to another device?
Do not assume so. Local browser storage normally remains tied to that browser profile and site storage. Cross-device saves need an explicit synchronization or account system, along with conflict handling and privacy decisions. Tell readers what the tested demo actually uses rather than presenting a local persistence example as a cloud-save feature.
Can I change upgrade prices after people have already played?
Yes, if the revised design defines how existing purchases and saved state are treated. Preserve a baseline save, decide which benefits remain owned, and test migration before releasing the change. Simply overwriting the price list does not prove old progress remains valid. If the behavior is still untested, describe it as a requirement rather than a successful update.
