DEV Community: Hiroshi TK

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.

7 Game Design Tools

Hiroshi TK — Tue, 14 Apr 2026 08:05:19 +0000

The Game Design Tools I Actually Use (And Some I Wish I Knew Earlier)

Every game designer has a moment where they realize their workflow is held together with sticky notes, a 400-row spreadsheet, and pure delusion. I’ve been there. So here’s the list I wish someone handed me earlier, tools that actually help you design better games, not just document them.

A quick note on how I ordered this: roughly from “pick it up in an afternoon” to “okay, you’ll need a weekend.” Because the right tool depends on where you are, what you’re building, and whether you want to ship something or just endlessly prototype.

Twine — https://twinery.org/

If you’ve never shipped a game and want to start, Twine is the answer. It’s free, browser-based, and lets you build branching narrative games without writing a single line of code. The output is plain HTML so sharing your game for playtesting feedback is as easy as sending a link.

It sounds retro but the skill you’re actually building is nonlinear storytelling, which is one of the hardest things to get right in any genre.

Miro — http://miro.com/

The online whiteboard that quietly became essential for game design. Use it for systems maps, player journey flows, quest diagrams, anything that lives better as a visual than a doc. The real value is that it’s collaborative and real-time, so your whole team is looking at the same thing.

A Miro board full of sticky notes is not a game design. It’s a mood board. Keep that distinction clear.

Notion — https://www.notion.so/

Underrated as a GDD tool. Notion lets you structure your design documentation in a way that’s actually readable and linkable, versus a Google Doc that turns into a 60-page scroll of outdated information.

Where it falls short: anything involving numbers, probabilities, or simulating outcomes. A table in Notion is just a table. It won’t tell you what your economy actually does.

Itembase Simulator — https://itembase.dev/sim

This one doesn’t get talked about enough. The simulator at itembase.dev lets you model game mechanics as a node graph and run simulations to see how they actually behave. Not how you think they’ll behave. How they actually play out across thousands of iterations.

Spreadsheets lie to you. You put a 30% drop rate in a cell, it stays 30% forever. But players don’t experience percentages, they experience streaks, dry spells, and lucky runs. A simulator shows you that. It also shows you where your reward loops break down before a developer writes a single line of code.

Free to use, no login required to poke around.

Articy Draft — https://www.articy.com/en/

If you’re building an RPG or any game with serious narrative branching, Articy Draft is built for it. It handles dialogue trees, character databases, story flow, and design documents all in one place. Variants and conditions stay manageable instead of spiraling into chaos.

There’s a learning curve but it pays off fast once your narrative gets complex.

itembase.dev — https://itembase.dev/

If you’re past the napkin sketch stage and actually designing a game economy, itembase.dev is worth bookmarking. It’s a visual platform that lets you manage your entire economy in one place: currencies, items, progression formulas, bundles, rarities, all connected and queryable. Want to know exactly how many coins a player earns per day at level 78? You can pull that without digging through five spreadsheets.

It also has a LiveOps timeline planner, import/export scripts, and a node-based plugin editor if you want to get fancy. The free beta is live right now so the barrier to try it is zero.

GameMaker — https://gamemaker.io/

When you want more control and you’re ready to write some code, GameMaker is the move. Its scripting language is approachable, the community is huge, and the number of commercial hits built on it should tell you it’s not a toy. Holocure, Undertale, Hotline Miami.

Check the current pricing model since it’s shifted around, but there’s a free tier to get started

Bottom Line

Most of these tools solve one specific part of the design problem: narrative flow, visual collaboration, documentation, or prototyping. The gap nobody talks about enough is simulation, which is understanding how your systems behave probabilistically before you commit to building them.

That’s the gap I tried to fill with the simulator at itembase.dev. If you’re spending hours tweaking numbers in a spreadsheet trying to guess how your economy will play out, go try it. It’s the thing I kept wishing existed before I built it.

Why You Can't Stop Playing: A Beginner's Guide to Game Design Psychology

Hiroshi TK — Tue, 07 Apr 2026 07:04:25 +0000

You've told yourself "just one more turn" in Civilization. You've stayed up way too late farming in Stardew Valley. You've opened a gacha pull knowing the odds are terrible.

None of that was an accident.

Behind every game that hooks you, there's a carefully designed system of psychological mechanics working together. In this post, I'll break down how game designers use psychology to create experiences players can't put down, and why understanding this matters whether you're building games, apps, or any product that relies on engagement.

What Even Is a "Game Mechanic"?

A game mechanic is any rule or system that defines how a player interacts with the game. Jumping is a mechanic. So is collecting coins. So is a cooldown timer on a spell.

But the interesting part isn't the mechanic itself. It's what it makes the player feel. And that's where psychology comes in.

Game designers don't just ask "what can the player do?" They ask "what will the player feel when they do it, and what will they want to do next?"

The Core Loop: The Heartbeat of Every Game

Every game, from Candy Crush to Elden Ring, is built on a core loop: the repeating cycle of actions a player performs over and over again.

A core loop typically follows this pattern:

Action → Reward → Progression → Action

Here's what that looks like in practice:

Game	Action	Reward	Progression
Animal Crossing	Catch fish, dig fossils	Bells (currency)	Pay off house debt, unlock upgrades
Diablo	Kill monsters	Loot drops	Better gear, higher difficulty
Duolingo	Complete a lesson	XP, streak counter	Unlock new levels, maintain streak

The loop works because each step feeds into the next. You act, you get rewarded, the reward unlocks something new, and that new thing gives you a reason to act again.

If the loop breaks (rewards feel meaningless, progression stalls), players leave. The loop is the game.

Dopamine and the Variable Reward Schedule

Here's where it gets neuroscience-y.

Your brain releases dopamine not when you get a reward, but when you anticipate one. And the most powerful form of anticipation comes from unpredictability.

This is called a variable ratio reward schedule, the same mechanism behind slot machines. You don't know when the reward will come, so your brain stays hyper-engaged waiting for it.

Games use this everywhere:

Loot drops in RPGs (will this enemy drop the rare sword?)
Gacha pulls in mobile games (will I get the SSR character?)
Critical hits in combat (random extra damage = random dopamine spike)
Procedural generation in roguelikes (every run is different, so every run might be the good one)

Compare this to a fixed reward schedule, where you get a reward every single time. It works at first, but the brain adapts fast and the reward stops feeling rewarding. This is why games that hand you a prize for literally every action start feeling hollow.

The magic ratio: rewards should feel earned but not guaranteed.

Loss Aversion: Why You Can't Break Your Streak

People are roughly twice as motivated to avoid losing something as they are to gain something of equal value. Game designers know this.

Examples of loss aversion in game design:

Daily login rewards that reset if you miss a day (you're not gaining a reward, you're avoiding the loss of your streak)
Durability systems where gear degrades (you play to maintain, not just to gain)
Energy/lives systems that refill over time (if you don't play now, you're "wasting" free energy)
Ranked decay in competitive games (stop playing and your rank drops)

This is one of the most powerful, and most controversial, tools in a game designer's toolkit. Used well, it creates meaningful stakes. Used cynically, it creates anxiety-driven engagement that burns players out.

The Endowment Effect and Sunk Cost

Once a player has invested time, effort, or money into something, they value it more than it's objectively worth. That's the endowment effect.

And once they've invested, they don't want to walk away and "waste" that investment. That's the sunk cost fallacy.

Games layer these together constantly:

You've spent 200 hours on your MMO character. Quitting feels like throwing that away.
You've built an elaborate base in a survival game. You have to log in to defend it.
You've almost completed a collection. You need just three more items. (This one also leverages the Zeigarnik Effect: our brains are wired to fixate on incomplete tasks.)

This is why free-to-play games front-load you with customization, collections, and progression systems before ever asking for money. By the time the paywall appears, you're already invested.

Flow State: The Holy Grail

Psychologist Mihaly Csikszentmihalyi identified flow as the mental state where you're fully immersed in an activity, challenged enough to stay engaged but not so challenged that you're frustrated.

In game design, flow lives in the balance between skill and difficulty:

Too easy → boredom
Too hard → frustration
Just right → flow (the "one more level" feeling)

Great games manage this through dynamic difficulty, adjusting challenge in real time:

Resident Evil 4 secretly makes enemies less aggressive if you die repeatedly
Racing games use "rubber banding" to keep AI opponents close
Mario Kart gives better items to players in last place

The player never notices. They just feel like they're having a great time. And that's the point.

Feedback Loops: Positive and Negative

Games use two types of feedback loops to shape the experience.

Positive feedback loops amplify success. The better you do, the more powerful you become, which makes you do even better. Think snowballing in a MOBA: one early kill leads to a gold advantage, which leads to better items, which leads to more kills.

Positive loops feel amazing when you're winning and terrible when you're losing. They create dramatic, decisive moments but can also make games feel unfair.

Negative feedback loops balance things out. They give struggling players a boost and hold dominant players back. Mario Kart's item system is the textbook example: blue shells exist specifically to punish the leader.

Most well-designed games use both. Positive loops for moment-to-moment excitement, negative loops to keep the overall experience competitive and fair.

Social Mechanics: Why Multiplayer Is Sticky

Humans are social creatures, and game designers exploit this ruthlessly:

Cooperative mechanics create social obligation (your guild needs you for the raid tonight)
Leaderboards trigger social comparison (you're not playing to have fun, you're playing to be higher than your friend)
Limited-time events create shared urgency and FOMO
Trading systems create interdependence (you need what I have, I need what you have)
Social proof shows you what other players are doing ("1.2 million players online now")

The most retentive games aren't the ones with the best mechanics. They're the ones where your friends are. This is why every modern game has social features, even single-player ones.

Putting It All Together: The Player Journey

A well-designed game layers all of these systems across the player journey:

1. Onboarding (0-5 minutes): Hit the player with quick wins and immediate positive feedback. Teach mechanics through doing, not reading. Minimize friction. This is where you earn the right to their attention.

2. Early game (first session): Establish the core loop. Give clear goals and generous rewards. Let the player feel competent and curious. Introduce one system at a time.

3. Mid game (days/weeks): Deepen the loop with secondary systems like crafting, social features, and customization. This is where investment and sunk cost start building. Variable rewards become more important as fixed rewards lose their novelty.

4. Late game (months+): Shift motivation from extrinsic (rewards) to intrinsic (mastery, community, identity). Players who stay this long aren't staying for loot. They're staying because the game is part of who they are.

The Ethics Question

Everything I just described can be used to create joy or to exploit people. The line between "engaging design" and "manipulative design" is real, and every game designer has to decide where they stand.

A few questions worth asking:

Does the player feel good after they stop playing, or only while they're playing?
Are you designing for the player's enjoyment or for their wallet?
Would the player still engage with the mechanic if they fully understood how it worked?

The best games don't trick people into playing. They create systems so satisfying that people want to keep playing. That's the difference between a game you love and a game you're trapped in.

Where to Go From Here

If this sparked your interest, here are some resources to go deeper:

"A Theory of Fun for Game Design" by Raph Koster: the classic intro to why games work
"Hooked" by Nir Eyal: product design perspective on habit-forming systems (applies directly to games)
GDC Vault (gdcvault.com): free talks from professional game designers
"The Art of Game Design" by Jesse Schell: comprehensive and practical

Game design psychology isn't just useful for making games. If you're building any product where engagement matters (apps, learning platforms, productivity tools), these same principles apply.

The question isn't whether you're designing for psychology. You always are. The question is whether you're doing it intentionally.

If you found this useful, drop a reaction or leave a comment with a game mechanic that's hooked you recently. I'd love to hear what's keeping you playing.

A Carnival Shooting Game Changed How I Think About Design

Hiroshi TK — Mon, 06 Apr 2026 13:54:48 +0000

A team built a target-shooting game for families. Playtests went great, everyone was smiling. Then someone noticed that men were consistently outscoring women.

It wasn't a skill gap. It was a strategy gap. One group sprayed targets for speed. The other lined up shots for accuracy. The game only rewarded one approach, which meant it was quietly failing half its audience.

The fix was absurdly small. And it changed everything about how I think about designing systems, not just games, but any product people interact with.

I wrote about what that fix was, why most designers fall into the same trap, and what playtesting actually teaches you when you pay attention.

Read the full piece on my blog → https://itembase.dev/blog-design-for-behaviors.html

Game Simulations Are Not About Realism. They Are About Better Design Decisions

Hiroshi TK — Mon, 06 Apr 2026 10:07:24 +0000

A lot of teams hear “simulation” and think of realism. More accurate physics. More detailed AI. More complexity.

That is usually the wrong goal.

A good simulation is not valuable because it is more realistic. It is valuable because it helps the game produce meaningful outcomes. Players make choices, systems respond, and the results feel earned rather than staged.

That is the real design value of simulation. It lets you stress-test loops, predict economy outcomes, and understand how a system behaves before production makes it expensive to change.

The key distinction is simple:

the model is the rules and variables
the behavior is what emerges when those rules run over time
the conceptual model is what the player understands about the system

If the player cannot explain why something happened, the simulation may be technically impressive but design-wise weak.

This is also why fidelity is often overrated. More detail is only useful when it creates better choices. If it just adds noise, cost, or opacity, it is not helping the product.

On the engineering side, the most important move is decoupling the simulation core from presentation. That makes faster stress tests, deterministic debugging, seeded reproduction, and long-term balancing much more practical.

I wrote the full piece here:

Read the full article: https://itembase.dev/blog-game-simulations.html
More game design articles: https://itembase.dev/blogs.html

Design for player motivations, not demographic labels

Hiroshi TK — Mon, 06 Apr 2026 09:47:53 +0000

The strongest games do not try to satisfy everyone equally. They create one clear experience with multiple valid ways for different players to enjoy it.

A lot of game design discussions get stuck on the wrong question. Teams ask whether they should design for one demographic or many. That framing sounds strategic, but it usually leads nowhere useful.

The better question is simpler: what kinds of player behavior is your game prepared to reward?

That shift matters because players do not arrive as neat marketing categories. They arrive with preferences, habits, motivations, and different definitions of what feels satisfying. Some players like speed. Some like precision. Some like mastery through repetition. Others like expression, experimentation, or support roles. If your design only recognizes one path to success, you are not just narrowing your audience. You are narrowing the game itself.

One of the most useful design patterns here is to support multiple expressions of skill inside the same system. A scoring model that rewards both volume and accuracy is a simple example. It does not water the game down. It makes the game more legible to more types of players. Different people can feel competent for different reasons while still participating in the same core loop.

This is where game design becomes product design.

From a design perspective, supporting multiple motivations can deepen a system. From a UX perspective, it helps players feel seen because the game acknowledges their preferred way to play. From an engineering perspective, though, every extra path adds balancing work, interface complexity, and tuning cost. And from a business perspective, broader motivational coverage can improve retention, but only if the game still has a sharp identity. Once a system becomes too flexible, it often stops being memorable.

That is why “make it for everyone” is such bad advice. It usually produces vague features, unclear progression, and a game that never fully commits to a point of view. But the opposite extreme is not right either. “Just make the game you personally want” sounds pure, yet it can become an excuse to ignore playtesting and player observation.

The stronger approach sits in the middle. Start with a clear intended experience. Then observe how different players actually engage with it. Where you see meaningful variation, ask whether the system can reward more than one style without losing coherence. If it can, that is not compromise. That is good design.

This principle is especially important for smaller teams. Indies do not have the budget to build for every audience. But they can often create surprising reach by letting adjacent motivations coexist within one elegant system. That is usually cheaper and more effective than adding raw content scale.

In practice, the design question is not “which demographic are we targeting?” It is “what kinds of players can feel smart, expressive, or successful in this game, and how clearly does the system communicate that?”

That is a much more useful lens. It leads to better mechanics, better onboarding, better balancing, and often a more resilient product.

Conclusion

Games get stronger when they stop chasing labels and start rewarding real player behavior. A focused experience with room for different motivations will usually outperform a broad, blurry attempt at mass appeal.

Read more game design articles: https://itembase.dev/blogs.html

The Modern Game Designer’s Toolkit

Hiroshi TK — Fri, 27 Mar 2026 07:36:36 +0000

Game design is not just about creativity. It is about clarity, iteration, and communication. Whether you are working solo or in a team, the tools you use directly affect how efficiently you turn ideas into actual gameplay.

Here is a practical breakdown of essential tools every game designer should know, from simple staples to more advanced platforms.

1. Idea Mapping and Collaboration

Miro

Game design often starts messy. Systems connect, overlap, and evolve quickly. Miro helps bring structure to that chaos.

Great for brainstorming, flowcharts, and system mapping
Real-time collaboration with teams
Infinite canvas for exploring ideas without constraints

Use it to map:

Core gameplay loops
Player journeys
Feature relationships

2. Data, Balancing and Systems Design

Google Sheets

This is one of the most important tools in a designer’s workflow.

Build and balance economies
Define stats, progression, and scaling
Run lightweight simulations using formulas

Common use cases:

Weapon and character balancing
XP curves and leveling systems
Resource and currency economies

Learning formulas turns Sheets into a powerful design tool, not just a spreadsheet.

3. Specialized Game Design Tools

itembase.dev

As projects grow, keeping systems organized becomes harder. This is where itembase.dev becomes more than just a tool. It acts as a control room for your game.

Centralized place for all items, stats, and systems
Manage your entire game economy in one place
Keep everything consistent and scalable

But the real power comes from scripting.

Scripting in itembase.dev

itembase.dev allows you to go beyond static data and actually control how your game behaves.

Write scripts that define how systems work
Ship changes directly from itembase to the game without a middle layer
Manage and plan liveops from the same environment
Adjust economy, rewards, and behaviors without waiting on engineering

This turns itembase into a live control system, not just a database. You are not only storing your game design, you are actively running it.

Best suited for:

RPG systems
Economy-heavy games
Live service and continuously updated games

itembase.dev/sim

Simulation is where design decisions become testable.

Run simulations on your systems
Validate balance before implementation
Iterate quickly without needing engineering support

Instead of relying on intuition, you can test how your systems behave under real conditions before they go live.

4. How These Tools Work Together

A typical workflow might look like this:

Start in Miro to explore and structure ideas
Move to Google Sheets to define numbers and logic
Organize everything in itembase.dev
Simulate and validate using itembase.dev/sim
Use scripting in itembase.dev to push changes live and manage systems

This creates a pipeline from idea to live game without unnecessary friction.

Final Thoughts

Strong game design comes from a mix of creativity and structure. The right tools help reduce guesswork, improve iteration speed, and make collaboration easier across teams.

The biggest shift is moving from static design to live systems thinking. When your tools allow you to design, test, and operate your game in one place, you unlock a completely different level of control.

If you have other tools in your workflow, it is always worth comparing approaches. The way designers build their toolkits often defines how they design games.