Adding a reward is easy to describe and harder to judge in isolation. A few extra coins may make the next purchase arrive sooner, change which choice a player makes or leave a balance growing with little to spend it on. Before changing a game build, a small model can show what the proposed rule does under a few explicit assumptions. The result should help the designer choose a question for the next playtest.
This guide uses a fictional garden game with a virtual currency called seeds. The numbers are illustrative arithmetic, not player data or a recommended economy. Seeds exist only inside the imagined game. There is no crypto asset, cash exchange, wallet or player-fund handling in the model. Keeping the scope this small lets a designer inspect the relationship between rewards, purchases and the pace of a session.
Define the loop in one short paragraph
In the example, a new player begins with 20 seeds. Completing a delivery awards 8 seeds. A decorative pot costs 15 seeds and a fountain costs 45. A sample session contains three deliveries, with one purchase opportunity after each delivery. The model has no random rewards, refunds or bonuses. Those assumptions are written above the table so another designer can reproduce the result.
Decide what the model should answer before building it. Here the question is: can a player buy a small decoration early while still seeing a reason to save for a larger one? That is a design intention, not a fact the arithmetic can prove. The table can show when each purchase is affordable. A playtest is needed to learn whether the choices are interesting to the people playing.
Record sources and sinks separately
Create columns for event number, event name, amount added, amount removed and closing balance. The opening row contains 20 seeds. A delivery adds 8. A purchase removes its stated cost. The balance formula is previous balance plus the amount added minus the amount removed. Keep both columns visible, even if a single signed-amount column could do the calculation, because the distinction helps a design review.
Walk through a player buying a pot at the first opportunity. After delivery one, the balance is 28. The pot removes 15, leaving 13. Delivery two brings it to 21, and delivery three to 29. At the end of that session, the fountain is still out of reach. That sequence is easy to explain from the rows, and it gives the team a concrete scenario to discuss.
Compare a second choice using the same rules
Now model a player who saves throughout the first session. Three deliveries add 24 seeds to the opening 20, so the closing balance is 44. That is one seed below the fountain's price. The first delivery of the next session brings the balance to 52. Buying the fountain then leaves 7. The model has exposed a precise pacing question: is waiting for that next delivery the experience the team intends?
Try a third player who buys a pot whenever the current balance permits it. With the same three deliveries, the balances after purchase decisions are 13, 6 and 14. The player finishes with two pots and 14 seeds. No hidden simulation is needed. Each row follows the same rule, and the team can see how a repeated small purchase changes the path to the larger decoration.
Change one assumption at a time
Suppose the proposed update raises the delivery reward from 8 to 10. A saving player would finish the first session with 50 seeds and could afford the fountain after the third delivery. A player buying one early pot would finish with 35. The reward change has moved an affordability point for one scenario. It has not established that the game is more enjoyable or that every player will follow either path.
Keep the original and revised tables side by side. Label the changed cell and write one sentence describing the effect. If you also lower the fountain cost and add a login bonus, the comparison becomes harder to interpret. Separate those changes until you know which assumption is doing the work. A small model is most useful when the designer can trace an outcome back to a specific decision.
Include the slower session
The three-delivery session is only one scenario. Add a one-delivery session and a five-delivery session, with the same purchase choices. A player completing one delivery per session reaches the saving milestones on a different schedule from a player completing five. The model can show both paths without claiming either is typical. Label them by their assumptions rather than calling them real segments.
Also test an interrupted session. If a player stops after a delivery, what balance should the next session begin with? If a purchase appears twice in an event export, does the model flag it or count it twice? These questions are partly about data quality. A clear test file should include one deliberately malformed row so the team can see how its workflow handles an error.
Keep the prototype data small
A first model can be a spreadsheet entered by hand. If the team later exports events from a game, define the fields and preserve a copy of the input. The Godot saving-games documentation offers an example of serializing selected game state. An economy review can use a narrower summary containing only the events needed for the question.
Give each test session an arbitrary identifier and omit names or contact details. Keep balances and event order consistent between the game and the model. Before drawing conclusions, reconcile one session by hand: opening balance, total earned, total spent and closing balance. If those four values do not agree, fix the data or formula before interpreting the design.
Turn the result into a playtest question
Invite a small bounded group to play the loop, then observe the first purchase decision. Ask what they wanted next and which available option they noticed. Do they understand the difference between spending now and saving? Can they explain the reward shown after a delivery? Record the choice and the explanation separately. A player may make the predicted purchase for a reason the model never considered.
Do not lead with “Did the fountain feel too expensive?” Ask what they were trying to do when they stopped or chose a decoration. The purpose is to connect the visible arithmetic with the player's experience. If the purchase menu is hard to find, changing reward amounts will not answer that problem. A useful test can redirect the team toward a clearer interface before another economy adjustment.
Leave a decision record for the next update
At the end, save the model version, assumptions, playtest notes and the change the team chose to try. Write down the question still open. That record helps the next designer understand why the current numbers exist. A later update can compare its new scenario with the same baseline instead of rebuilding the reasoning from memory.
A MetaCoins planning tool could make this review easier to repeat, with visible assumptions and exportable comparisons. The working method comes first: one fictional loop, a few clear scenarios, arithmetic that reconciles and a playtest question the team can actually observe. Use the model to choose the next experiment, then let the session show what deserves attention.