DEV Community: Hiroshi TK

How to Build a Reward Economy for a Mobile Game

Hiroshi TK — Mon, 01 Jun 2026 09:34:45 +0000

Rewards are the language mobile games use to talk to players. Every coin drop, every chest, every daily login bonus is the game saying: "You did something. Here's what you get." Get that language right and players feel seen, motivated, and loyal. Get it wrong and rewards feel arbitrary, cheap, or manipulative — and players leave.

Building a reward economy for a mobile game means designing every reward type, what it gives, when it appears, and how it connects to the larger economy. This guide walks through the full reward stack: daily rewards, missions, battle pass rewards, level rewards, ad rewards, gacha, and event rewards — and how to build them into a coherent system.

Key Takeaways

A mobile reward economy is the complete system of reward types in a game — how they're structured, timed, and connected.
Each reward type serves a specific behavioral purpose: driving return visits, rewarding skill, monetizing attention, or sustaining long-term engagement.
Reward types need to be balanced against each other — stacking too many high-value rewards devalues all of them.
The reward schedule (when and how often players receive rewards) matters as much as the reward value.
Simulate your reward economy before shipping — reward cadence problems are invisible in static math.

What Is a Mobile Reward Economy?

A reward economy is the network of all reward systems in a game — the sources of positive feedback that players receive for taking actions. It includes everything from a coin drop at the end of a level to a monthly milestone reward to the item pulled from a gacha banner.

The reward economy is distinct from the currency economy, though they're closely linked. The currency economy is the system of what currencies exist and how they're balanced. The reward economy is the system of delivery — how players receive value, when, and in response to what behavior.

Designing the reward economy means answering: for every moment a player does something in your game, what do they get? And does what they get feel proportional, motivating, and consistent with the overall design intent?

The 7 Core Reward Types in Mobile Games

1. Daily Rewards (Login Rewards)

What they are: Resources given to players simply for opening the game each day. Usually on a rotating schedule — day 1 gives coins, day 3 gives a small gem amount, day 7 gives something more valuable.

What they're for: Driving daily return visits. The reward is the reason to open the game on days when the player wasn't otherwise planning to.

Design rules:

The day 7 (or end-of-cycle) reward should be meaningfully better than day 1. Players should feel the streak is worth maintaining.
Don't reset the streak to zero on a miss — forgiveness mechanics (skip one day and continue) dramatically improve the behavioral outcome.
The daily reward should not be so valuable that it substitutes for gameplay rewards. It's an invitation, not the main course.

2. Mission and Quest Rewards

What they are: Resources earned for completing specific tasks. Daily missions, weekly challenges, achievement systems.

What they're for: Directing player behavior. Missions are how you get players to try mechanics they might otherwise ignore, engage with content they'd skip, and come back for specific sessions.

Design rules:

Missions should feel achievable in a single session for daily tasks, and in 2–3 sessions for weekly tasks.
Mission rewards should be meaningfully higher than passive earn rates — if completing a mission gives the same as just playing normally, there's no incentive to follow the mission.
Variety matters. Missions that always point at the same activity become invisible.

3. Battle Pass Rewards

What they are: Tiered rewards unlocked by earning XP through gameplay over a season. Usually split into a free track (available to all players) and a premium track (unlocked by purchase).

What they're for: Long-term engagement anchor. The battle pass is the reason a player comes back every day for six weeks. It's the highest-leverage retention mechanic in modern mobile game design.

Design rules:

The free track should feel genuinely rewarding — not a demo. Players who don't pay should still want to complete it.
Premium track rewards should feel clearly better than free track, but the free track shouldn't feel like punishment for not paying.
Reward pacing matters enormously. Big rewards clustered only at the end create the wrong motivation shape — spread high-value rewards throughout the track.
Simulate your XP pacing across casual, mid-core, and power player profiles. A battle pass that only completable for players who play 90+ minutes daily is a design problem.

4. Level Rewards

What they are: One-time rewards for reaching a specific player level or account milestone.

What they're for: Celebrating progress. Level rewards punctuate the progression curve — they're the exclamation marks that make leveling feel significant.

Design rules:

Level rewards at early levels should be frequent and exciting — the early game should feel like constant reward.
Major level thresholds (level 10, 25, 50) should have noticeably better rewards that feel like they mark a genuine milestone.
Don't let level rewards become entirely predictable. A surprise high-value reward at a non-obvious level (level 23, not 25) creates delight.

5. Ad Rewards (Rewarded Video)

What they are: Optional rewards — usually a currency bonus, extra life, or speed boost — given in exchange for watching a short advertisement.

What they're for: Soft monetization and session extension. Rewarded ads let non-paying players access small amounts of value in exchange for attention, while generating ad revenue.

Design rules:

Ad rewards should feel optional, not mandatory. If the game requires watching ads to stay competitive, it's coercive — which damages long-term trust.
The ad reward value should be lower than an equivalent IAP value. Players who pay should feel their money was worth more than watching videos.
Offer limits (e.g., 5 rewarded ads per day) prevent ad rewards from substituting for premium currency in ways that undermine monetization.

6. Gacha Rewards

What they are: Randomized rewards from a pull mechanic — spending currency (keys, crystals, gems) to receive a random item from a pool.

What they're for: High-engagement acquisition of rare items. Gacha systems are the primary source of rare or powerful items in many F2P games, and a significant monetization driver.

Design rules:

Publish drop rates. This is both ethically correct and increasingly required by platform policies in many markets.
Implement a pity system. After a defined number of pulls without a rare drop, guarantee one. This protects players from extreme bad luck and makes the expected value feel trustworthy.
The currency cost of pulls should feel within reach for free players — occasionally. If free players can never meaningfully engage with the gacha, it becomes purely a whale feature and loses the aspirational pull for the broader player base.
Avoid duplicate traps without a conversion system. Getting the same rare item 5 times with no way to convert duplicates is a trust-destroying experience.

7. Event Rewards

What they are: Rewards earned during limited-time events — seasonal content, tournaments, special missions.

What they're for: Re-engaging lapsed players, driving high-activity windows, and creating the sense that the game is alive and changing.

Design rules:

Event rewards should include at least one item or currency type that's exclusive to the event — this is what creates FOMO-driven return.
Event reward volume needs to be scoped carefully. Events that inject large amounts of currency without commensurate sinks cause post-event inflation.
Event reward pacing should account for varying player availability. A player who can only play on weekends should still be able to earn meaningful event rewards.

Building a Coherent Reward Stack

The individual reward types above need to work together as a system. Here's what a coherent stack looks like in practice:

Daily rewards bring players into the session.

Mission rewards direct what they do in the session.

Session rewards (level rewards, gameplay drops) make the session feel productive.

Battle pass gives them a long-term goal that spans the season.

Gacha gives them something to aspire to and occasionally spend on.

Events give them a reason to come back during otherwise quiet periods.

The failure mode is reward cannibalization — when too many reward systems fire at once, the value of each individual reward drops. If players are getting coins from daily login, missions, level completion, a pop-up ad offer, and a bonus event simultaneously, the coins feel like background noise rather than meaningful reward.

The fix: think about the reward schedule as a whole. What rewards appear in what sessions? What's the total reward value per session? Is there enough variation — and enough silence — between reward peaks for the peaks to feel meaningful?

Reward Economy and Monetization

Every reward type has a relationship with monetization:

Reward type	Monetization relationship
Daily reward	Minimal — supports retention, not direct spend
Mission reward	Indirect — drives engagement that leads to spend
Battle pass	Direct — premium track is a purchase
Level reward	Minimal — supports retention
Ad reward	Revenue from ad impressions; reduces premium spend pressure
Gacha	Direct — premium currency spend driver
Event reward	Mixed — exclusive rewards drive FOMO-based purchases

Balancing the reward economy with monetization means making sure rewards feel generous enough to build trust without being so generous that they remove purchase motivation.

Simulate Your Reward Economy

Reward economies are hard to balance in static math because the feel of a reward is contextual — it depends on when it appears, how often, and what the player expects. A 100-coin reward feels great on day 1 and meaningless by day 30 when players have 50,000 coins in reserve.

itembase lets you model your full reward economy and simulate how it feels across the player lifecycle — identifying where reward cadence goes thin, where currency accumulates beyond useful levels, and where the battle pass XP pacing goes wrong for different player profiles.

Try itembase → itembase.dev

Frequently Asked Questions

What is a mobile game reward economy?

A mobile game reward economy is the complete system of reward types — daily logins, missions, battle pass tiers, level rewards, ad rewards, gacha pulls, and event rewards — that defines how players receive value from the game. It encompasses what rewards exist, what they give, when they appear, and how they work together as a retention and monetization system.

How do you design a daily reward system for a mobile game?

Daily reward systems should offer escalating value across the reward cycle (day 7 meaningfully better than day 1), include streak forgiveness to prevent single misses from resetting progress, and be valuable enough to motivate a return visit without replacing gameplay-earned rewards.

What is a gacha pity system?

A pity system guarantees a rare reward after a set number of pulls without receiving one. For example, if a player makes 90 pulls without a 5-star item, the 90th pull guarantees a 5-star. Pity systems protect players from extreme bad luck, make the economics of gacha feel trustworthy, and are increasingly standard practice in ethical F2P design.

How do battle pass rewards work?

Battle pass rewards are unlocked by earning XP through gameplay over a season. A free track is available to all players; a premium track requires purchase. Reward pacing — how quickly players earn XP and how rewards are distributed across tiers — is critical to the retention value of a battle pass.

How do event rewards affect a game economy?

Event rewards inject currency and items at a higher-than-baseline rate during a limited time window. Without adequate sinks, this causes post-event inflation — players have more currency than they can spend, and the value of that currency drops. Event reward design needs to include event-specific sinks (exclusive items, limited exchanges) to contain the economic impact.

Build a Reward Economy That Keeps Players Coming Back

Model and simulate your mobile game reward economy in itembase → itembase.dev

Game Economy Simulator: Why You Should Simulate Before You Ship

Hiroshi TK — Fri, 29 May 2026 07:03:04 +0000

Every game designer has shipped something that looked balanced on paper and broke in production. The math checked out. The spreadsheet said players would earn roughly what they spent. Then real players got into the game and the economy fell apart in a way nobody anticipated.

This isn't a design failure. It's a tooling failure. The spreadsheet was never capable of catching what went wrong — because what went wrong wasn't a math error. It was a behavioral dynamic that only shows up when you model players moving through the economy over time.

That's what a game economy simulator does. This article explains what economy simulation is, what it catches, and why it should be a standard step in your design process — not an afterthought.

Key Takeaways

A game economy simulator models how player behavior interacts with your economy over time — not just what the numbers say in theory.
Simulation catches four major problem classes: broken progression, inflation, reward imbalance, and content exhaustion.
These problems are expensive to fix after launch and cheap to fix in design.
Spreadsheets calculate. Simulators simulate. Both are useful; only one validates behavioral dynamics.
itembase is a game economy simulator built for F2P, mobile, and live service game designers.

What Is a Game Economy Simulator?

A game economy simulator is a tool that models how a game's economy behaves when players move through it — not just how it's structured on paper.

The difference from a spreadsheet: a spreadsheet gives you static values. It tells you the expected value of a chest, the cost of an upgrade, the daily earn rate assuming one session. It doesn't model variance. It doesn't account for players who play more or less than average. It doesn't show you what happens to currency supply after 10,000 players complete week 3 of your battle pass.

A simulator takes your economy design — currencies, earn rates, costs, drop probabilities, progression gates — and runs it forward through time with modeled player behavior. The output isn't a single number. It's a picture of how the economy evolves: where currency accumulates, where players get stuck, where rewards feel too thin, where progression deserts form.

What Simulation Catches That Math Misses

Broken Progression

The most common economy failure. A point in the game where upgrade costs escalate faster than earn rates, and players hit a wall.

On paper, it's invisible. Your spreadsheet shows the upgrade costs and the earn rates in separate columns, and both look reasonable in isolation. What the spreadsheet doesn't show: that a player earning at the mid-game rate would need to play for 12 days straight to afford the next upgrade — and that by day 4, they've already churned.

A simulator shows you this. Run a 30-day player simulation at your target session frequency and you'll see exactly where the earn curve and cost curve diverge. That's the cliff. Fix it before it ships.

Inflation

Inflation happens when sources produce more currency than sinks consume. Players accumulate, prices feel meaningless, monetization collapses because there's nothing left that feels worth paying for.

The tricky part about inflation: it's time-dependent. Your economy might be perfectly balanced for the first two weeks and inflate badly in week 4, once high-engagement players have completed all the primary sinks and are still earning passively. A spreadsheet with static assumptions won't catch this. A simulation that runs player behavior for 60+ days will.

Reward Imbalance

Your session rewards feel thin. Or your gacha feels terrible. Or your battle pass feels padded. These are perceptual problems — they're not about whether the numbers add up, they're about whether the rewards feel right relative to player effort.

Simulation surfaces reward imbalance by modeling the reward history of a player over time. If a player completes 50 sessions and the distribution of meaningful rewards is clustered in the first 10 and nearly absent in sessions 20–50, the reward cadence is broken even if the total value is technically correct.

Content Exhaustion

You designed your battle pass to last 6 weeks. Your simulator tells you that a player who plays 45 minutes per day completes it in 3 weeks. You have a content exhaustion problem — and it would have shown up in your live game as a spike in churn around week 3 followed by a sharp drop in battle pass conversion for the next season.

Content exhaustion is particularly dangerous in live games because it compounds: once players learn they can exhaust your season content quickly, they start timing their engagement to avoid the dead period, which shows up as activity spikes at launch and steep drop-offs after.

Why Post-Launch Analytics Isn't the Answer

The obvious question: why simulate before launch when you can just look at analytics after?

Two reasons.

Cost. Fixing an economy problem in design takes hours. Fixing it in a live game takes an update cycle, player communication, potential rollback, and damage control for the players who already experienced the broken version. The later you find the problem, the more expensive it is.

Trust. Economy problems erode player trust in ways that are hard to reverse. Inflation that made your premium currency feel worthless. A broken gacha run that felt exploitative. A battle pass that turned out to take twice as long to complete as advertised. Players who experience these don't just churn — they leave reviews, post in communities, and poison organic acquisition.

Analytics is essential for post-launch tuning. It is not a substitute for pre-launch validation. You want both.

What a Game Economy Simulation Looks Like in Practice

Here's a simplified example. You're designing the first season of a battle pass for a mobile RPG.

Your design specs:

50 tiers
Players earn XP from daily quests (200 XP/day) and matches (50 XP per match, ~5 matches/day)
Total daily XP for average player: ~450
XP per tier: 1,000
Season length: 6 weeks (42 days)
At average earn rate: 42 days × 450 XP = 18,900 XP = 18.9 tiers completed

Wait — players only complete 18 out of 50 tiers on your "average" earn rate? That's a problem. Tier 50 is supposed to feel achievable for engaged players, not just whales.

You run a simulation with three player profiles:

Casual: 1 session/day, 3 matches → 350 XP/day → 14 tiers in 6 weeks
Mid-core: 2 sessions/day, 6 matches → 650 XP/day → 27 tiers in 6 weeks
Power: 4 sessions/day, 12 matches → 1,100 XP/day → 46 tiers in 6 weeks

Now you can see the full picture. The power player nearly completes the pass. The mid-core player doesn't get halfway. The casual player gets less than a third. Is that what you intended? Probably not — you need to either reduce the total tier count, increase the XP earn rate, add bonus XP sources, or accept that the full pass is designed for power players only and price the premium track accordingly.

That's simulation in practice. You found the problem in the design phase, not in the post-launch analytics dashboard.

Who Should Use a Game Economy Simulator

F2P mobile game designers. This is the primary use case. Any game with soft currency, hard currency, energy, progression gates, or monetization mechanics benefits from simulation before launch.

Idle and clicker game designers. Idle economies grow exponentially and break in ways that are nearly impossible to predict without simulation. Prestige loops, inflation, bottlenecks — simulation is close to mandatory here.

Battle pass designers. Season length, XP pacing, reward density — all of these need to be validated against realistic player behavior before the season launches.

Gacha designers. Pull rate probabilities, pity system behavior, currency earn rate vs pull rate ratio — the math of gacha is deceptive. Simulation at percentile extremes (the unlucky 10% of players) often reveals problems the expected value calculation hides.

LiveOps designers. Before any significant event, balance change, or bundle launch — simulating the economy impact prevents the surprises that show up in next week's dashboard.

itembase: A Game Economy Simulator for Designers

itembase is a game economy design and simulation platform built specifically for game designers — not data scientists or engineers.

It's designed around the way game economies actually work: items, currencies, progression systems, events, player behavior profiles. You model your economy in the tool the same way you'd describe it to a developer, and then simulate how it behaves over time.

What you can do in itembase:

Build a visual model of your economy (items, currencies, sources, sinks)
Define player behavior profiles (casual, mid-core, power)
Simulate economy behavior over days, weeks, and seasons
Identify progression cliffs, inflation risks, and reward gaps
Test LiveOps changes before they go live

It's the tool that sits between your spreadsheet and your launch — the validation step that catches what static math misses.

Try itembase → itembase.dev

Frequently Asked Questions

What is a game economy simulator?

A game economy simulator is a tool that models how a game's economy behaves when players move through it over time. Unlike spreadsheets, which calculate static expected values, a simulator runs player behavior against the economy design and shows how currencies accumulate, where progression stalls, and how different player types experience the economy differently.

Why should you simulate a game economy before launch?

Simulation catches economy problems — broken progression, inflation, reward imbalance, content exhaustion — at the design stage, when they're cheap to fix. Post-launch economy problems are expensive to fix, erode player trust, and show up in churn data and reviews. Simulating before launch prevents problems that analytics can only diagnose after they've already hurt your game.

What does a game economy simulator catch that spreadsheets miss?

Spreadsheets calculate theoretical values for individual transactions. Simulators model behavioral dynamics over time: where currency accumulates beyond what players can spend (inflation), where upgrade costs outpace session earn rates (progression cliffs), where reward cadence becomes too thin (reward imbalance), and where players complete all content too quickly (content exhaustion).

What is the best game economy simulator?

itembase is a purpose-built game economy design and simulation platform for F2P, mobile, and live service game designers. It models real game items and currencies, supports multiple player behavior profiles, and simulates economy behavior over extended time periods.

When should you simulate your game economy?

Ideally, at two points: during design (to validate the economy structure before implementation) and before major LiveOps updates (to test the impact of events, balance changes, or new content before they go live). Post-launch analytics complements simulation but doesn't replace it.

Simulate First. Ship Confident.

The gap between "the math looks right" and "the economy works" is where most economy mistakes live. Simulation is how you close that gap.

Simulate your game economy in itembase → itembase.dev

Game Economy Balancing: How to Tune Rewards, Costs, and Progression

Hiroshi TK — Mon, 18 May 2026 11:43:07 +0000

An economy can be well-designed and still badly balanced. The design tells you what the currencies are, what the loops are, how players earn and spend. Balance determines whether any of that feels right in practice.

Game economy balancing is the process of tuning earn rates, upgrade costs, session rewards, and progression curves until the game hits the target pace. Too fast and nothing feels earned. Too slow and the game feels like a chore. The sweet spot is a moving target — different for different player segments, different at different stages of the game, different before and after a live update.

This guide gives you a practical framework for approaching balance, the key variables you need to control, and the mistakes that make balance work collapse.

Key Takeaways

Balancing is tuning, not designing — it happens after the economy structure is in place.
The two core ratios to maintain: earn rate vs upgrade cost, and session reward vs session goal.
Progression curves define how quickly players feel powerful — linear, exponential, and milestone-based curves all produce different player experiences.
Balance for multiple player segments: casual, mid-core, and power players experience the same numbers very differently.
Simulation is the only way to validate balance across time and player types — math alone isn't enough.

What Is Game Economy Balancing?

Game economy balancing is the process of adjusting the numerical values in a game economy — earn rates, costs, drop probabilities, progression multipliers — until the player experience matches the design intent.

Balancing happens at two levels:

Micro-balance: Individual values. How many coins does this quest give? How much does this upgrade cost? What's the drop probability on this chest? These are the granular numbers that make up the economy.

Macro-balance: The overall feel. Does progression move at the right pace? Do players feel rewarded? Are there points where the game feels too easy, too hard, or too grindy? Macro-balance is the emergent result of all the micro-balance decisions combined.

Getting micro-balance right doesn't guarantee macro-balance is right. You can have perfectly calibrated individual numbers that produce a broken overall experience — usually because you didn't account for how the numbers compound over time.

The Key Variables in Economy Balancing

Earn Rate

What it is: How much currency (soft, hard, event tokens, materials) a player earns per session, per day, per week.

How to set it: Start from the player goal, not the other way around. If you want players to be able to upgrade their main item every 2 sessions, work backward from the upgrade cost to determine the required earn rate.

Segment it. A player who plays 3 sessions a day earns 3x what a player who plays 1 session does. Your earn rate should make sense for both. Design your base earn rate around the casual player — the one who plays once a day for 20 minutes — then make sure the economy doesn't break for power players who play much more.

Upgrade Cost

What it is: How much currency a player spends to advance — to level up a unit, unlock a building, progress through a tier.

The basic rule: Upgrade cost should feel proportional to the upgrade's impact. Small quality-of-life upgrades cost small amounts. Transformative upgrades cost significantly more. If costs feel arbitrary, players stop caring about the economy.

The escalation question: Should costs go up as players advance? Almost always yes — but the question is at what rate.

Session Reward

What it is: The currency or items a player earns in a single play session.

The target feeling: Players should end each session feeling like they made progress. The session reward doesn't need to complete an upgrade — but it should visibly advance toward one. If players play for 15 minutes and can't see any change in their resource total, the session reward is too low.

The cap question: Session rewards that scale infinitely with time-in-session create problems (power players hoard). Session rewards that don't scale at all create a different problem (players feel capped). Most games use a soft cap: good rewards for the first 20–30 minutes, diminishing returns after that.

Progression Curves

A progression curve defines how the relationship between player effort and player advancement changes over time. There are three main types:

Linear curve: Each upgrade costs the same amount. Level 1→2 costs 100 coins; level 19→20 costs 100 coins. Simple, transparent, but provides no sense of escalating challenge or achievement.

Exponential curve: Each upgrade costs significantly more than the last. Level 1→2 costs 100 coins; level 19→20 costs 100,000 coins. Creates a sense of meaningful progress but can produce brutal late-game walls if the earn rate doesn't scale proportionally.

Milestone-based curve: Costs escalate in tiers, not continuously. Levels 1–5 cost roughly the same; levels 6–10 are more expensive; levels 11–15 jump again. Easier to balance than pure exponential, and creates natural breakpoints that feel like progression milestones.

Most F2P games use a hybrid: mild exponential with milestone jumps at key progression points (equipment tier changes, content unlocks, power thresholds).

Balancing for Player Segments

The biggest mistake in economy balancing is balancing for a single player type. Your economy is played by at least three meaningfully different player segments:

Casual players: Play once a day, 15–20 minutes per session. Low total earn rate. Need to feel the economy working for them even with limited play time. If your economy only makes sense for players who play an hour a day, casual players will churn.

Mid-core players: Play 2–4 sessions a day, 30–45 minutes each. Your median engaged user. The economy should feel most natural to this segment — this is who you're primarily designing for.

Power/whale players: Play many sessions a day, long sessions. High earn rates. The risk here is that your economy breaks for them — they accumulate too fast, exhaust your progression content, and lose motivation.

To balance across segments, calculate the daily earn rate for each segment type and check:

Does the casual player feel meaningful progression? (Goal: yes)
Does the power player exhaust the economy? (Goal: no — there should always be a valuable goal out of reach)
Does the mid-core player feel the economy is well-paced? (Goal: yes — this is your primary signal)

Common Balance Mistakes

The level 15 cliff. A sudden jump in upgrade cost that isn't matched by a jump in earn rate. Players hit the wall, session rewards feel meaningless, and churn spikes. This shows up in analytics as a sharp retention drop at a specific progression point.

Front-loaded generosity. Giving new players too much, too fast. The first few levels feel amazing; then the earn rate normalizes and the game feels like it got harder. Players experience this as "bait and switch" even if it's not intentional.

Back-loaded stinginess. Mid-game earn rates that don't keep up with upgrade cost escalation. Players who've been engaged for weeks suddenly feel stuck. This is the most common cause of mid-game churn in F2P games.

Power player exhaustion. No meaningful content for the top 5% of players. They've completed everything, they have max resources, there's nothing left to do. These players leave and sometimes never come back — even when new content launches.

Ignoring material sinks. Adding upgrade materials as a mechanic but not enough sinks for them. Players accumulate materials they can't use, the inventory fills up, and the materials become meaningless noise.

How to Actually Tune the Numbers

Balancing is iterative. There's no formula that produces a balanced economy on the first pass. Here's a practical process:

Step 1: Define target pacing. What should the average player experience at day 1, day 7, day 30? Write this out explicitly. "By day 7, a player who plays once daily should be able to upgrade their main item to tier 3." That's a spec, not just a vibe.

Step 2: Work backward from goals. If day-7 tier 3 is the target, how much does tier 3 cost? How much should a player earn per day? Set the earn rate from there.

Step 3: Check the curve. Plot upgrade costs and daily earn rates on the same chart. Do they move together? Is there a point where costs spike above earn rate? That's a cliff — adjust it.

Step 4: Simulate, don't just calculate. Run a simulation of player behavior over 30 days for casual, mid-core, and power player profiles. Does each segment experience the economy the way you intended? Where do they diverge from your targets?

Step 5: Iterate on bottlenecks. Identify the points where progression stalls and whether those stalls are intentional (designed friction) or accidental (balance errors). Adjust costs or earn rates at those specific points.

Step 6: Test with real players. Playtest data will always surface things simulation doesn't catch — feel, perception of fairness, emotional response to randomness. Use both.

Where itembase Fits in Balancing

Steps 4 and 5 — simulation and bottleneck identification — are where spreadsheets fail and a proper tool becomes essential. itembase lets you model your earn rates, upgrade costs, and progression curves, define player behavior profiles, and simulate the economy over days and weeks of play.

Instead of guessing where the level 15 cliff is, you see it in the simulation. Instead of calculating whether your casual player can upgrade by day 7, you run it and see exactly what they have at the end of day 7 with 1 session per day.

That's the difference between balancing on paper and balancing with confidence.

Try itembase → itembase.dev

Frequently Asked Questions

What is game economy balancing?

Game economy balancing is the process of tuning numerical values — earn rates, upgrade costs, drop rates, progression multipliers — to produce a player experience that matches design intent. A balanced economy feels rewarding, progresses at the right pace, and works well across different player types (casual, mid-core, power players).

What is a progression curve in games?

A progression curve defines how the cost of advancement changes as players go deeper into a game. Linear curves keep costs constant; exponential curves escalate costs rapidly; milestone-based curves escalate in tiers. Most F2P games use a hybrid of exponential and milestone-based curves to create a sense of meaningful progression without producing unmanageable late-game walls.

How do you balance earn rates and upgrade costs?

Start from your target pacing — how quickly you want players to progress — and work backward. If players should upgrade every two days, and they earn 200 coins per day, the upgrade should cost around 400 coins. Then check that the ratio holds as costs escalate: the earn rate should scale roughly in parallel with upgrade costs to avoid mid-game cliffs.

Why do games feel grindy?

Games feel grindy when upgrade costs escalate faster than earn rates — players spend more time working toward the same upgrade than they did earlier in the game, but the reward feels proportionally smaller. Grind is usually a symptom of unbalanced earn/cost ratios at specific progression points, often in the mid-game.

How do you balance an economy for multiple player types?

Calculate daily earn rates for casual (1 session/day), mid-core (3–4 sessions/day), and power players (many sessions/day). Check that the economy feels meaningful for the casual player, is primary-tuned for the mid-core player, and doesn't allow power players to exhaust all content. Adjust earn rate caps, session reward decay, and high-end progression goals accordingly.

Balance It Before You Ship It

The best time to find a balance problem is in simulation, not in your live player data.

Balance and simulate your game economy in itembase → itembase.dev

Game Economy Design for Free-to-Play Games: A Beginner’s Guide

Hiroshi TK — Mon, 18 May 2026 09:18:14 +0000

Free-to-play is the dominant business model in mobile games, and it lives or dies on its economy. The game is free to download. Revenue comes from players choosing to spend inside it. That choice — whether a player spends, how much, and how often — is almost entirely determined by how the economy is designed.

This guide is for designers who are new to F2P economy design. No jargon assumed. By the end, you'll understand the building blocks: currencies, monetization pressure, progression pacing, reward loops, and why getting the economy wrong is one of the fastest ways to kill retention.

Key Takeaways

F2P economies are designed to generate revenue from voluntary in-game spending — but only work if the game is worth playing for free.
Soft currency and hard currency serve different roles and need separate balance logic.
Monetization pressure should be felt as motivation, not frustration — the line between them is pacing.
Reward loops are the engine that keeps players coming back. Break the loop and you lose the player.
Economy design directly affects retention — not just revenue.

What Makes F2P Economy Design Different

In a paid game, the economy exists to serve the player's enjoyment. In a free-to-play game, the economy has to do two things at once: create a great experience for players who never spend a cent, while also creating meaningful reasons for players who want to spend to do so.

That's a harder design problem than it sounds. Too generous with free rewards and nobody has a reason to pay. Too aggressive with monetization pressure and players feel exploited — and leave.

The best F2P economies feel fair. Players who don't pay still progress, still have fun, still feel rewarded. Players who pay feel like they're getting something genuinely valuable — time, cosmetics, or power — without making the game feel broken for those who don't.

The Two Core Currencies

Almost every F2P game runs on a two-currency system. Understanding these two currencies — what they're for and how they interact — is the foundation of F2P economy design.

Soft Currency

What it is: The primary earned currency. Coins, gold, credits, stars — whatever your game calls it. Players earn it through gameplay: completing levels, winning matches, finishing quests, watching ads.

What it does: Covers frequent, low-stakes purchases. Upgrading common items, buying consumables, accessing standard content. The soft currency transaction should feel like a routine decision, not a weighty one.

How to balance it: Players should always have enough to make regular purchases but never so much that upgrades feel trivially cheap. The goal is motivated abundance — enough to keep progressing, not enough to buy everything at once.

Common mistake: Over-rewarding soft currency early, then under-rewarding it mid-game. Players feel rich at the start, hit an upgrade cliff mid-game, and churn.

Hard Currency

What it is: The premium currency. Gems, diamonds, crystals, rubies. Earned very slowly through gameplay — or purchased with real money.

What it does: Covers high-value decisions: rare item pulls, time skips, premium content access, exclusive bundles. The hard currency transaction should feel meaningful. If hard currency is too abundant, it loses its premium feel. If it's too scarce for free players, it feels extractive.

How to balance it: Free players should earn enough hard currency to make occasional premium purchases — just enough to feel included, not enough to eliminate purchase motivation. The rate for free players is typically 10–20% of what a modest spender would access.

Common mistake: Making hard currency feel mandatory for basic progression. The moment a player feels they have to pay to continue, the game's reputation tanks and organic acquisition dries up.

Monetization Pressure: The Line Between Motivation and Frustration

Monetization pressure is the design tension that makes a player consider spending. Done right, it feels like an opportunity. Done wrong, it feels like a wall.

The factors that determine which side of the line you're on:

Pacing. If players encounter a hard paywall 10 minutes into the game, they feel trapped. If they encounter it after 10 hours of free progression, they've already invested — and the spend feels like a natural continuation.

Optionality. Cosmetic purchases create zero pressure — players choose to spend, not because they need to. Power purchases (pay to progress faster or be stronger) create more pressure, and the ethics depend heavily on whether the game is competitive.

Transparency. Players tolerate monetization they understand. Hidden conversion rates, obscured odds, and confusing currency layers feel manipulative.

Fairness. Players who don't pay should still feel like they're playing the real game. If the free version is a demo and the full experience is paywalled, the economy is designed for extraction, not retention.

Progression Pacing: The Engine of Retention

In F2P games, progression is the primary reason players return. The feeling of getting stronger, unlocking new content, reaching the next milestone — that's the loop that drives daily retention.

Pacing that progression well is one of the hardest things in F2P economy design.

The early game

Progress should feel fast. Players should reach meaningful milestones in their first session and their first week. The economy should be generous early — this is where players decide whether the game is worth continuing.

Early-game economy: high earn rates, low upgrade costs, fast unlock cadence.

The mid game

Progress should slow — but not stop. This is where the economy starts mattering. Upgrades take longer. Resources take more sessions to accumulate. Players start making meaningful decisions about what to upgrade and what to save for.

This is also where monetization starts appearing in earnest. Time-skip offers, resource bundles, battle pass introductions. The pacing here should feel like a natural deepening, not a sudden wall.

Mid-game economy: moderate earn rates, escalating upgrade costs, first meaningful soft currency decisions.

The late game

Progress is slow by design. The late game is for highly engaged players — the ones who've been playing for weeks or months. Upgrade costs are high, resources take dedicated effort to accumulate, and LiveOps content (events, seasonal updates) carries the retention load.

This is where whale monetization happens. Big bundles, exclusive content, significant time saves. The late-game economy doesn't need to be generous — but it needs to feel worth the investment for players who've already chosen to commit.

Late-game economy: low earn rates relative to costs, high-stakes decisions, LiveOps content as primary engagement driver.

Reward Loops: Why Players Come Back

A reward loop is the cycle of action, reward, and motivation that keeps a player engaged. In F2P games, reward loops are the economy's delivery mechanism — they're how players feel the economy rather than just seeing it in numbers.

The session loop (minutes)

Short cycle. Do something → get rewarded → feel good about doing more. Completing a level, earning coins, getting a drop. The session loop keeps players engaged within a play session.

Design goal: The session should end with the player feeling like they made progress. They spent resources on an upgrade, they earned resources from a quest, they got a drop worth keeping.

The daily loop (hours/days)

Medium cycle. Log in → complete daily content → accumulate toward a goal → return tomorrow. Daily missions, login rewards, energy replenishment, daily shop rotation. The daily loop is what makes a game part of a player's routine.

Design goal: Coming back tomorrow should feel rewarding from the moment the player opens the game.

The progression loop (weeks)

Long cycle. Level up, unlock new content, complete a battle pass tier, build toward a major upgrade. This is the backbone of long-term retention.

Design goal: Players should always have a goal that's 1–2 weeks away. Close enough to feel achievable, far enough to keep them coming back.

Why Economy Design Affects Retention

Here's the connection that most beginners miss: economy design and retention are not separate concerns.

Every churn event is an economy event. Players who churn at the upgrade cliff churn because the economy made them feel stuck. Players who churn after maxing out soft currency churn because the economy gave them nothing to spend on. Players who churn after a "bad" gacha run churn because the economy felt unfair.

Good economy design creates a game that feels worth playing every day, worth spending on occasionally, and worth recommending. That's not a monetization optimization — that's a retention architecture. And it's set at the design stage, before the first line of code.

Getting It Right: Simulate Before You Ship

F2P economy design is genuinely hard to get right on paper. The math can look balanced and still produce a broken player experience. The reason: player behavior doesn't follow expected values. Different players spend at different frequencies, have different risk tolerances for gacha, and progress at wildly different paces.

Simulation — running player behavior models against your economy before launch — is how F2P designers validate their work. It catches the soft currency cliff at level 15 that your spreadsheet missed. It shows you that your battle pass is only completable for players who play 90 minutes a day, not 30.

itembase is built for this. It's a game economy design and simulation platform designed specifically for F2P and live service games — model your currencies, reward loops, and progression systems, then simulate how different player types move through them.

Try itembase → itembase.dev

Frequently Asked Questions

What is F2P game economy design?

Free-to-play game economy design is the practice of designing a virtual economy that generates revenue through voluntary in-game purchases while keeping the game accessible and enjoyable for non-paying players. It involves designing currencies, reward structures, progression pacing, and monetization mechanics that balance player experience with business sustainability.

What is the difference between soft currency and hard currency in F2P games?

Soft currency is the primary gameplay-earned currency — used for frequent, low-stakes purchases like upgrades and consumables. Hard currency is the premium currency earned slowly or purchased with real money — used for high-value purchases like rare items, time skips, and premium content. The two-currency system allows F2P games to serve both paying and non-paying players simultaneously.

How does economy design affect game retention?

Economy design directly drives retention because it controls the pacing and feeling of progression. Economies that progress players too slowly create frustration and churn. Economies that progress players too quickly create nothing to work toward. Well-paced economies keep players in a state of motivated scarcity — always progressing, always with a goal in sight, always with a reason to return.

What is monetization pressure in F2P games?

Monetization pressure is the design tension that makes a player consider spending real money. Healthy monetization pressure feels like an opportunity — spending would be nice, but not spending is still a good experience. Unhealthy monetization pressure feels like a wall — not spending means significant friction or blocked progression. The line between them is mostly a function of pacing and optionality.

How do you design progression pacing in a F2P game?

F2P progression pacing should be fast in the early game (frequent milestones, generous rewards), moderate in the mid-game (escalating costs, meaningful decisions), and slow in the late game (high-effort goals, LiveOps-driven engagement). The key is that progress should always feel possible — even if it's slow — so players stay motivated rather than hitting walls that cause churn.

Start Designing Your F2P Economy

Understanding the principles is step one. Testing them against real simulated player behavior is step two.

Design and simulate your F2P game economy in itembase → itembase.dev

How to Design a Game Economy: Sources, Sinks, Loops, and Balance

Hiroshi TK — Fri, 15 May 2026 13:12:15 +0000

Every game with a currency has an economy. Most designers don't treat it like one.

They add coins because coins feel good. They add an upgrade system because upgrades feel like progression. They add a premium currency because monetization needs one. Then they ship and discover that players are swimming in coins by level 10, upgrades feel meaningless, and nobody is buying premium currency because the earn rate makes it feel pointless to spend real money.

That's not bad luck. That's an economy that was never designed — it was assembled.

This guide teaches you how to actually design a game economy from scratch: what sources and sinks are, how loops work, and how to balance it all so the economy serves the game instead of fighting it.

Key Takeaways

Every game economy has sources (where currency enters) and sinks (where it leaves). Keeping these balanced is the core job.
Inflation happens when sources outpace sinks. Deflation happens when sinks outpace sources.
Economy loops connect earning and spending into a cycle that drives player motivation.
Different currency types (soft, hard, energy, event tokens) serve different functions and need separate balance logic.
Simulation — not just math — is what catches economy problems before players do.

What Is a Game Economy?

A game economy is the complete system of resources in a game — how they're earned, how they're spent, how they interact, and how they create meaningful decisions for the player.

"Resources" here means anything a player accumulates and uses: coins, gems, energy, materials, keys, event tokens, XP, upgrade components. If it has a number attached to it and players can earn or spend it, it's part of the economy.

The goal of economy design is not to make players rich. It's not to make players poor. It's to keep players in a state of motivated scarcity — always feeling like they're progressing, always feeling like the next thing is within reach, and always having a reason to come back.

Sources: Where Resources Come From

A source is any mechanism that creates resources and puts them in the player's hands. Sources are the inputs to your economy.

Common sources in game economies:

Gameplay rewards — coins from completing a level, materials dropped from combat, XP earned from a quest. The most direct source; players feel they've earned it.

Daily and session rewards — login bonuses, daily missions, streak rewards. Reliable drip-feed sources that drive daily retention.

Event rewards — resources earned from limited-time events, tournaments, seasonal content. High-volume, time-compressed sources that can disrupt economy balance if not scoped carefully.

Ad rewards — rewarded video ads that give resources in exchange for watching. A soft monetization source that competes with premium currency spend.

IAP (in-app purchase) — real-money purchases that inject premium currency or items. The highest-value source; rate of injection has major economy implications.

Gacha / loot pulls — randomized item acquisition. Items pulled are effectively resources generated by spending a different resource (pulls, keys, crystals).

Crafting outputs — resources created by combining other resources. A source that's simultaneously a sink for input materials.

Progression unlocks — resources granted upon reaching a level, milestone, or achievement. One-time sources that front-load value at specific points.

The key question about every source: how much resource does it inject per unit of player time, and how does that rate change as players advance?

Sinks: Where Resources Go

A sink is any mechanism that removes resources from the player's hands. Sinks are the outputs of your economy — they're what gives resources meaning by making them scarce.

Without sinks, your economy inflates. Players accumulate more than they can spend, the currency becomes meaningless, and monetization collapses because there's nothing worth spending real money on.

Common sinks in game economies:

Upgrades — spending coins or materials to increase a unit's stats, a building's level, or a character's power. The most common sink in progression games.

Crafting inputs — materials consumed to create items. A sink that also creates new items, so the economy impact depends on what gets crafted and how it's used.

Chests and pulls — spending keys, crystals, or premium currency on randomized rewards. A premium sink with variable output.

Energy / stamina — spending energy to play levels or access content. A time-gating sink that controls session length and drives return visits.

Store purchases — buying items, cosmetics, power-ups, or content directly. A direct sink that turns currency into something specific.

Progression gates — content locked behind resource requirements (pay X coins to unlock this area, spend Y materials to access the next tier). Hard sinks that block progress until the requirement is met.

Expiry and decay — event tokens that expire after an event, energy that caps and doesn't accumulate, daily offers that reset. Soft sinks that remove resources by limiting their shelf life.

The key question about every sink: how much resource does it consume per meaningful player action, and is that rate in balance with the sources?

Source-Sink Balance: The Core of Economy Design

The relationship between sources and sinks determines the health of your economy:

Balanced: Players earn roughly what they spend over time. Scarcity exists but isn't oppressive. Players feel rewarded and motivated.

Source-heavy (inflation): Players accumulate more than they spend. Currency piles up, upgrades feel cheap, nothing feels scarce, and monetization tanks because there's nothing valuable left to sell.

Sink-heavy (deflation): Players can't earn enough to spend comfortably. Progression feels blocked, frustration builds, and players churn or feel forced to pay.

Neither extreme is good. The job is to keep the economy close to balanced — with deliberate small imbalances that create urgency, motivation, and monetization opportunities.

A practical balance check

For each currency in your game, map:

All sources and their earn rates (per session, per day, per event)
All sinks and their consumption rates
The ratio of total daily income to total daily spend for an average player
The ratio for a power player (high session frequency)
The ratio for a casual player (low session frequency)

If those ratios diverge dramatically between player segments, your economy is working differently for different players — which is usually a problem.

Economy Loops: Connecting Earning and Spending

A source and a sink by themselves aren't an economy. An economy loop is what connects them into a cycle that drives player motivation.

The basic loop structure:

Action → Reward → Spend → Power/Progress → New Action

Example from a simple RPG:

Fight enemies → earn coins and XP → spend coins on upgrades, spend XP on leveling → become stronger → fight harder enemies → earn more coins and XP

Example from a mobile idle game:

Tap/auto-produce resources → accumulate soft currency → spend on production upgrades → increase production rate → accumulate faster → unlock new resource types

Example from a farming sim:

Plant crops → wait → harvest → sell for coins → buy seeds and buildings → plant more crops → higher yields → more coins

What makes a loop work:

The reward feels proportional to the action. Players should feel like they earned the resource, not like it appeared randomly.
The spend has a meaningful outcome. Spending should visibly change something.
The new action is more interesting than the last. Progress should open new possibilities, not just bigger numbers.
The loop has the right cycle time. Too fast and it feels trivial. Too slow and players disengage between loops.

Multiple Currencies: When One Isn't Enough

Most games beyond a simple arcade title have more than one resource. Here's why, and how to design each one's role:

Soft currency (coins, gold, credits): The primary earned currency from gameplay. High volume, low unit value. Used for frequent, low-cost purchases — upgrades, consumables, standard content.

Hard currency (gems, diamonds, crystals): The premium currency, earned slowly or purchased. Low volume, high unit value. Used for high-value purchases — rare items, time skips, premium content. This is your core monetization lever.

Energy / stamina: A session-gating resource. Replenishes over time. Controls how long players can play in a session and drives return visits. The sink is playing the game; the source is time (and premium spend for refills).

Event / seasonal tokens: Temporary currencies earned from specific content. Expire with the event. Create urgency and give live events economic weight.

Upgrade materials: Specific resources for specific upgrades. Adds targeting to spending — you can't just dump coins, you need the right material for the right upgrade. Creates secondary sink loops.

Each currency needs its own source-sink balance. And each currency's design should answer: what is the player's relationship to this resource? Is it abundant or scarce? Do they make frequent small decisions or rare large ones?

Common Economy Design Mistakes

Inflation from over-rewarding events. Limited-time events that inject large amounts of currency without adequate sinks create an inflation spike that outlasts the event.

Dead currencies. Adding a currency but not enough sinks for it. Players accumulate a resource they can't meaningfully spend, and it becomes invisible noise.

Pay-to-skip vs pay-to-win. Hard currency that lets players skip time gates is contentious but acceptable to most players. Hard currency that gives a direct power advantage over others damages game perception and long-term health.

Bottleneck cliffs. Points in progression where the cost of the next upgrade far exceeds what the average player has accumulated. These are progression deserts — churn magnets.

Simultaneous inflation and deflation. An economy with too many soft currencies and not enough of the specific material needed for an upgrade. Players feel rich and stuck at the same time.

Why You Should Simulate, Not Just Calculate

All of the above can be planned on paper and in spreadsheets. But spreadsheets show you what your economy should do. They don't show you what it will do when 50,000 players with different play frequencies, spending habits, and session lengths move through it simultaneously.

Economy simulation — running player behavior models against your economy design over time — is how you catch problems before launch:

Does soft currency inflate at mid-game for high-session players?
Does the first major upgrade bottleneck cause player drop-off?
Does the premium currency earn rate make IAP feel pointless?
Does the battle pass feel completable for casual players or only for whales?

itembase is built for this. It lets you model your economy visually, define player behavior profiles, and simulate how your economy evolves over time — so you catch the inflation, the bottlenecks, and the dead currencies before your players do.

Try itembase → itembase.dev

Frequently Asked Questions

What are sources and sinks in game economy design?

Sources are mechanisms that create resources and deliver them to players — gameplay rewards, daily bonuses, events, IAP. Sinks are mechanisms that consume resources — upgrades, crafting, store purchases, energy expenditure. Keeping sources and sinks in balance is the core discipline of game economy design.

What is game economy design?

Game economy design is the discipline of designing how resources (currencies, items, energy, materials) are created, distributed, spent, and balanced in a game. It includes defining sources and sinks, designing reward loops, balancing multiple currencies, and ensuring the economy supports player motivation and business sustainability.

How do you balance a game economy?

Balance a game economy by mapping all sources and sinks for each currency, calculating earn and spend rates across different player segments, ensuring no segment accumulates dramatically more than they spend over time, and using simulation to test dynamic behavior over extended play sessions.

What causes inflation in a game economy?

Inflation happens when sources produce more currency than sinks consume. Common causes: over-rewarding events, insufficient upgrade costs, adding currencies without corresponding sinks, or failing to account for high-frequency players who earn far more per day than casual players.

What is an economy loop in games?

An economy loop is the cycle connecting earning and spending in a game: player takes an action, receives a reward, spends the reward to gain power or progress, which enables a new action. Well-designed loops create self-reinforcing motivation — the spending always leads back to the earning.

Design Your Economy the Right Way

Understanding sources, sinks, and loops is where economy design starts. Simulating them is where you validate that they actually work.

Model and simulate your game economy in itembase → itembase.dev

Best Game Economy Design Tools for Modern Game Teams

Hiroshi TK — Thu, 14 May 2026 11:14:05 +0000

Game economy design has a tooling problem. Every other design discipline has dedicated software, UI designers use Figma, project managers use Jira, engineers use IDEs with version control. Economy designers? Most of them are still working in a spreadsheet their lead designer built three years ago, maintained by whoever has been there longest.

That's changing. This guide covers every major category of game economy design tool available today, what each is actually good for, where it breaks down, and how to think about building a stack that matches how your team actually works.

Key Takeaways

There's no single tool that handles every part of game economy design.
Spreadsheets are cheap and universal but lack simulation and break at scale.
Machinations is good for visual resource flows but has a steep learning curve.
Internal tools are powerful but expensive to build and maintain.
Analytics dashboards tell you what went wrong after the fact — not how to fix it before launch.
itembase is the purpose-built option for F2P, mobile, and live service game economy design and simulation.

What Game Economy Design Tools Need to Do

Before comparing tools, it's worth being explicit about what the job actually requires. A complete game economy design tool should handle:

Modeling — representing currencies, items, sources, sinks, and their relationships
Simulation — running player behavior over time to see how the economy evolves
Balancing — tuning earn rates, costs, and progression curves
LiveOps planning — testing what events, bundles, or balance changes do to the economy before shipping
Collaboration — making the economy model readable and shareable with the full team

With that in mind, here's how the available options compare.

Spreadsheets (Google Sheets / Excel)

What they are

The universal default. Every game economy starts in a spreadsheet. Expected value calculations, upgrade cost tables, currency conversion ratios, progression curve plots.

What they're good at

Static math. If you need to check whether your daily quest coin yield makes a chest affordable in 2.5 days, a spreadsheet does that in seconds. Simple curves, ratios, and snapshots.

Where they fall short

Spreadsheets don't simulate — they calculate. They give you theoretical expected values, not behavioral distributions across a player population. They can't model how currency supply accumulates over 30 days of play, how a randomized loot system performs at percentile extremes, or how a seasonal event changes your economy's equilibrium.

At scale, they also become maintenance problems. Multiple currencies, interdependent formulas, seasonal patches — spreadsheets grow into systems no single person fully understands.

Best for: Early-stage math, simple economies, quick ratio checks.

Not for: Simulation, dynamic modeling, complex economies, LiveOps.

Cost: Free.

Machinations

What it is

A node-based visual tool for designing and simulating game systems. Machinations represents economies as diagrams — nodes represent resources, edges represent flows — and can run simulations over time.

What it's good at

Making systems visible. Machinations is excellent for teaching economy design (it's widely used in game design education) and for the early stages of designing resource flow logic. The visual format makes it easier to show a system to a non-designer than a spreadsheet does.

Where it falls short

Machinations abstracts heavily. It works at the level of "resource flows" — not at the level of actual game items, currencies with specific names, seasonal event structures, or IAP bundles. Getting a real game's economy accurately represented is time-consuming, and the output is more useful for system thinking than for production-ready balancing.

The learning curve is also steeper than it looks. Designers who aren't already comfortable with systems diagrams often bounce off it.

Best for: Systems education, early-stage economy diagramming, academic or concept-phase work.

Not for: Production economy balancing, LiveOps simulation, F2P game-specific economy modeling.

Cost: Free tier available; paid plans for teams.

Custom Internal Tools

What they are

Spreadsheet-based systems, internal dashboards, or custom-built apps that larger studios develop specifically for their games. Some studios have internal economy editors, balance sheets with simulation layers, or backend tools that tie directly into their game's data.

What they're good at

Perfect fit. A custom tool built around your specific game, your specific currencies, your specific LiveOps pipeline — nothing out-of-the-box matches that.

Where they fall short

Cost. Building and maintaining a custom economy tool requires engineering time that most teams don't have. The tool ages with the game — it needs to be updated every time the economy changes. And when the economy designer who built it leaves, institutional knowledge walks out with them.

Custom internal tools are a luxury for teams with dedicated tooling engineers. Most indie and mid-size studios can't afford them.

Best for: Large live service studios with dedicated tooling teams.

Not for: Indie teams, mobile studios, teams without engineering capacity.

Cost: High — engineering time.

Analytics Dashboards (GameAnalytics, Amplitude, Mixpanel)

What they are

Post-launch data platforms that track player behavior, monetization metrics, retention curves, and funnel performance.

What they're good at

Telling you what happened. If your economy shipped broken, an analytics dashboard will tell you — players are churning at level 12, premium currency spend dropped 40% after the last patch, the conversion rate on your new bundle is below benchmark.

Where they fall short

They're retrospective by design. Analytics tells you about problems after players experienced them. They're not design tools — they don't help you model an economy or test a decision before shipping. And they require a live game with real player data, making them useless in pre-launch design phases.

Best for: Post-launch economy tuning, player behavior analysis, KPI tracking.

Not for: Pre-launch economy design, balancing, LiveOps planning before ship.

Cost: Free tiers available; paid for larger data volumes.

itembase

What it is

itembase is a purpose-built game economy design and simulation platform. It's the tool in this list designed specifically to cover the gap between "static spreadsheet math" and "real player behavior" — for designers working on F2P, mobile, and live service games.

What it's good at

itembase lets designers model their actual game economy — real currencies, items, sources, sinks, progression systems — and simulate how players move through it over time. You can test what happens when you add a new currency, run a limited-time event, change a drop rate, or introduce a new IAP bundle — before any of it goes live.

It's also designed to be usable by game designers, not data engineers. The interface is visual and game-design-native, not a BI tool with a game economy use case bolted on.

Key capabilities:

Visual economy modeling with actual game items and currencies
Player behavior simulation over time
LiveOps scenario testing (events, bundles, balance changes)
Progression and reward system simulation
Built-in simulation library with real game examples

Where it fits in the stack

itembase is not a replacement for analytics (which handles post-launch data) or for documentation tools (which handle GDDs). It's the pre-launch and pre-ship validation layer — the tool that catches economy problems before players do.

Best for: F2P economy design, battle pass design, LiveOps economy simulation, mobile game balancing, idle game economy, gacha economy design.

Cost: Free to start at itembase.dev.

Recommended Stack by Team Type

Team type	Recommended stack
Solo indie developer	Google Sheets + itembase
Small mobile studio (2–5)	Notion + Google Sheets + itembase
Mid-size F2P team	Notion + itembase + GameAnalytics
Large live service studio	Custom tooling + itembase + Amplitude
Narrative / non-economy game	Google Sheets + Machinations (optional)

The pattern is consistent: spreadsheets handle simple early-stage math, analytics handles post-launch data, and itembase covers the design and simulation layer that neither can.

Frequently Asked Questions

What is the best game economy design tool?

It depends on the game type and studio size. For F2P, mobile, and live service games, itembase is purpose-built for economy design and simulation. For simple games with linear economies, Google Sheets is sufficient. Machinations is useful for systems education and visual flow diagrams. Analytics tools like GameAnalytics are essential post-launch but not useful for pre-launch design.

What tools do game economy designers use?

Most economy designers use a combination of spreadsheets for static math, visualization tools for system diagrams, and increasingly — dedicated economy simulation tools like itembase for F2P and live service titles. Custom internal tools exist at larger studios but are uncommon at indie and mid-size scale.

Is Machinations good for game economy design?

Machinations is good for systems thinking and visual resource flow design, especially in educational or concept-phase work. It abstracts heavily and doesn't model real game-specific objects well, making it less practical for production-ready economy balancing or LiveOps simulation.

Do I need a game economy design tool if I have a data analyst?

Yes. Analytics and data analysis are retrospective — they tell you what happened after players experienced it. Economy design tools are prospective — they let you test assumptions before shipping. Both serve different purposes and neither replaces the other.

What is the best free game economy design tool?

itembase offers free access for game economy design and simulation. Google Sheets is free for static math. Machinations has a free tier for basic diagrams.

Build Your Economy Design Stack

If your current economy tooling is a spreadsheet and a prayer, it's worth investing an hour in a proper tool before your next project enters production.

Explore itembase for game economy design → itembase.dev

Why Spreadsheets Are Not Enough for Game Economy Design

Hiroshi TK — Wed, 13 May 2026 10:17:15 +0000

Spreadsheets built game economies before any dedicated tool existed for the job. And honestly — for a long time, they were fine. Simple math, a few currencies, a linear upgrade curve. Sheets handled it.

But modern games aren't simple. F2P economies have multiple interlocking currencies, randomized reward systems, time-gated progression, seasonal events, and player segments that all behave differently. Trying to model that in a spreadsheet doesn't just get inconvenient — it gets dangerous. You ship a broken economy because your spreadsheet said everything was fine.

This article explains where spreadsheets work, where they stop working, and what game economy design actually needs from a dedicated tool.

Key Takeaways

Spreadsheets are good for static math — expected values, cost ratios, simple curves.
They break down when randomness, multiple interdependent currencies, progression simulation, and LiveOps enter the picture.
The core problem: spreadsheets calculate what should happen. They can't simulate what will happen.
Economy-heavy games need a tool with a simulation layer, not just a calculation layer.
itembase is built specifically for this gap.

What Spreadsheets Do Well

Let's be honest — spreadsheets aren't going away, and they shouldn't. There's a class of economy design work they handle just fine:

Static expected value calculations. If a chest costs 100 coins and your daily quest gives 40 coins, a spreadsheet tells you players earn one chest every 2.5 days. That's useful.

Simple progression curves. Plotting upgrade costs across 20 levels, visualizing a power curve, checking that your XP-to-level formula doesn't get absurd at the high end — all spreadsheet territory.

Quick ratio checks. Is this item worth its cost relative to other items? Is this IAP bundle competitive? Spreadsheet does this in minutes.

Sharing static snapshots. A well-formatted balance sheet is easy to share with a producer, a developer, or a publisher. Everyone can open it.

So no — the argument isn't "never use spreadsheets." It's that spreadsheets are a starting point, not a complete solution.

Where Spreadsheets Break Down

1. They can't handle randomness properly

Gacha pulls, loot tables, variable event rewards, random drop rates — these all involve probability distributions, not single values. A spreadsheet gives you the expected value of a 3% drop rate. It can't simulate what the distribution of that outcome looks like across 10,000 players over 30 days. You end up designing around a single theoretical number that doesn't reflect actual player experience.

Some designers work around this with Monte Carlo simulations in Sheets, but those are painful to build, slow to run, and nearly impossible for non-technical teammates to use or trust.

2. Multiple interdependent currencies become unmanageable

Most spreadsheet economy models work fine with one or two currencies. Add a third, a fourth, a premium currency with two earn paths and three spend destinations, a seasonal token that converts to the main currency at a variable rate — and the spreadsheet becomes a liability. Cell references break. Formula errors propagate silently. Someone updates a conversion rate and doesn't realize it's referenced in fourteen other cells.

The bigger the economy, the faster this collapses.

3. They model states, not dynamics

A spreadsheet shows you a snapshot: what the economy looks like at a given point with a given set of assumptions. It doesn't show you how the economy changes over time as players move through it. Where does currency supply peak? When do players hit the first hard bottleneck? What happens to soft currency reserves if you double the drop rate from a limited-time event? These are dynamic questions. Spreadsheets are static tools.

4. Player behavior isn't in the model

Spreadsheets model the economy as designed. They don't model the economy as played. Players don't follow the expected path — they hoard, they spend irrationally, they quit at bottlenecks, they exploit unintended conversion loops. None of that shows up in a spreadsheet because the spreadsheet only knows about numbers you put in, not about players.

5. LiveOps makes it worse

The first time you ship a limited-time event that injects a new currency, adds a temporary exchange rate, and gates progression behind event-exclusive items — your spreadsheet breaks. You're now maintaining a fork, or patching in new tabs, or rebuilding the sheet from scratch. Every season, every update, every balance change adds complexity that the spreadsheet was never designed to carry.

The Economy Problems You'll Miss

Here's a short list of real economy failures that spreadsheets routinely fail to catch:

Inflation. Your sources produce more currency than your sinks consume. Players stockpile. Prices start to feel meaningless. The spreadsheet never shows you this because it doesn't simulate accumulation over time.

Currency devaluation. A new bundle or event offers a better conversion rate than existing content. Players drain their reserves, the old content becomes pointless, and the perceived value of your premium currency drops. The spreadsheet models each event in isolation.

Progression deserts. There's a 10-level stretch where the upgrade cost curve massively outpaces session rewards. Players stall, bounce, and churn. The spreadsheet shows you the numbers — it doesn't show you the behavioral consequence.

Content exhaustion. Players complete your battle pass in week one. The spreadsheet said the XP pacing would take six weeks. It didn't account for session frequency variance across your player base.

What Game Economy Design Actually Needs

A proper game economy design tool needs to do things a spreadsheet can't:

Simulate player behavior over time — not just calculate theoretical values.
Model multiple currencies and their interactions as a connected system, not isolated cells.
Run probabilistic outcomes for gacha, loot, and random rewards.
Visualize economy dynamics — currency accumulation, spend rates, bottleneck formation — as graphs, not tables.
Test LiveOps changes before they go live — what does this event do to my currency supply?
Be usable by a non-engineer designer without building custom scripts or pivot tables.

Where itembase Fits

itembase is a game economy design and simulation platform built for exactly this gap. It's not a replacement for spreadsheets entirely — quick math still happens in sheets. But for designing and validating a real game economy, itembase gives you what a spreadsheet can't:

A visual economy model built around your actual game items and currencies
Simulation of player behavior over time, not just static calculations
Support for multiple currencies, sinks, sources, and their interactions as a live system
LiveOps scenario testing — model an event, a bundle, a balance change before it ships

If your game has more than two currencies, any form of randomized rewards, progression gating, or live events — the spreadsheet is already failing you silently. The problems it misses don't show up until players find them.

Try itembase → itembase.dev

Frequently Asked Questions

Why are spreadsheets not enough for game economy design?

Spreadsheets handle static math well but can't simulate player behavior over time, model probabilistic outcomes accurately, or show how multiple interdependent currencies interact dynamically. They model the economy as designed — not as played. For F2P games, live service games, or any game with complex reward systems, this creates a gap between the design on paper and what players actually experience.

What is a game economy design tool?

A game economy design tool is specialized software for modeling, simulating, and balancing a game's virtual economy — its currencies, items, reward systems, progression gates, and live events. Unlike spreadsheets, dedicated tools include simulation layers that model player behavior over time and can test economy changes before they ship.

Can you design a game economy in Excel or Google Sheets?

Yes, for simple games with linear economies. For games with multiple currencies, randomized rewards, progression systems, or live events, spreadsheets become unreliable — they model expected values but miss behavioral dynamics, can't simulate time-based accumulation, and break down structurally as the economy grows in complexity.

What problems does game economy simulation solve?

Economy simulation catches problems that static spreadsheet models miss: inflation from unbalanced sources and sinks, progression deserts where reward rates fall behind upgrade costs, content exhaustion from faster-than-expected player advancement, and currency devaluation from poorly scoped live events.

What should I use instead of a spreadsheet for game economy design?

itembase is purpose-built for game economy design and simulation — it handles multiple currencies, player behavior simulation, probabilistic reward modeling, and LiveOps scenario testing in a visual interface designed for game designers, not data engineers.

Stop Designing Blind

Spreadsheets are a starting point. They're not a validation tool. If you're shipping a game economy based only on spreadsheet math, you're finding out what's wrong when players do.

Design and simulate your game economy in itembase → itembase.dev

Game Design Tool vs Game Engine: What Designers Actually Need

Hiroshi TK — Tue, 12 May 2026 10:45:35 +0000

Every new game designer makes the same assumption: the game engine is the tool. If you're in Unity, you're doing game design. If you know Unreal, you're a game designer.

That's not wrong — but it's nowhere near the full picture. Game engines are powerful, essential, and completely wrong for most of the actual work game designers do. This article draws the line clearly: what engines are for, what design tools are for, and why conflating the two costs designers time, money, and shipping confidence.

TL;DR — Key Takeaways

A game engine is a development and runtime tool — it builds, runs, and ships the game.
A game design tool is a thinking, modeling, and validation tool — it helps you figure out what to build.
Most core design work (systems, economy, balance, documentation) happens outside the engine.
Treating the engine as your design tool leads to expensive implementation-first decisions.
Designers need both — but they serve completely different purposes at different stages.

What a Game Engine Is (and Isn't)

A game engine — Unity, Unreal, Godot, GameMaker — is the software that makes your game run. It handles rendering, physics, input, audio, scripting, and deployment. It's where programmers write code, artists import assets, and the team integrates everything into a working product.

Engines are extraordinary tools. But they're built for implementation, not design thinking. When you're in Unity, you're already committed to a specific technical structure. You're answering "how do we build this?" — not "what should we build?"

That distinction is critical. Implementation-first game design leads to one of the most common and expensive problems in game development: systems that were built before they were properly designed. You prototype a progression system in the engine, it gets used as the base for real development, and three months later you realize the economy doesn't balance — but now it's baked into production code.

What a Game Design Tool Is

A game design tool helps you answer design questions before — and separate from — the question of how to implement them. Depending on the category, a design tool might help you:

Write and communicate design decisions (documentation tools: Notion, Confluence)
Map and sketch systems visually (whiteboard tools: Miro, FigJam)
Prototype player-facing flows (UI prototyping: Figma)
Model and simulate game systems and economies (systems tools: itembase, Machinations)
Balance numbers and curves (balancing tools: spreadsheets, itembase)
Plan and test live events (LiveOps tools: itembase, Airtable)

None of these tasks happen inside a game engine. And none of them should — the whole point is to make decisions before you commit to implementation.

Where the Confusion Comes From

The confusion makes sense. Game engines have become more and more design-friendly over time. Unity's visual scripting, Unreal's Blueprints, rapid-prototype-friendly frameworks — these blur the line between design and implementation. For small indie games with simple systems, prototyping in the engine can be totally valid.

But there are two problems with defaulting to the engine for design work:

1. The engine is the wrong level of abstraction for design questions.

Design questions are things like: "How fast should players earn premium currency?" or "What happens to player engagement if we add a third resource type?" or "Does our battle pass feel rewarding at the midpoint?" These are systems questions. The engine can't answer them. It can only implement whatever answer you give it.

2. Prototyping in the engine creates false permanence.

Once something is built in the engine, it feels real. It feels costly to change. Designs that live in a document, a diagram, or a simulation are psychologically easy to throw out and rebuild. Designs that live in Unity are not — even when the team intellectually knows they should.

The Right Tool for Each Stage of Design

Stage	Question	Right tool type
Concept	What is this game?	Docs, whiteboard
System design	How do the mechanics work?	Whiteboard, systems tool
Economy design	How do currencies, items, and rewards interact?	Economy design tool (itembase)
UI/UX flow	What does the player experience?	Prototyping tool (Figma)
Balancing	Are the numbers right?	Balancing tool, economy simulator
LiveOps planning	What happens after launch?	LiveOps tool, economy simulator
Implementation	How do we build it?	Game engine

Notice that the engine appears last. That's not because implementation is unimportant — it's because every stage before it exists to make the implementation stage faster, cheaper, and more confident.

When Engineers and Designers Disagree About Tools

One version of the engine-vs-design-tool argument that comes up in real teams: engineers want to prototype in the engine because they're more comfortable there; designers want to prototype in lightweight tools because they iterate faster. Both are valid — but they're optimizing for different things.

Engineers prototype to test technical feasibility. Designers prototype to test design assumptions. These should happen in parallel, not as the same activity. When a team conflates them, design decisions get made by whoever is most comfortable in the engine — which is usually not the designer.

What Designers Actually Need

If you're a game designer building any kind of system-heavy game — progression, economy, live events, gacha, idle mechanics, battle pass — your toolset needs to include more than an engine and a Google Doc.

Specifically:

A documentation tool so design decisions are written, shared, and findable.
A visual thinking tool for early system mapping.
A prototyping tool for player-facing flow validation.
An economy design and simulation tool for anything involving currencies, items, rewards, or live events.

itembase covers the last category directly — it's built for game economy design and simulation, designed to answer the systems questions your engine can't. If you're designing an F2P game, a live service game, or any game with a meaningful economy layer, it belongs in your stack before you open your engine.

itembase.dev

Frequently Asked Questions

What is the difference between a game design tool and a game engine?

A game engine (Unity, Unreal, Godot) is software for implementing, running, and shipping a game. A game design tool is software for thinking, modeling, simulating, and validating design decisions — documentation platforms, whiteboard tools, economy simulators, and prototyping tools. Engines answer "how do we build this?" Design tools answer "what should we build?"

Can you use a game engine as a game design tool?

To a limited extent — rapid prototyping inside an engine is valid for testing small mechanics. But engines are the wrong tool for documentation, economy modeling, balancing, LiveOps planning, and most system-level design thinking. Over-relying on the engine for design work leads to expensive late-stage changes.

What tools should a game designer use?

A complete designer toolkit covers: documentation (Notion, Confluence), visual thinking (Miro), UI prototyping (Figma), economy design and simulation (itembase), and LiveOps planning. The exact mix depends on the game type — economy-heavy and live service games need dedicated economy tooling.

Why do designers prototype outside the engine?

Speed and reversibility. A design that lives in a document or simulation is fast to change. A design that lives in production code feels permanent and becomes costly to revisit. Prototyping outside the engine lets designers validate assumptions cheaply before committing to implementation.

What is the best game design tool for systems design?

For game economy and systems design — especially in F2P, mobile, and live service games — itembase is purpose-built for modeling and simulating virtual economies. For visual system mapping, Machinations or Miro work well at early stages.

Design First, Build Second

The best game development teams treat engines and design tools as different instruments for different jobs. If you're currently doing all your design work inside Unity or in a spreadsheet, you're likely missing a layer of validation that would save you real development time.

Start designing your game economy in itembase → itembase.dev

What Is a Game Design Tool? A Practical Guide for Game Designers

Hiroshi TK — Tue, 12 May 2026 08:47:15 +0000

Ask a junior game designer what tools they use and they'll usually say Unity or Unreal. Ask a senior designer the same question and they'll list eight things — none of which are game engines.

A game engine is where your game runs. A game design tool is where your game gets designed. Those are two completely different activities, and conflating them is one of the most common mistakes new designers make. This guide explains what a game design tool actually is, the categories that matter, and how to build a stack that makes you a faster, clearer designer.

TL;DR — Key Takeaways

A game design tool is any software that helps you document, prototype, model, simulate, or communicate a game's design — before or during development.
Game engines are development tools, not design tools.
There are six core categories: documentation, whiteboards, prototyping, systems/economy design, balancing, and LiveOps.
Different game types need different tool stacks — a narrative RPG and an F2P mobile game have almost nothing in common in their tooling needs.
Economy-heavy and live games need a dedicated economy design tool. A spreadsheet is not enough.

What Is a Game Design Tool?

A game design tool is any software that helps a game designer define, communicate, test, or refine a game's design — its rules, systems, economies, flows, and content. It is not the software that builds or ships the game. It is the software that helps you figure out what to build before and during the time you're building it.

The distinction matters because most game designers underinvest in design tooling. They write a design doc in Google Docs, do their balancing in a spreadsheet that breaks after three weeks, and prototype flows in their head — then wonder why development keeps circling back to decisions that should have been settled earlier.

Good design tooling creates a single source of truth for game decisions. It makes invisible thinking visible. It lets you simulate consequences before they ship.

The 6 Categories of Game Design Tools

1. Documentation Tools

Documentation tools are where design decisions live in written form. This includes game design documents (GDDs), feature specs, system overviews, content databases, and design wikis.

What they're for: Creating a shared understanding of what the game is, how it works, and why decisions were made.

Common tools: Notion, Confluence, Google Docs, Coda.

What to look for: Structure, searchability, and ease of linking between documents. A GDD nobody can navigate is a GDD nobody reads.

Where they fall short: Documentation tools record decisions. They don't help you make them. You can write a perfectly formatted GDD for a broken economy system — the doc won't tell you it's broken.

2. Whiteboard and Visual Thinking Tools

Before a design becomes a document, it usually becomes a diagram. Whiteboards — physical or digital — are where designers map core loops, sketch progression systems, plan content hierarchies, and run early workshops with their teams.

What they're for: Visual thinking, early-stage system mapping, team alignment sessions.

Common tools: Miro, FigJam, Excalidraw, Mural.

What to look for: Speed. Whiteboard tools should be frictionless. If it takes five minutes to set up a board, you'll stop using it.

Where they fall short: Everything on a whiteboard is manual. There's no data, no logic, no simulation. A diagram of your economy system looks correct until you actually run the numbers.

3. Prototyping Tools

Prototyping tools let designers create low-fidelity representations of a game's user experience — usually focused on screens, flows, and UI interactions rather than underlying systems.

What they're for: Testing player-facing flows before they're built. Onboarding sequences, store layouts, menu structures, tutorial flows.

Common tools: Figma, Adobe XD, Marvel, Axure.

What to look for: The ability to link screens and simulate basic interactions. Good prototyping tools let a non-engineer share a clickable flow with a developer or producer without needing a build.

Where they fall short: Prototyping tools are surface-level by design. They show you how the game looks to a player, not how it works underneath. A beautifully prototyped store screen can still ship with a broken economy behind it.

4. Game Systems and Economy Design Tools

This is the category most indie designers underinvest in — and the one that causes the most expensive problems later.

Game systems design tools help you model the underlying logic of a game: resource flows, currency systems, progression curves, loot tables, crafting systems, and reward structures. Economy design tools are a specialized subset focused specifically on virtual economies — how currencies are generated, how they're spent, how items move through the system, and how player behavior interacts with all of it.

What they're for: Designing and testing game systems before (and during) development. Understanding how your economy behaves under player pressure, not just on paper.

Common tools:

Spreadsheets (Google Sheets / Excel): The default. Good for static models, bad for simulation and scale.
Machinations: Node-based visual tool for resource flow diagrams and system simulation.
itembase: Purpose-built platform for game economy design and simulation. Designed for F2P, mobile, and live games where virtual currencies, items, progression systems, and LiveOps events need to work together. Lets you simulate how your economy behaves over time — not just how it's structured on paper.

What to look for: The ability to model your actual game objects (items, currencies, events) — not just abstract flows. And the ability to simulate player behavior against your design, not just calculate static outputs.

Where spreadsheets fall short: Spreadsheets calculate. They don't simulate. They show you the expected value of a gacha pull, but they can't show you what happens to your premium currency supply after 10,000 players play through your first season. For any economy-heavy game, you need a tool with a real simulation layer.

5. Game Balancing Tools

Balancing tools help designers tune numbers — combat values, difficulty curves, progression pacing, drop rates, economy ratios. This overlaps with economy design but focuses more on feel and fairness than on systemic behavior.

What they're for: Making sure the game is the right difficulty, that progression feels rewarding, that combat numbers make sense, and that no single strategy dominates.

Common tools: Spreadsheets (again), GameAnalytics for post-launch data, custom internal tools at larger studios.

What to look for: Visual feedback on curves. A table of 200 enemy stats is hard to reason about; a chart showing how difficulty scales by level is immediately interpretable.

Where they fall short: Most balancing happens reactively — after players complain. Proactive balancing, where you simulate player behavior before shipping, requires a tool that actually models the player, not just the numbers.

6. LiveOps Tools

LiveOps tools help designers plan, execute, and analyze the ongoing operation of a live game — seasonal events, limited-time offers, battle passes, promotional bundles, push notifications, and AB tests.

What they're for: Managing the game as a service after launch. Planning what happens, when, and why — and understanding the economy impact before it goes live.

Common tools:

Airtable / Notion: For event calendars and content planning.
Braze / OneSignal: For push notifications and player communication.
GameAnalytics / Amplitude: For post-launch analytics.
itembase: For simulating the economy impact of live events before they ship — e.g., what a double-drop weekend does to your currency supply, or how a new bundle affects your IAP conversion over the next 30 days.

What to look for: The ability to connect planning with consequence. Most LiveOps tools tell you what happened after the fact. A simulation tool tells you what will happen before you commit.

How Game Type Affects Your Tool Stack

Not every game needs every category. Here's how the stack shifts depending on what you're building:

Game type	High priority	Lower priority
Narrative / story game	Docs, prototyping, whiteboard	Economy tools, LiveOps
Puzzle / arcade mobile	Prototyping, balancing	Economy simulation, LiveOps
F2P RPG / strategy	Economy design, balancing, docs	—
Idle / clicker game	Economy simulation, balancing	Prototyping
Live service / GaaS	Economy design, LiveOps simulation, analytics	—
Battle pass game	Economy design, LiveOps planning, docs	—

If your game has a virtual economy — any game with currencies, items, progression gating, or live events — economy design tools are not optional. They're where the most consequential design decisions get made.

The Tool That's Usually Missing

Across all of these categories, the most common gap for indie and mobile designers is a dedicated game economy design tool.

Most designers start with a spreadsheet and never upgrade. Spreadsheets are fine for simple static models, but they break down quickly when your economy has multiple currencies, interconnected systems, and live events that interact with each other. They don't simulate. They don't visualize behavioral dynamics. And they turn into unmaintainable messes the moment another designer touches them.

itembase was built to fill this gap. It's a game economy design and simulation platform — not a generic system tool, but one built specifically around how live game economies work: items, currencies, progression systems, event structures, and player behavior modeled together. Designers use it to design economies visually, simulate how players move through them, and test LiveOps decisions before they go live.

If you're building a game with any kind of economy layer, it's worth exploring: itembase.dev

Frequently Asked Questions

What is a game design tool?

A game design tool is any software that helps a game designer document, prototype, model, simulate, or communicate a game's design. This includes documentation platforms (Notion, Confluence), visual thinking tools (Miro, FigJam), prototyping tools (Figma), systems and economy design tools (itembase, Machinations), balancing tools, and LiveOps platforms. Game engines like Unity and Unreal are development tools, not game design tools.

Is Unity a game design tool?

Not primarily. Unity and Unreal Engine are game development and runtime tools — they're where you implement and run a game. Game design tools are what you use before and during development to figure out what to build: how the systems work, what the economy looks like, how the UI flows. Some rapid prototyping happens in engines, but treating an engine as your primary design tool leads to expensive rebuild cycles.

What tools do game designers use?

Most game designers use a combination of tools across different categories: Notion or Google Docs for documentation, Miro or FigJam for visual thinking, Figma for UI prototyping, Google Sheets or itembase for game balance and economy design, and Airtable or analytics platforms for LiveOps. The exact stack depends heavily on the type of game being built.

What is the best game design tool for economy-heavy games?

For games with virtual currencies, items, progression systems, or live events, itembase is purpose-built for game economy design and simulation. It's designed specifically for F2P, mobile, and live service games where a spreadsheet isn't sufficient for modeling how the economy will actually behave under player load.

Do indie developers need game design tools?

Yes — arguably more than large studios. Indie developers don't have the safety net of large QA teams or the runway to rebuild systems that shipped broken. Good game design tooling lets a small team make confident decisions early, which is the most leverage a solo developer or small indie team can get.

What is the difference between a game design tool and a game engine?

A game engine (Unity, Unreal, Godot) is software for building, running, and shipping a game. A game design tool is software for designing the game — its rules, systems, economies, and flows. Design tools are used to make decisions; engines are used to implement them. Most professional designers use both, but they serve completely different purposes.

Build Your Design Stack

If this guide made you realize you're missing a tool for your economy or live game design work, itembase is a good place to start.

Explore itembase → itembase.dev

Best Game Design Tools for Indie and Mobile Game Designers

Hiroshi TK — Tue, 12 May 2026 08:33:41 +0000

Good game design doesn't happen in your head. It happens in tools — docs, diagrams, spreadsheets, simulators — and the quality of those tools directly affects the quality of your decisions. This guide covers the best game design tools across every discipline indie and mobile designers actually need: documentation, prototyping, systems design, economy balancing, and LiveOps planning.

We'll also tell you where each tool falls short, so you can build a stack that actually fits how you work.

TL;DR — Key Takeaways

No single game design tool does everything. The best designers use a focused stack.
For docs and GDDs: Notion or Confluence.
For prototyping and flow: Figma or Miro.
For systems and logic: Machinations or a custom spreadsheet.
For game economy design, balancing, and LiveOps simulation: itembase is purpose-built for it.
Free-to-play and live game designers specifically need a tool that handles currencies, progression, and event simulation — most general tools don't.

What Makes a Game Design Tool Actually Useful?

A game design tool is useful when it reduces the gap between your idea and a testable, shareable representation of it. That sounds obvious, but most tools fail this test in practice — they're either too generic (Google Docs), too complex for a small team (full Jira setups), or designed for a different discipline entirely (Figma is a UI tool, not a systems tool).

The best game design tools have three things in common:

They match the abstraction level of the problem. Economy tools should think in currencies and sinks. Prototyping tools should think in screens and flows.
They make your thinking visible. A designer who can't show their system to a developer or producer is a bottleneck.
They let you iterate fast. If changing one variable requires updating fifteen cells across three sheets, the tool is working against you.

With that framing, here's the breakdown.

Game Documentation Tools

Notion

The go-to for indie teams doing game design documentation. Notion handles GDDs, wikis, task tracking, and meeting notes in one place — which matters a lot when you're a team of two.

Best for: Game design documents, feature specs, worldbuilding wikis, content tables.

Limitations: Not built for real-time design collaboration or visual systems. Anything that needs to be diagrammed will end up as a workaround.

Free tier: Yes, generous for small teams.

Confluence (Atlassian)

Standard at mid-sized studios, especially those already using Jira. More structured than Notion, better for cross-team documentation at scale.

Best for: Teams of 5+ with existing Atlassian infrastructure.

Limitations: Overhead is high for indie teams. Slower to iterate. Costs add up.

Google Docs / Sheets

Not glamorous, but still the most universal tool in game design. Practically every designer has a game balance spreadsheet that started in Google Sheets.

Best for: Quick GDDs, balance scratch work, sharing with external collaborators.

Limitations: No structure enforcement, no simulation capability, version control is manual.

Prototyping and Wireframing Tools

Figma

The industry standard for UI/UX prototyping. If you're designing menus, HUDs, onboarding flows, or store layouts, Figma is the tool.

Best for: UI flows, screen-by-screen mobile game prototyping, asset layout.

Limitations: Figma is a visual design tool, not a game logic tool. It can't tell you whether your economy works — only whether it looks good.

Free tier: Yes.

Miro

A digital whiteboard. Surprisingly powerful for early game design work — mapping core loops, sketching progression systems, running design workshops with a distributed team.

Best for: Visual thinking, early-stage systems sketching, team workshops.

Limitations: Everything is manual. There's no logic layer, no simulation, no data.

Excalidraw

Lightweight, open-source whiteboard. Great for quick diagrams you need to share fast.

Best for: Throwing a rough systems diagram in a doc or Slack message.

Limitations: Aesthetic tool only — no computation.

Game Systems and Economy Design Tools

This is where most indie designers have the weakest tooling — and where the most important design decisions get made.

Google Sheets / Excel

The default. Every game designer has done economy work in a spreadsheet at some point. It's flexible, everyone knows it, and it's free.

Best for: Static economy models, early-stage currency math, quick balance checks.

Limitations: Spreadsheets don't simulate player behavior. They calculate what should happen, not what will happen. They also fall apart fast as your economy gets complex — linked sheets, broken formulas, no version history.

Machinations

A visual tool for designing and simulating game systems. Uses a node-based diagram to represent resource flows, and can run simulations over time.

Best for: Resource flow diagrams, systemic game design, academic-style system modeling.

Limitations: Steep learning curve. Better for systems designers than for economy-focused live game designers who need to work with real game data (items, currencies, events, seasons).

itembase dev

itembase is a game economy design and simulation platform built specifically for designers working on economy-heavy and live games — F2P mobile, idle games, battle pass systems, seasonal events.

Where spreadsheets show you static math and Machinations shows you abstract flows, itembase lets you define your actual game items, currencies, and economy rules, then simulate player behavior against them. You can model a battle pass, run a seasonal event schedule, test a gacha pull rate, or project how a new resource sink affects your economy over 30 days — and see it visually.

Best for: F2P economy design, LiveOps planning, balancing virtual currencies, battle pass design, game monetization design, progression systems.

Why it's different: It's the only tool in this list designed around the concept of a live game economy — not just static balance or abstract flows.

Try it: itembase.dev

LiveOps Planning Tools

Notion / Airtable

Most teams manage their LiveOps calendar in a doc or spreadsheet. Airtable is a step up — it adds views, filters, and relational data to what would otherwise be a flat calendar.

Best for: Event scheduling, content calendars, release planning.

Limitations: No simulation. You can plan an event in Airtable, but you can't test whether the economy impact of that event will cause inflation or kill your player retention.

itembase dev(LiveOps Simulation)

For designers who want to go beyond planning and actually test their LiveOps decisions before shipping, itembase lets you simulate the economy impact of an event. What happens to your premium currency supply if you run a double-drop weekend? What does a limited-time bundle do to your IAP conversion curve? These aren't questions a calendar tool can answer.

Best for: LiveOps economy modeling, event impact simulation, season design.

The Recommended Stack for Indie and Mobile Designers

Need	Tool
Game design document	Notion
UI / screen prototyping	Figma
Visual systems sketching	Miro
Static balance math	Google Sheets
Game economy design + simulation	itembase
LiveOps planning (calendar)	Notion / Airtable
LiveOps economy simulation	itembase

You don't need all of these on day one. But if you're building a F2P game with a virtual economy — any game with currencies, items, progression systems, or live events — you need something more than a spreadsheet. That's the gap itembase is built to fill.

Frequently Asked Questions

What is a game design tool?

A game design tool is any software that helps a game designer document, prototype, model, simulate, or communicate their game's design. This includes documentation tools (Notion), visual prototyping tools (Figma), systems modeling tools (Machinations), and economy simulation tools (itembase).

What tools do indie game designers use?

Most indie designers use a combination of Notion for documentation, Figma for UI, Google Sheets for balance math, and either Machinations or itembase for systems and economy work. The exact stack depends on the game type — economy-heavy games need dedicated economy tooling.

Is there a game design tool specifically for game economies?

Yes. itembase is purpose-built for game economy design and simulation. It's designed for designers working on F2P, mobile, and live games where virtual currencies, items, progression systems, and LiveOps events need to be designed, balanced, and tested together.

What's the best free game design tool?

For documentation, Notion has a generous free tier. For UI prototyping, Figma is free for individuals. For economy and systems work, itembase offers free access to start building and simulating your game economy.

Do I need a game design tool if I'm a solo developer?

Yes — arguably more than a team does. Solo developers can't rely on verbal alignment or shared context. A tool that makes your design visible and testable is what keeps your project from drifting as it grows.

Start Designing Your Game Economy

If you're building a game with any kind of virtual economy — currencies, items, progression, loot, events — try itembase. It's the game design tool built specifically for economy-heavy and live games.

Try itembase free → itembase.dev

This is how Gacha Games get ya. Game Design Deconstruction and Simulation

Hiroshi TK — Tue, 21 Apr 2026 12:29:18 +0000

You open the app. You have 10 pulls saved. You know the odds. You know there's a 1.6% chance of getting the legendary you want. You pull anyway. Then you pull again. Then you're somehow buying the starter pack.
This is not a bug. It's a system that was designed, tuned, and simulated before it ever shipped. Let's pull it apart.

What is Gacha, actually
Gacha comes from "gashapon" - those Japanese vending machines where you put in a coin and get a random toy capsule. The digital version is the same concept: you pay (or earn) currency, and you get a random item from a pool with different rarities.
The fantasy is that you might get the legendary. The reality is that the probability is carefully engineered so you almost never do — at least not right away.
Gacha is everywhere now. It's in Genshin Impact, in every mobile RPG, in FIFA Ultimate Team packs, in battle pass loot pools. And the reason it's everywhere is that it works.

The Probability Table
Here's the actual mechanic: every item has a rarity tier, and every rarity tier has a weight. At pull time, the game runs a weighted random - it picks a number, and based on where that number lands in the distribution, you get common, rare, epic, or legendary.

A simple table might look like this (raw weights, not percentages):

--------------------
Rarity    |   Weight
--------------------
Common    |       80
Rare      |       17
Epic      |      2.5
Legendary |      0.5 
--------------------

To convert to probability: divide each weight by the total (100). So legendary = 0.5%. That's 1 in 200 pulls on average.
But "on average" is doing a lot of heavy lifting there. On average doesn't mean after exactly 200 pulls you're guaranteed one. You could hit it on pull 3. You could also go 600 pulls without one. That's the variance, and variance is what makes it feel exciting and unfair at the same time.

The Expected Value Trap

Here's where it gets mathematically interesting. The probability of NOT getting a legendary in a single pull is 99.5%. After 10 pulls, your chance of still having zero legendaries is 0.995^10 = 95.1%. After 100 pulls: 0.995^100 = 60.6%. After 200 pulls: 36.7%.
So even at the "average" pull count, you have a 37% chance of still not having it. This is why gacha feels rigged even when it isn't. You are fighting the geometric distribution, and it has no memory - each pull is independent.
This is exactly the psychology the system exploits. Humans are bad at geometric distributions. We expect things to "average out" sooner than they do, and when they don't, we feel like we're due. The gambler's fallacy is built into our intuition, and gacha banks on it.

Pity Systems: Designed Mercy

To prevent players from quitting in frustration (or the PR disaster of someone going 1000 pulls dry), gacha games introduced pity systems.
There are two flavors.
Hard pity is a guarantee. After N pulls without a legendary, the next pull is forced to be legendary. Genshin Impact does this at 90 pulls for 5-star characters. It's a ceiling on how bad your luck can be.
Soft pity is more interesting. It's a gradual increase in legendary probability as your pull count rises. Genshin starts increasing 5-star rates around pull 74 and ramps sharply toward 90. This means most players hit their legendary somewhere in the 75-90 range - it feels like the system "knew" they'd been struggling, even though it's just probability math.
The emotional effect of soft pity is powerful. Players report it feeling "fair" and "generous" - even though the baseline rates are still extremely low, and the guarantee just means you're spending more currency to get there in the worst case.

Simulating the System

I built a simulation of exactly this in itembase.dev/sim. Here's what the probability table in the sim looks like across 10 pull stages (columns 0 to 9):

Each column is a "stage." The simulation starts at column 0 (first pull) and advances one column each pull, cycling back to 0 after column 9.
Notice what's happening: at pull 0, you literally cannot get anything except common. The system is intentionally withholding. By pull 4, legendary opens up at 5%. By pull 9, you're at 18% for legendary. And then it resets.
This is a soft pity cycle compressed into 10 pulls. The weights are not real-world gacha numbers — they're tuned for the simulation to be demonstrative. But the architecture is identical to what actual gacha games ship.

The Node Graph: What's Actually Running

The simulation runs as a node graph where each tick executes this logic:

Read the current pull stage (signal.col)
Pull a column from the probability table using that index
Run a weighted random against the column's weights — this picks a rarity index 0 to 3
Map the index to a rarity name (common / rare / epic / legendary)
Display it in the center
Increment the counter for that rarity
Advance the column by 1, and if it hits 10, reset to 0

That's it. No hidden variables, no secret streaks. Just a weighted random on a rotating probability table.

The counter table on the side accumulates every rarity dropped. After a long run, you start seeing the distribution converge toward the expected values - but getting there takes hundreds of pulls, which is exactly the point.

Why It Works Psychologically
A few things are happening beyond the math.
Variable reward schedules. This is the core mechanism, borrowed directly from behavioral psychology. Random rewards at variable intervals are more addictive than fixed ones. Your brain releases more dopamine in anticipation of a possible reward than for a guaranteed one. Gacha is a slot machine with a character portrait.
Sunk cost framing. Every pull you make is a step closer to pity. You can literally see your progress. Walking away at pull 60 "wastes" the 60 pulls you already did. This framing isn't rational, but it's effective.
Social pressure. Limited banners, time-limited characters, your friends already having the thing — these are scarcity and social proof layered on top of the probability system. The odds are already against you, and now there's a countdown timer.
Near-misses. Getting an epic when you wanted legendary feels like almost winning. The near-miss activates the same response as a win in some players. Gacha is full of near-misses.

Try the Simulation Yourself
The full simulation is live at itembase.dev/sim. You can run it, watch the counter fill up, edit the probability table, and experiment with different pity curves. It's built in itembase, a sandbox tool for game designers - you can modify the node graph, change the weights, build your own drop table logic.
If you're designing a gacha system, or just want to understand what you're playing, watching it run a few hundred times is more informative than any percentage tooltip in a menu.
The math isn't hidden. The design isn't mysterious. It's a weighted random on a rotating table, wrapped in particle effects and character animations. Knowing that doesn't make it less compelling - but it makes you a harder target.

Your indie game didn't fail because of bad code. It failed because of bad design.

Hiroshi TK — Thu, 16 Apr 2026 08:44:23 +0000

I've had this conversation more times than I can count.

Someone tells me they're making a game. I ask what they do on the project. "I'm a game developer," they say. I ask if they have a game designer. Blank stare. "Isn't that the same thing?"

No. It is not the same thing. And this confusion this seemingly harmless mix-up is quietly killing indie games before they ever have a chance.

Let me be blunt about what game design actually is

Game design is not making assets. It's not writing code. It's not even making levels, necessarily.

Game design is the discipline of making decisions about how a game feels, behaves, and communicates with the player. It's asking: what does the player do, why do they do it, and how do they feel when they do?

A game designer decides that the jump in a platformer should have 12 frames of coyote time. They decide that a reward should come every 90 seconds on average to maintain engagement. They write the design document that explains why a mechanic exists and what it's supposed to accomplish emotionally.

A developer builds the jump. A designer decides what the jump should feel like and why it matters to the player.

Neither role is more important than the other. But they are completely different jobs, with completely different skill sets, and completely different ways of thinking about problems.

Why does this confusion exist?

Honestly? Because the word "game" is in both titles and that's enough to make people assume they overlap.

There's also a cultural thing happening. Game development tutorials are everywhere. You can learn Unity in a weekend. You can ship a prototype in a game jam. So when someone wants to make games, they learn to code, they make something that runs, and they call themselves a game developer. Which is completely valid.

But game design isn't taught the same way. It doesn't have a tutorial. You can't just follow along and produce an output. It requires studying player psychology, understanding feedback loops, analyzing what makes an interaction feel satisfying and then making thousands of small decisions that nobody notices unless they go wrong.

So most indie devs skip it. Or more accurately, they do it accidentally, without realizing it, and without the vocabulary or frameworks to do it well.

Here's where indie games actually die

I want to push back on something the indie dev community tells itself.

We love blaming failure on marketing. "The game was good, it just didn't get seen." Sometimes that's true. But more often and I say this as someone who has played a lot of indie games the game wasn't good. The core loop wasn't satisfying. The progression felt arbitrary. The player never understood what they were supposed to want.

That's not a code problem. The code works fine. That's a design problem.

A technically perfect game with a broken design loop will feel like work. Players will put it down in 20 minutes and not know why. They'll say "it wasn't for me" but what they mean is "I was never told why I should care."

Player retention, the feeling of progression, the moment-to-moment satisfaction of interacting with your game world all of that is designed, intentionally, by someone who understands systems and psychology. When nobody on your team is doing that job, it shows.

What game design actually looks like in practice

Here's a simple example. You're making an RPG. You add a loot system enemies drop gear. A developer's job is to make it work: the drop rate is a float, the item table is populated, the UI shows the item when it drops.

A designer's job is to decide: what drop rate creates excitement without frustration? How rare is rare enough to feel special, but not so rare the player gives up? Should legendary drops feel surprising or expected? What's the emotional beat of getting a rare drop and how do you amplify it through sound, animation, and UI so it actually lands?

That's the work. It's invisible when it's done well. It destroys games when it's missing.

So what do I actually want you to take from this?

If you're building an indie game solo or with a small team, I'm not saying you need to hire a dedicated game designer. I'm saying you need to do the game design intentionally, explicitly, not as an afterthought.

That means before you code a system, you ask: why does this exist? What is the player feeling when they interact with it? What behavior am I incentivizing?

It means playing your own game critically, not just testing if the bugs are gone, but asking: is this fun? Why or why not? What would make this feel better?

It means understanding that "it's not fun yet" is a design problem with a design solution not a bug to be fixed or a feature to be added.

Most indie games fail because someone built a technically functional product and called it done. Design is the gap between "it works" and "I can't put this down."

Are you an indie dev who does both roles yourself, or do you have a dedicated designer on your team? I'm curious how others split this drop a comment below.