EkoSphere
Economy & Progression Design — Full Breakdown
Economy & Progression Design — Full Breakdown
Jump to:
The Economy
•
Design Goals
•
Core Systems
•
Problems Solved
•
My Approach
•
Results
•
Full Project Page
What Is the Economy?
EkoSphere runs on a multi-system, non-monetary economy built around urban resilience. Instead of a single currency like gold or coins, players balance three interdependent resource axes and every decision pulls against all three simultaneously.
Community wellbeing, accessibility, public health
E — Ecological
Biodiversity, water retention, climate resilience
T — Technological
Infrastructure efficiency, energy systems
CORE CONSTRAINTS
Budget Points
→
primary spending limit per round
Intervention Tokens
→
available actions each turn (wetlands, green roofs, etc.)
Turn Progression
→
pacing layer that escalates pressure over time
City State Variables
→
dynamic modifiers shifting costs and outcomes based on prior decisions
The core loop driving every session:
Earn Resources
→
Allocate Budget
→
Place Intervention
→
Update SET Systems
→
Trigger Climate Event
→
Re-evaluate Strategy ↺
Example Decision Impact
Player places a wetland → +Ecological, +Flood resilience, −Available land (indirectly reduces Social and Tech options) → Flood event triggers next turn → outcome depends entirely on prior investment spread
Design Goals
Design Inspiration:
The economy draws from games that use resource constraints to teach real-world thinking rather than reward optimization. Terra Nil showed how placement-based decisions could communicate ecological tradeoffs without text-heavy explanations. Eco demonstrated how interdependent resource systems create genuine community-level tradeoffs. Floodland and IXION both use scarcity and cascading consequences across interconnected systems which is the same logic that underpins EkoSphere's SET model, where no single axis can be maximized without affecting the others.
The economy isn't about optimization, it's built to teach systems thinking. Every constraint is intentional, and every goal pushes against the player's instinct to find "the right answer."
1
Force Tradeoffs
Every decision impacts multiple systems. No move is purely beneficial.
2
Prevent Dominant Strategies
Single-resource stacking (e.g., all-ecological builds) causes cascading problem elsewhere.
3
Simulate Real Complexity
Urban decisions have cascading effects. The economy reflects that.
4
Sustain Decision Pressure
Prevent late-game stagnation where players have accumulated enough to coast.
One hard constraint shaped every decision: the system had to remain readable for non-expert players while still reflecting real-world urban complexity. Elegance became a design requirement.
Core Economy Systems
A. Source / Sink Model
All economy health flows through the balance between sources (inflows) and sinks (outflows). Early versions of EkoSphere had sources consistently outpacing sinks which meant players accumulated resources without meaningful pressure to spend them.
Sources (Inflows)
Passive city output each turn
Intervention effects (green infrastructure bonuses)
Event rewards for successful resilience outcomes
Sinks (Outflows)
Intervention placement costs
Upgrade tiers (long-term investment)
Scaling maintenance costs in late game
B. Multi-Currency Interdependency
Unlike traditional single-currency economies, EkoSphere's S/E/T axes interact continuously. Gains in one area create indirect effects across others; sometimes beneficial, sometimes not.
Cascade Example
Over-investing in Ecology → improves flood resilience → indirectly boosts Social
But: reduces Tech infrastructure → causes problems during heat events
A decision that solves one scenario can quietly break the next.
But: reduces Tech infrastructure → causes problems during heat events
A decision that solves one scenario can quietly break the next.
C. Dynamic Pricing (City-State Driven)
Costs scale with city development stage. This prevents hoarding, encourages early spending, and maintains pressure into the late game.
| City State | Cost Multiplier | Effect |
|---|---|---|
| Early | 1.0x | Accessible entry, encourages experimentation |
| Mid | 1.25x | Decision tension increases, efficiency matters |
| Advanced | 1.5x | Every spend is consequential, no room to hoard |
D. Progression Curve (Upgrade Tiers)
Upgrade costs follow a non-linear curve designed to be accessible early, create meaningful tension mid-game, and act as a significant resource drain late.
| Tier | Cost | Design Purpose |
|---|---|---|
| 1 | 100 | Early accessibility — low barrier to first upgrade |
| 2 | 250 | Mild commitment — players start feeling cost |
| 3 | 600 | Mid-game tension — meaningful choice required |
| 4 | 1,400 | Late-game drain — forces strategic resource management |
Design Problems
During playtesting, three design problems emerged that undermined the economy's core design intent:
Late-Game Inflation
Players accumulated excess resources. Decisions lost weight because scarcity disappeared.
Resource Hoarding
The optimal strategy became waiting. Players delayed spending because there was no cost to doing so.
Pacing Breakdown
Mid-game felt trivial. Late-game had no tension. The progression curve flattened when it should have steepened.
My Approach
Step 1 — Source/Sink Mapping
I mapped all inflows and outflows turn by turn to find where the surplus was accumulating. The data revealed a mid-game surplus that ballooned into late-game inflation.
| Turn | Sources | Sinks | Net |
|---|---|---|---|
| 3 | 120 | 80 | +40 |
| 6 | 200 | 150 | +50 |
| 10 | 350 | 400 | −50 |
Mid-game surplus consistently carried into late game and sinks weren't scaling fast enough to match growing sources.
Step 2 — Excel Scenario Modeling
I built a progression simulation across three player profiles to forecast behavior and catch balance issues before playtesting.
Player Profiles
Conservative — saves resources, defers spending
Balanced — mixes strategies, responds to events
Aggressive — spends immediately, invests early
Model Inputs
Resource generation rates per turn
Intervention costs at each city state
Upgrade thresholds and tier costs
Turn progression and event timing
| Turn | Income | Spend | Net |
|---|---|---|---|
| 5 | 400 | 250 | +150 |
| 10 | 900 | 800 | +100 |
| 15 | 1,500 | 1,600 | −100 |
Key finding: Dedicated players accumulated excess resources early and upgrade costs were not scaling fast enough to absorb mid-game income.
PROBLEM → DESIGN RESPONSE
Late-game inflation
→
Increased late-game sinks and higher-tier upgrade costs
Resource hoarding
→
Dynamic pricing scaling with city state
Pacing breakdown
→
Adjusted conversion rates and progression curve steepness
Step 3 — System Adjustments
Based on the modeling, I made three targeted changes:
1
Increased Late-Game Sinks
Added higher-tier upgrades and introduced scaling maintenance costs that grew with city development. This mirrors how games like Eco handle late-game resource pressure: the cost of maintaining a system should grow with its complexity.
2
Adjusted Conversion Rates
Reduced cross-resource conversion efficiency to slow exponential S/E/T growth and prevent single-axis stacking.
3
Implemented Dynamic Pricing
Costs now scale with city state, eliminating the incentive to hoard and reintroducing spend pressure across all game phases.
Results
22%
reduction in late-game currency inflation
18%
reduction in resource hoarding behavior
5–8%
variance between modeled and live playtest outcomes
BEFORE
Players accumulated excess resources by mid-game
Decisions had low consequence — optimal play was to wait
Late-game felt trivial, progression curve flattened
AFTER
Resource pressure sustained through late game
Players reported spending felt meaningful and consequential
Mid-to-late pacing restored, decision weight maintained
Mid-to-late game decision pressure was restored. Players in post-adjustment playtests consistently reported that spending felt consequential which was the core design goal from the start.
Key Design Takeaways
Inflation is a systems problem
It's not just "too much currency", it's weak sinks, flat progression curves, and static pricing all reinforcing each other. You have to fix the system, not just the numbers.
Multi-system economies need guardrails
Interdependent systems can spiral or collapse into dominant strategies fast. Conversion rate caps and dynamic pricing act as circuit breakers.
Modeling reduces wasted iteration
Even a simple Excel simulation predicted player behavior accurately enough to validate pacing before a single playtest, cutting the number of reactive fixes needed mid-cycle.
← Back to Full EkoSphere Page