Summary
A game’s internal economy is the system of rules governing how resources are produced, consumed, and exchanged. Most games have an internal economy, even if simple; construction and management simulations make the internal economy their central challenge. Understanding the components of an economy allows designers to model, tune, and balance their games’ resource systems deliberately.
(Adams, Fundamentals of Game Design, see source-fundamentals-game-design)
Components
Sources
A source is a mechanic by which a resource enters the game world. Sources may be:
- Automatic: produce at a fixed or variable rate without player action (a river producing fish in The Settlers)
- Player-triggered: the player must build, place, or activate the source
- Limited: can produce only a finite total amount (bank of houses in Monopoly)
- Unlimited: can produce indefinitely (the “Go” square in Monopoly; a river)
- Spawn points: designated locations where enemies, items, or resources appear in a game world
Design requirement: specify the production rate (fixed or variable) and, if limited, the maximum total.
Drains
A drain is a mechanic specifying how resources permanently leave the game world. Examples:
- Firing a weapon drains ammunition
- Enemy attacks drain health points
- Road decay drains structural integrity over time
“Players don’t mind getting money for free, but when they have to spend it, they want to know why. Explain your drains.” — Adams, Ch. 14
Drains should have legible causes — players need to understand why resources disappear.
Converters
A converter changes one or more resource types into another. Design requirements: the conversion rate (input-to-output ratio) and the production speed.
Examples from The Settlers:
- Windmill: grain → flour (1:1, 20 seconds per bag)
- Iron smelter: ore + coal → iron bar (less efficient with charcoal: 3 loads charcoal per bar)
Traders
A trader reassigns ownership of resources without changing them. Distinct from a converter: no resource is created or destroyed, merely transferred.
Design risk — runaway profits: If a player can buy an item and sell it back at a profit indefinitely, they will exploit this. Prevention strategies:
- Require all resales to be for less than the purchase price
- Impose time limits or count limits on transactions
- Give the trader limited funds
- In multiplayer, allow player-to-player trade at profit but not player-to-NPC-trader
Production mechanisms
Any mechanic that gathers or makes resources conveniently available to the player. Includes harvesters (Command & Conquer’s tiberium harvesters), gatherers, and extraction buildings. These are intermediate between sources and the player’s direct control.
Tangible vs. intangible resources
| Type | Properties | Example |
|---|---|---|
| Tangible | Occupies space, requires transport | Ammunition carried by avatar |
| Intangible | No location; cannot be seized | Money in a city-builder |
| Mixed | Tangible during transport, intangible when stored | Food in Age of Empires |
Tangible resources create logistics challenges; intangible resources simplify management. Games choose based on the desired cognitive load.
Feedback loops and deadlocks
Feedback loops in production
A feedback loop occurs when a production mechanism requires some of the resource it produces. As long as the initial supply is sufficient and production exceeds consumption, the loop is stable.
Deadlock: if a feedback loop’s resource runs out, the mechanism cannot produce more of it, and production halts permanently. The Settlers III example: stone is needed to build the stonecutter’s hut; the hut is needed to produce stone. If the player uses all stored stone elsewhere, she enters a deadlock.
“Design Rule: Provide means to break deadlocks. If your internal economy contains feedback loops or mutual dependencies, include a means to break a deadlock if one occurs.” — Adams, Ch. 14
Deadlock-breakers: alternative resource sources; demolishing existing structures to recover raw materials; the $200 for passing “Go” in Monopoly.
Mutual dependencies: two production mechanisms each requiring the other’s output. Another deadlock risk requiring the same solution.
Machinations framework
Joris Dormans’ diagramming language for visualising and simulating internal economies. Inspired by Adams’ earlier editions. Nodes include: pools (resource stores), sources (triangles), drains, and connections (resource connections = solid arrows; state connections = dotted arrows). Available at www.jorisdormans.nl/machinations.
A simple Machinations diagram showing positive feedback: a source connected to a pool, with a state connection feeding back to increase the source’s production rate — producing exponential growth.
Equilibrium
Static equilibrium
Resources flow steadily; amounts do not change significantly over time. Production rate equals consumption rate. Easy for players to understand — changing one variable produces a predictable result.
Dynamic equilibrium
The system cycles — constantly changing, but returning to the same state periodically. Harder for players to manage; difficult to attribute changes to their own actions vs. the natural cycle.
Growth as the player’s challenge
In most games, equilibrium — static or dynamic — removes pressure. Meaningful play requires the player to produce growth: the system should not grow beneficially on its own. The player must act to prevent resources from running out or to expand production. This is the primary challenge in construction and management simulations.
Economic failure modes (Sellers)
Sellers (Advanced Game Design, Ch. 10) identifies three systemic failure modes that affect any game economy with exchange or acquisition:
Inflation
Resources enter the economy faster than they are consumed, eroding their purchasing power. As supply grows, each unit of currency buys less — or, with fixed price tables, players accumulate resources they cannot meaningfully spend, removing the economy’s challenge.
Common causes: undertuned source rates; quests or modes that pay out disproportionately; player strategies that exploit efficient farming loops.
Countermeasures: resource sinks (recurring mandatory costs); time-limited resources; dynamic pricing; supply caps.
Stagnation
Resources enter too slowly for meaningful progress. Players cannot afford decisions; the economy becomes a waiting game rather than a strategic challenge. Stagnation is a common first-design failure — intuitions about “how much should this cost” routinely underestimate how much currency players need to feel engaged.
Countermeasures: increase source rates; add free daily resources; provide cheap “gateway” items to give players an early foothold.
Arbitrage
Arbitrage occurs when a player can exploit price differentials between buy and sell prices (or between markets) to generate unlimited wealth at zero risk.
The Habitat case study (Sellers, Ch. 10): In Habitat (Lucasfilm Games, 1986), dolls cost 75 tokens at one vendor and crystal balls cost 75 tokens at another. Both could be sold to the other vendor for 100 tokens, creating an infinite profit loop. One player discovered this and generated unlimited wealth overnight, destroying the in-game economy. The lesson: every buy price and sell price must be checked against every other for circular arbitrage paths before release.
For the full treatment of arbitrage, price boundaries, and market design — including Albion Online’s explicit tier-based pricing model — see progression-and-power-curves.
Progression mechanics (Juul’s distinction)
Game scholar Jesper Juul distinguishes two types of games by how their events are generated:
- Games of emergence: events emerge from the operation of rules — not pre-planned. Chess, Tetris, bridge. The core mechanic generates endless distinct situations.
- Games of progression: contain predefined event sequences; players experience the story in a predetermined order (with possible branching). Most story-driven games. Level designers control progression through space (walls, locked doors, one-way passages), time (triggers, timers), and plot (dialogue engines, branching systems).
Most commercial games combine both: emergent core mechanics within a progression framework.
In practice (Unity/C#)
For small game projects, the internal economy can be implemented as a set of float or int variables representing resources, with methods for sources (AddResource(float amount)), drains (ConsumeResource(float amount)), and converters (Convert(float input) → modifies multiple resource values). Keep economy data in a central GameEconomy MonoBehaviour or ScriptableObject for easy tuning; in Unity, unity-scriptableobjects are the obvious asset-based container for this.
Tuning tip: Separate data from code. Store rates and ratios in data files or ScriptableObjects so they can be adjusted without recompilation.
Currency design in live-service games
Oscar Clark (Games as a Service, see source-games-as-a-service) extends the internal economy framework specifically to F2P and live-service contexts, where the currency system also carries the monetisation layer. Key additions:
Standard vs premium currency duality: Most F2P games implement two currencies — a widely-earned standard currency (gold, coins) and a slowly-earned or purchasable premium currency (gems, crystals). The standard currency provides the satisfaction of earning through play; the premium currency creates an aspirational tier. Clark recommends that premium currencies, where possible, cannot be bought directly — they should be earned through engagement with an option to accelerate via purchased boosters. Experience points are his example of a currency that should never be sold (Clark, Games as a Service, see source-games-as-a-service).
Imbalanced economies as engagement: Clark argues that a perfectly balanced economy — where supply exactly meets demand — produces no motivation. Introducing deliberate imbalance (scarcity in one resource, surplus in another) creates the decision pressure that drives engagement. This is distinct from the Adams/Sellers concern about deadlocks: Clark’s imbalance is intentional and manageable; Adams’ deadlock is an unintended failure state.
Currency sinks in live games: In long-running live-service games, economies inflate over time as veteran players accumulate currency far in excess of what content can absorb. Designed sinks (prestige resets, cosmetic tiers with high costs, social competition for scarce decorative resources) maintain the motivational value of currency. Without active sink design, late-game currency becomes meaningless and the outer loop collapses.
The pay-to-win line: Clark identifies “pay to win” (where purchased currency directly provides competitive advantage) as the primary economy design failure mode in F2P — it simultaneously degrades the experience for non-payers and undermines the long-term value of the game for payers (because the satisfaction of progress is negated by the knowledge that it was purchased). See f2p-monetisation-design for the full treatment including the Freemium Triangle.
Open questions
- The Machinations framework provides a simulation layer for internal economies. At what project size does the overhead of modelling become worthwhile?
- Intangible resources simplify player experience but reduce strategic depth (no logistics). How do designers decide where to draw the line?
- Feedback loop design is often intuitive. Are there systematic methods for identifying deadlock risks before playtesting?
- How does Clark’s imbalanced economy model interact with the Machinations approach? Can Machinations simulate intentional scarcity as a design tool rather than a failure to detect?
Related
- game-balance — Positive feedback loops are a balance consideration; see also drains and difficulty
- progression-and-power-curves — Power curves, inflation/stagnation/arbitrage, and the iron equation
- challenge-types — Economic challenges are one of the eight challenge categories
- mda-framework — Internal economy mechanics produce dynamics; dynamics produce aesthetics
- level-design — Progression mechanics design (space, time, plot)
- prototyping — Economy design is a core mechanic; prototype and test early
- source-fundamentals-game-design
- source-advanced-game-design
- source-games-as-a-service — Clark on dual currency, imbalanced economy, and pay-to-win risks
- f2p-monetisation-design — virtual goods taxonomy and the Freemium Triangle
- player-lifecycle — how economic engagement maps to lifecycle stage
- economy-simulation-queues — lightweight off-screen merchant and stock simulation
- unity-gamemanager-pattern — implementing score, health, lives as a central economy in Unity
- unity-scriptableobjects — storing shared economy tuning data as reusable Unity assets