Trace an upgrade through your economy
Follow earning, spending, and progression with a small calculation sheet and meaningful abuse cases.
A checkable upgrade path and an ordered list of economy risks.
Completed example
Original fictional example. These are filled-in worksheet answers, not evidence of a built or tested game.
Check a fictional basket upgrade before tuning it
- Units and assumptions
- Design assumptions for arithmetic only: one delivery earns 10 tokens; the basket upgrade costs 30 tokens. These are not measured earnings or a balance recommendation.
- Worked calculation
- Starting at 0 tokens with no other spending: three deliveries × 10 tokens = 30 tokens. Buying once leaves 0 tokens. One or two deliveries are insufficient.
- Behavior to verify
- The upgrade changes carry capacity from three fruit to four. Verify that collection, the displayed capacity, and delivery rules agree after purchase.
- Refusal and repetition
- Request the upgrade with 20 tokens, repeat the same request, and reconnect after a successful purchase. Each case needs a recorded authoritative result.
- Open question
- Delivery time and failure rate have not been measured. Do not convert three deliveries into minutes or predict player retention from this example.
Expected resultA transparent cost calculation and an ordered set of economy checks, with assumed values clearly separated from measured play.
Try it in your blank worksheetName the unit and the milestone
Choose one upgrade, unlock, or reset to review. Name its exact event; buying the first upgrade is different from opening an area. Record the starting balance, reward unit, earning action, and cost. Do not combine different currencies into one unexplained number.
Write each assumption beside the calculation. Travel, failed attempts, full storage, and return trips can matter as much as the nominal reward rate. A spreadsheet estimate is a hypothesis to compare with play, not a measured session.
- Milestone / starting state / currency unit
- Reward per successful action / actions per trip
- Action time / travel time / return time
- Upgrade cost / prerequisites / reset effects
Work one transparent example
Calculate net gain per loop, then loops required, then estimated time. Round loop counts up: a player cannot buy with a fraction of a completed loop unless your actual rules support partial redemption. Keep one-time rewards separate from repeatable earning.
Illustrative arithmetic: a loop earns 12 coins, takes 45 seconds, and has no coin cost. With 6 starting coins and a 60-coin upgrade, the shortfall is 54. Ceiling(54 / 12) is 5 loops, or 225 seconds before menus and mistakes. These invented values teach the method; they are not balancing recommendations or measured results.
- Zero or negative net gain is handled explicitly.
- One-time bonuses are not counted every loop.
- Capacity, travel, and prerequisite costs are included.
- Net gain = reward minus loop cost
- Shortfall = max(0, price minus spendable balance)
- Loops = ceiling(shortfall / positive net gain)
- Estimated time = loops × loop duration
- Observed play time / reason for difference
Review what the upgrade really changes
Describe the new behavior in units a player can understand: reach, capacity, rate, or access. Recalculate the same route after the upgrade. Ask whether the next choice is meaningful and whether a cheaper option still has a useful role.
Check a fresh save, a mid-progression save, and a returning save where applicable. Keep reset rules explicit. An attractive curve on paper does not prove that the player understands or enjoys it.
- Before attribute / after attribute / unit
- Route before / route after
- Next milestone and total cost
- Returning-save or reset behavior
- Player understanding question for the next playtest
Follow the authority and refusal paths
Identify the server-side reader and writer for balances, rewards, and ownership. The client may request an action; it should not be trusted to choose the resulting balance or entitlement. Validate context and rate limits before using anomaly signals.
Record expected results for repeated requests, insufficient balance, invalid quantities, interrupted saves, and replayed purchase receipts where commerce applies. Do not use a single unusual earning rate as automatic proof of cheating; legitimate shortcuts and measurement errors are possible.
- A refused purchase changes neither balance nor ownership.
- Duplicate requests do not grant the same reward twice.
- Negative, non-finite, and oversized values are refused.
- Save failures have a documented recovery path.
- Any commerce implementation is checked against current receipt guidance.
- Case / expected state / observed state / evidence
- Server authority location / unresolved risk
Source checked November 5, 2026: Roblox: Server-side detection and consequencing.
Evidence and limits
This is an original calculation and review worksheet. It contains no executable economy, receipt handler, anti-cheat, revenue forecast, or validated balance model. Its example is deliberately fictional. Actual saving, purchase, multiplayer, and abuse behavior require tests in your implementation.
You may copy, adapt, and use this BerryBlox worksheet in your own projects and team handoffs. Roblox documentation retains its own terms; linked guidance supports the authority discussion and does not endorse the example values.