A small game economy becomes easier to reason about when every resource change has a visible cause. Begin with the choices the player should face, then test whether earning and spending create those choices. This guide uses a fictional expedition game with earned coins and equipment upgrades. Its numbers are worked examples for a test plan, not recommended prices, measured player behavior, or a forecast of engagement.
/01
Map resources and transactions explicitly
List each resource, its starting amount, how it enters the economy, and how it leaves. Include rewards, purchases, refunds within the game, one-time grants, and any caps. Keep a transaction row with previous balance, cause, amount, and resulting balance. Unity's Economy documentation distinguishes currencies, inventory items, and purchases; that separation is useful vocabulary even when your game uses a different implementation.
For the expedition example, suppose a successful run earns 12 coins and an upgrade costs 60. With no starting coins and no other spending, five successful runs cover the price. That arithmetic is only the first check. Write down what the player does during those runs, what failure earns, and whether another useful purchase competes for the same coins before deciding whether the wait feels worthwhile.
/02
Build a few explicit player scenarios
Create short sequences representing different decisions: saving for the upgrade, buying consumables first, failing several runs, and returning after a break. Calculate each sequence from the same initial state. If a consumable costs six coins and is purchased after every successful run, the example's net saving is six per success. The upgrade then needs ten such successes, assuming no other resource changes.
Replay those scenarios inside the game and compare the visible balances with the calculation. Check rounding, caps, awarded quantities, and displayed costs at each step. A spreadsheet can expose arithmetic, but it cannot establish whether a purchase is understandable or enjoyable. Observe whether players notice the upgrade's effect and can explain the tradeoff they made when choosing a consumable instead.
/03
Test boundaries before adjusting pacing
Exercise balances just below the price, exactly equal to it, and above it. Try the same purchase with a full inventory or an unmet unlock condition. The game should explain the actual restriction and leave balances consistent. If a purchase fails after the interface has shown an animation, verify that the animation has not hidden a partial deduction or an item granted without its intended cost.
Repeat the completion or purchase signal in a controlled test environment to check the transaction boundary. A duplicate callback must not award the expedition twice or charge twice for one logical purchase. Interrupt persistence and retry with disposable data. These correctness checks belong before pacing adjustments: lowering prices cannot repair a ledger that sometimes loses coins, and a generous reward can conceal repeated grants during casual testing.
/04
Evaluate the choice, then change one lever
Ask a playtester what they are saving for and why. If they cannot identify a desirable purchase, earning speed may not be the main issue. If they understand the upgrade but find repeated runs monotonous, investigate the underlying loop as well as the price. Track the actual route taken and spending decisions without treating a tiny sample as a prediction for the whole audience.
Choose one change, such as reward amount, upgrade cost, or competing consumable value, and replay the scenario ledger. Acceptance means balances reconcile, boundary cases behave consistently, purchase effects are visible, and the intended tradeoff can be understood in play. Document which scenarios improved and which became worse. Keep the previous configuration and save fixtures so later content changes can be checked against the same baseline.
Keep this in mind
Key takeaways
- Track every source and sink with a transaction ledger and explicit starting conditions.
- Separate economy correctness from the pacing and appeal of player choices.
- Change one lever and replay both arithmetic scenarios and actual playtest decisions.
Sources & further reading
Consult the source documentation for the version and platform you are working with.