Economy Design - Deep Dive

Sink/Faucet Modeling

Step 1: Map the flow

Create a directed graph of every resource in the game:

[Quest Rewards] ---> [Player Gold] ---> [NPC Shop]
[Monster Drops] ---> [Player Gold] ---> [Crafting Costs]
[Daily Login]   ---> [Player Gold] ---> [Repair Bills]
[Trading]       <--> [Player Gold] <--> [Auction House Tax]

Every arrow INTO the player stock is a faucet. Every arrow OUT is a sink. Bidirectional arrows (trading) create secondary flows that need their own sinks.

Step 2: Quantify hourly rates

For each faucet and sink, estimate the per-hour flow for three player archetypes:

Red flag: If hardcore earners accumulate 3x+ faster than they spend, you need progressive sinks (higher repair costs at higher levels, luxury cosmetics, prestige resets that cost currency).

Step 3: Model over time

Simulate 100 hours of play for each archetype. Plot cumulative stock over time. A healthy economy shows:

• Casual: slow but steady growth, can afford core items by midgame
• Median: comfortable growth, occasional saving for big purchases
• Hardcore: fast growth but with meaningful endgame sinks that prevent hoarding

Inflation prevention

Bounded currencies: Cap how much a player can hold (e.g., 999,999 gold). This is a blunt instrument but prevents extreme outliers.

Decay mechanics: Resources lose value over time (food spoils, gear degrades). Adds realism but players may find it punishing. Use sparingly.

Progressive taxation: Auction house fees scale with transaction value. A 5% fee on small trades, 15% on large trades. This drains more from wealthy players.

Money sinks disguised as content: Cosmetic housing, mount breeding, guild upgrades - these are optional sinks that players choose to engage with. Most effective because they feel rewarding, not punitive.

Multiplayer Market Dynamics

Player-driven economies

When players can trade freely, you lose direct control over pricing. Instead, you control:

1. Supply - Drop rates determine how many items enter the economy
2. Demand - Crafting recipes and gear requirements determine consumption
3. Transaction costs - Auction house fees remove currency from circulation
4. Item lifetime - Durability, binding-on-equip, and seasonal resets control item supply over time

Common multiplayer economy problems

Bot farming: Automated players generate resources 24/7, causing massive inflation. Mitigation: daily earn caps, CAPTCHA-like mechanics for farming activities, diminishing returns on repeated content.

Market manipulation: Wealthy players buy out all stock of an item to corner the market. Mitigation: price ceilings on essential items, NPC vendors as price anchors, limiting stack purchases.

New player gap: Veterans have millions; new players have nothing. The economy prices items at veteran levels, making early game unplayable. Mitigation: level- bracketed markets, starter-bound items, catch-up mechanics that give new players accelerated earning.

Dual currency systems

Most successful F2P games use two currencies:

Critical rule: Never let hard currency buy power that soft currency cannot eventually also buy. The conversion should be time, not exclusivity.

Exchange rate management

If players can convert between soft and hard currency:

• Fixed rate (developer-set): Simple but may not reflect actual value
• Market rate (player-driven): Flexible but volatile
• Hybrid (developer floor/ceiling, market between): Best of both worlds

Set the floor at 80% of your target rate and the ceiling at 120%. This prevents extreme manipulation while allowing organic price discovery.

Economy Health Metrics

Track these weekly for live games:

Playtesting Guide - Deep Dive

How to Run a Balance Playtest

Playtest types

Pre-playtest checklist

• Define the specific balance question being tested (e.g., "Is the level 10 boss too hard?")
• Instrument all relevant metrics (see metrics section below)
• Prepare a control group if doing A/B testing
• Write down your prediction before the test (prevents confirmation bias)
• Set success/failure criteria in advance (e.g., "Pass if 65-80% of testers complete it")
• Recruit testers matching your target audience skill level
• Prepare a post-session questionnaire (max 5 questions)

During the playtest

Observe without interfering. Do not coach, hint, or explain. If a tester is confused, that IS the data point. Note:

• Where they pause or hesitate
• Where they express frustration (verbal, facial, body language)
• Where they express delight or surprise
• Any strategies they discover that you didn't intend
• How long each section takes

Post-session questions (template)

1. "What was the hardest part?" (open-ended, no prompting)
2. "Did you ever feel stuck? Where?" (identifies difficulty spikes)
3. "Did anything feel too easy or pointless?" (identifies trivial content)
4. "How did you feel about the rewards you received?" (economy feedback)
5. "Would you keep playing? Why or why not?" (retention signal)

What Metrics to Track

Core balance metrics

Instrument these from day one:

Per-level/encounter:

- completion_rate: % of players who finish
- attempt_count: average attempts before completion
- time_to_complete: median seconds
- death_count: average deaths per attempt
- health_remaining: % HP left on completion (for combat)
- items_used: consumables burned per attempt

Per-session:

- session_length: minutes played
- content_progressed: levels/quests completed
- resources_earned: currency and items gained
- resources_spent: currency and items consumed
- net_resource_change: earned minus spent

Per-player (longitudinal):

- total_playtime: cumulative hours
- current_level: progression status
- total_currency: economic stockpile
- churn_point: last content completed before quitting
- return_rate: % chance of playing again within 7 days

Derived metrics

Difficulty index = 1 - completion_rate. Values above 0.4 indicate a problem for required content. Optional content can go up to 0.7.

Economy velocity = resources_spent / resources_earned. Healthy range is 0.6-0.85. Below 0.5 means players are hoarding. Above 0.9 means they feel poor.

Engagement slope = session_length[this_week] / session_length[last_week]. Below 0.8 means engagement is dropping fast. Above 1.0 means the game is gaining momentum.

Power-to-content ratio = player_power_level / recommended_content_level. At 1.0, content is matched. Below 0.9, player is undergeared. Above 1.2, content is trivially easy.

Statistical Significance for Small Samples

Game playtests often have small sample sizes. Use these guidelines:

Minimum sample sizes for confidence

When you can NOT draw conclusions

• Fewer than 5 testers and all succeeded: You cannot claim the content is balanced. You can only say "we found no obvious breaks."
• One tester struggled but others didn't: This is signal, not proof. Note it and watch for the pattern in future tests.
• Testers are all from the dev team: Internal testers are 2-5x more skilled than the median player.

Quick significance check

For completion rate tests with small samples, use this rule of thumb:

If N testers attempt a level and K complete it:

• K/N > 0.8 and N >= 8: Probably fine for required content
• K/N between 0.5-0.8 and N >= 10: Borderline, likely needs tuning
• K/N < 0.5 and N >= 5: Almost certainly too hard

For more rigorous analysis, use a binomial confidence interval. With 10 testers and 7 completions, the 95% confidence interval for true completion rate is approximately 35-93%. This is why small samples are tricky - you need more data to narrow the range.

Interpreting Results

The balance interpretation framework

For each metric that's outside healthy range, ask:

1. Is this a skill problem or a design problem?

   • Skill: Players don't know what to do (add tutorials, hints)
   • Design: Players know what to do but can't (tune numbers)

2. Is this affecting the median or the tails?

   • Median affected: Core balance issue, must fix
   • Only tails affected: Add difficulty options, don't change core

3. Is the fix additive or subtractive?

   • Prefer additive (buff the weak path, add a new tool for players)
   • Avoid subtractive (nerfing feels bad, removing options feels worse)

Common playtest findings and responses

The balance change process

1. Identify the problem metric
2. Hypothesize the cause (one specific thing)
3. Propose a single parameter change (10-20% adjustment)
4. Predict the expected metric change before implementing
5. Implement the change
6. Playtest again with same methodology
7. Compare actual vs predicted result
8. If prediction was wrong, re-hypothesize (don't just try a bigger change)

Repeat until the metric is within healthy range. Never skip step 4 - predicting forces you to understand the system, not just react to symptoms.

Progression Formulas - Deep Dive

XP Curve Formulas

Standard exponential curve

xp_required(level) = base_xp * level ^ exponent

Parameters:

• base_xp: XP for level 1. Determines the pace of early game. Typical: 50-200.
• exponent: Controls curve steepness. Typical range: 1.5-2.5.

Cumulative XP (total XP from level 1 to N):

total_xp(N) = sum(base_xp * i^exponent for i in 1..N)

For quick estimation: total_xp(N) ~= base_xp * N^(exponent+1) / (exponent+1)

Worked example: 50-level RPG

Parameters: base_xp=100, exponent=1.8, earn_rate=200 XP/hr at midgame

Analysis: Level 50 takes ~400 hours. For a hardcore MMO, this is reasonable (~6 months at 2hr/day). For a casual game, this is too long - reduce exponent to 1.5 or add catch-up mechanics.

Alternative curves

Fibonacci-style: Each level requires the sum of the previous two levels' XP. Creates a naturally accelerating curve that feels organic.

xp(1) = base
xp(2) = base
xp(n) = xp(n-1) + xp(n-2)

Stepped: XP requirements jump at tier boundaries (every 10 levels) but are flat within a tier. Good for games with clear "chapter" boundaries.

xp(level) = tier_base[floor(level/10)] * (1 + (level % 10) * 0.1)

Logarithmic (inverted): Early levels are hard, later levels are easier. Rare but useful for "mastery" systems where early learning is the bottleneck.

xp(level) = base * log(level + 1) / log(2)

Power Scaling

Stat growth formulas

Player stats (HP, attack, defense) should grow in a way that maintains the challenge delta against enemies. Common approaches:

Linear growth (simple):

stat(level) = base_stat + (growth_per_level * level)

Easy to balance but feels flat at high levels.

Compound growth (percentage-based):

stat(level) = base_stat * (1 + growth_rate) ^ level

Growth_rate of 0.03-0.08 (3-8% per level) is typical. Creates exponential curves that feel rewarding but require exponential enemy scaling to match.

Diminishing returns (soft cap):

stat(level) = max_stat * (1 - e^(-growth_rate * level))

Approaches a maximum asymptotically. Good for stats that should cap out (crit chance, cooldown reduction) to prevent game-breaking values.

Enemy scaling strategies

Fixed scaling: Each enemy has set stats. Players outlevel them and feel powerful. Good for linear games with no backtracking.

Level-matched scaling: Enemies scale to player level. Maintains challenge but can feel like the player never progresses. Use sparingly - only for specific "challenge" zones.

Bracket scaling: Enemies have a level range (e.g., goblin: level 3-7). Within that range, they scale. Outside it, they're fixed. Best of both worlds.

Recommended formula for bracket scaling:

enemy_stat(player_level) = base_stat * clamp(player_level / enemy_center_level, 0.7, 1.3)

This keeps enemies within 70-130% of their intended difficulty relative to the player's level.

Prestige / Reset Loop Design

When to add prestige

Add a prestige/rebirth/new-game-plus system when:

• The main progression has a natural endpoint (max level reached)
• You want to extend game lifetime without adding new content
• Players enjoy optimizing and min-maxing

Prestige reward scaling

Each prestige cycle should offer a permanent bonus that makes the next cycle faster. Typical structure:

Critical rule: The time savings should be meaningful but never trivial. If prestige 10 takes less than 10% of the original time, you've made it too fast and players will feel the loop is pointless.

Target: Each prestige should reduce cycle time by 15-25%. Diminishing returns should kick in around prestige 5-7 to prevent infinite acceleration.

Prestige cost design

What the player sacrifices on prestige:

• Full reset (harsh): Lose all levels, items, currency. Only keep prestige bonuses. High stakes, high reward feeling.
• Partial reset (moderate): Keep key unlocks (recipes, achievements) but lose levels and consumables. Most common choice.
• Soft reset (gentle): Keep almost everything, gain a small permanent bonus. Low stakes, good for casual audiences.

Skill Tree Balancing

Node costing

Each node in a skill tree should cost points proportional to its power:

node_cost = base_cost * power_tier_multiplier * depth_multiplier

Where:

• power_tier_multiplier: 1.0 (minor), 1.5 (moderate), 2.5 (major), 4.0 (capstone)
• depth_multiplier: 1.0 + (0.2 * distance_from_root)

Path balance validation

No single path through a skill tree should be more than 15% stronger than alternatives at equivalent point investment. Test by:

1. Calculate total DPS/effectiveness for each complete path
2. Normalize to points spent
3. If any path exceeds the mean by >15%, reduce its strongest node or buff competing paths

Respec economics

Always allow respecs. The cost should be:

• Free for the first 3 respecs (experimentation phase)
• Scaling cost afterward: respec_cost = base * 2^(respec_count - 3)
• Hard cap the cost at a value achievable in 1-2 hours of play
• Optional: free respec on major patches that change balance