Outcome focus: Created an economy balancing framework that separates progression health from currency hoarding, making pacing, reward pressure, and retention tradeoffs easier to test.
game deveconomy designsystemstelemetryunity
The first economy readout looked healthy until I asked what the currency was doing.
Players were earning. Balances were going up. Upgrade completion looked steady enough. On a dashboard, that can look like engagement. In a game loop, it can also mean the economy has stopped asking players to make choices.
That was the balancing mistake: I treated accumulation as a positive signal before separating earning from spending pressure.
Hippi Kingdom needs the economy to do more than hand out rewards. It has to pace progression, create small decisions, preserve long-term goals, and keep experimentation cheap enough that players are willing to try new strategies. That makes the economy a systems problem, not a spreadsheet problem.
The loop#
The core loop I use for the economy is simple on purpose:
The loop breaks if any part becomes decorative.
If earning is too generous, upgrades become automatic. If sinks are too aggressive, progression feels punitive. If unlocks do not change future play, spending feels cosmetic even when the numbers move. If events distort the main currency permanently, every future balance pass inherits that distortion.
Sources and sinks#
I separate sources and sinks by what behavior they are supposed to create.
| Economy element | Type | Intended behavior | Failure signal |
|---|---|---|---|
| Session completion reward | Source | Finish a normal play session | Players grind shortest session only |
| Streak bonus | Source | Return without requiring perfection | Players feel punished after a missed day |
| Kingdom upgrade | Sink | Commit to long-term progression | Upgrade path becomes mandatory |
| Cosmetic craft | Sink | Spend without power pressure | Nobody spends unless balances overflow |
| Event contribution | Temporary sink | Create short-term goal | Event drains main progression |
| Catch-up reward | Source | Help late or returning players | Veteran players exploit loop |
The artifact here is not the table itself. It is the discipline of tying every economy object to a behavior and a failure signal. If a currency source has no intended behavior, it is probably noise. If a sink has no failure signal, it is hard to tune.
The rejected design#
The rejected design was a single linear upgrade ladder.
It had one advantage: it was easy to explain. Earn currency, buy next upgrade, unlock next thing. That is attractive early because it keeps implementation clean.
The cost is that a linear ladder turns the economy into a queue. Players stop making decisions and start asking how long until the next step. When the only meaningful question is "can I afford the next upgrade," the designer has only two levers: make rewards bigger or costs smaller.
I moved away from that toward parallel upgrade paths:
- production upgrades,
- exploration upgrades,
- cosmetic or expression sinks,
- event-limited goals,
- catch-up mechanics for returning players.
The tradeoff is complexity. Parallel paths require more telemetry, more balance passes, and more explanation in the UI. I accept that because it gives players room to express intent instead of only obeying the next price.
The balancing mistake#
My first balance pass overvalued median balance growth.
The logic seemed reasonable: if median balance is rising, players are earning and staying engaged. But balances can rise because players are excited, or because there is nothing worth buying.
The metric that changed my mind was spend participation.
| Metric | Healthy interpretation | Bad interpretation |
|---|---|---|
| Median balance | Players can afford planned upgrades | Players are hoarding because sinks are weak |
| Spend participation | Players see worthwhile decisions | Players are ignoring economy choices |
| Time to first upgrade | Onboarding pace is clear | New players are blocked or rushed |
| Upgrade path diversity | Multiple strategies are viable | One path is obviously dominant |
| Event spend share | Event is engaging | Event is cannibalizing core progression |
Once I split earning from spending behavior, the balance conversation improved. The question changed from "are players accumulating enough" to "are players making meaningful choices at the intended cadence."
Telemetry readout#
For early tuning, I would track a small dashboard:
cohort: new_players_week_1
median_soft_currency_balance: 420
p75_soft_currency_balance: 980
time_to_first_upgrade_median: 18m
upgrade_completion_rate_day_1: 62%
spend_participation_day_1: 48%
top_upgrade_path_share: 71%
event_spend_share: 9%The exact numbers above are illustrative. The shape is the point.
top_upgrade_path_share is the one I would watch closely. If one path takes 70% or more of early upgrades, the economy may not be offering a real choice. That can be fine if the first path is intentionally tutorialized. It is a problem if the player is supposed to be selecting a strategy.
Tuning rules#
I use three tuning rules before changing reward numbers.
First, decide whether the issue is source pressure or sink value. If players are not spending, increasing rewards does not fix the actual problem.
Second, tune one loop at a time. If the same change adjusts session rewards, upgrade prices, and event costs, the next telemetry readout will be harder to interpret.
Third, preserve a reason to come back that is not only scarcity. A good economy creates anticipation. A bad economy creates anxiety.
Implementation boundary#
In Unity, I want the economy rules to be data-driven but not opaque.
The balance table can live as ScriptableObjects or external data, but the runtime should expose:
- currency source id,
- sink id,
- player cohort,
- pre-spend balance,
- post-spend balance,
- upgrade path,
- session index,
- event id when relevant.
Without those fields, tuning becomes narrative. With them, a designer can ask whether a price change altered behavior or only moved balances.
A balance-change acceptance check#
Before shipping an economy change, I would write down the expected movement.
| Change | Expected signal | Stop condition |
|---|---|---|
| Lower first upgrade cost | Time to first upgrade drops, day-one spend participation rises | Top path share climbs too high |
| Add cosmetic sink | High-balance players spend without slowing core upgrades | New players delay first power upgrade |
| Increase event rewards | Event participation rises | Core progression becomes less attractive |
| Add catch-up grant | Returning players re-enter loop | Active players exploit grant timing |
The stop condition matters. Without it, every balance change can be defended after the fact. A designer can always tell a story about why a number moved. The acceptance check makes the story testable before the patch ships.
This is also where game design starts to look like product analytics. The metric is not the design. The metric is the argument you agree to have with yourself after players touch the system.
What to do differently#
Do not call an economy healthy because balances are rising.
Balances are inventory. The design question is whether inventory creates interesting future decisions. Hippi Kingdom needs the economy to pace progress, invite strategy, and keep the kingdom feeling alive. That requires sinks, sources, telemetry, and rejected designs that are all tied back to the loop.