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.
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
Top comments (0)