Currencies, sinks and prices: an economy players understand

Sources and sinks

The whole model in two words. Sources create currency, sinks remove it, and the relationship between them decides whether your economy is stable, inflating or starving.

• Sources are everything that pays out: quest rewards, drops, selling, daily bonuses, the bonus for a good run.
• Sinks are everything that consumes: purchases, upgrades, repairs, crafting costs, entry fees, respecs.
• Inflation happens when sources outpace sinks. Players accumulate, prices lose meaning, and rewards stop feeling like rewards.
• Starvation happens the other way, and it reads as grind.
• Sinks stop working when the player has bought everything. That moment arrives for every player who stays, and it is the point where late-game economies quietly die.
• One-time sinks are not sinks. A one-off purchase drains once; a repeatable cost keeps working, which is why consumables, repairs and entry fees exist.

The practical version: for every source you add, name the sink that absorbs it. If you cannot, you have added inflation with extra steps.

How many currencies

The answer is the number of genuinely separate decisions you want the player to make, which is almost always fewer than the number a game ends up with.

• The merge test: if two currencies are earned from similar activities and spent on similar things, they are one currency wearing two hats.
• Every currency needs its own visual identity, in shape as well as colour, used identically everywhere.
• Event currencies must expire visibly, with a warning, or they become a trust problem when they vanish.
• Never make players do conversion maths. If a conversion exists, show the result before they commit.
• Premium currency is a separate discussion, and mostly a trust one, covered in monetisation UI.

Pricing that reads

Prices communicate value long before they balance anything. Players learn your economy from the first four or five prices they see, and everything after that is judged against those anchors.

1. Set the anchor deliberately. The first meaningful purchase teaches what a unit of currency is worth. Pick it rather than letting it be whatever the tutorial hands out.
2. Round to numbers people can hold. 250, 500, 1000. A price of 1,847 is not more balanced, it is less usable.
3. Keep ratios legible. If a good sword is roughly ten times a potion, players can plan. If it is 7.3 times, they cannot.
4. Price by what it is worth to the player, not by what it cost you to make.
5. Show the earn rate somewhere. A player who knows a run pays about 200 can evaluate a 1000 price. Without that, every price is meaningless.
6. Beware of pricing in time. Players convert prices into hours whether or not you want them to, and a price that reads as "six hours" is a decision about your game's pacing.

Numbers players can feel

The same rule as everywhere else in game interface: precision only where a decision needs it.

• Show the balance where it is spent, in the same position on every screen that can spend it.
• Show the cost at the decision point, not on the previous screen.
• Show what is left afterwards, on the confirmation. It is the number players are actually calculating.
• Mark what is affordable now, so the shop can be scanned rather than read.
• Show progress towards the thing they want. "240 of 500" turns a price into a goal.
• Abbreviate large numbers consistently and never in a way that hides an order of magnitude.

Sinks that are not shops

Teams reach for a shop by default, and shops are the least interesting sink available. These tend to work better, and they are cheaper to build.

Where economies break

1. Hoarding. Players save for something and never spend, usually because the best purchase is unclear or because they fear regret. A refund or respec option releases more currency than any balance change.
2. The dead currency. One that accumulates with nothing worth buying. Every player notices, and it makes the whole economy feel unfinished.
3. The cap. Hitting a maximum with no warning wastes earnings and reads as disrespect. Warn before the cap, and consider converting the overflow.
4. The last item. The moment a player owns everything, all sources become meaningless. Have an answer ready before your most engaged players arrive there.
5. The grind wall. A price so far beyond the earn rate that players calculate the hours and stop. Check your worst ratio.
6. Trading and duplication exploits, in anything with player-to-player transfer, which is an economy design problem long before it is a security one.

Players will tell you a price is unfair. What they mean, almost always, is that they could not tell what it would take to afford it.

Showing the economy

Everything above lands, or fails to, on four surfaces. These are the screens I would design first on any game with an economy.

• The persistent balance, in a fixed position, on every screen where spending is possible.
• The shop or upgrade screen, where affordability is visible at a glance and comparison is built in, per progression design.
• The confirmation, restating item, cost and remaining balance, with two verbs rather than Yes and No, per UX writing.
• The earn moment, showing what was gained and where it went, at the moment it happens rather than in a later summary.

An economy audit

1. List every source and every sink on one page. Are there sinks for each source?
2. Count your currencies. For each, name the decision it forces that no other currency does.
3. Play for an hour and record everything you earned. Divide your most expensive item by that rate.
4. Open the shop at hour one and hour ten. Is anything affordable at both?
5. Find the cheapest item nobody buys and ask why it exists.
6. Check what happens at the currency cap, and whether players are warned.
7. Check what a player who owns everything sees.
8. Read your five most common prices aloud. Are they numbers a person can hold?
9. Ask a playtester what a run is worth in currency. If they do not know, your earn rate is invisible.
10. Check the confirmation screen states the balance after purchase.