# Trace an upgrade through your economy

BerryBlox creator resources
Edition 1.0 · November 5, 2026

Follow earning, spending, and progression with a small calculation sheet and meaningful abuse cases.

Take away: A checkable upgrade path and an ordered list of economy risks.
Intermediate · 8 min read

Original BerryBlox editorial worksheet. You may copy, adapt, and use it in your own projects and team handoffs. Linked sources and third-party materials retain their own terms.

Download this Markdown file and fill it in with any text editor. Your notes stay in your copy; this worksheet does not upload or save them to BerryBlox.

## Name 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](https://create.roblox.com/docs/scripting/security/server-side-detection).

## 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.