Ask any game designer what tools they use and you'll get a surprisingly scrappy answer. The reality is far from polished - and that's exactly what makes this space interesting.
There's a recurring thread that pops up in game design communities every few months. Someone asks: "What tools do you use for level design?" And the answers are always a mix of the expected and the surprising.
Draw.io. Google Sheets. Blender. Pen and paper. MS Paint.
Yes, Paint. And not ironically.
The truth is, game design tooling is still a remarkably unsettled space. Unlike concept art (where everyone gravitates toward Photoshop or Procreate) or 3D modeling (Blender, Maya, ZBrush), game design — particularly level design and systems design — doesn't have a clear default. Designers piece together workflows from general-purpose tools, engine-specific editors, and a lot of improvisation.
That gap says something important about where the craft is right now — and where it's going.
The Case for Simple Tools
One of the more interesting arguments that comes up in designer communities is that simplicity isn't a limitation — it's a feature.
The logic goes like this: if you're using a tool as basic as Paint to sketch a level, you physically cannot get distracted by polish. You're forced to think in terms of space, flow, and structure. Individual pixels become tiles. Color becomes function, not decoration. It's crude, but it keeps you honest about what you're actually designing.
Graph paper works on the same principle. Some designers swear by custom grid templates that enforce consistent scale across sketches — a constraint that keeps prototyping fast while maintaining spatial accuracy. When you need to iterate on a Metroidvania map or an RTS battlefield, speed of thought matters more than visual fidelity.
The takeaway isn't that sophisticated tools are bad. It's that the best tool is the one that matches the speed of your thinking at each stage of design.
The Tools Designers Actually Reach For
Based on community discussions, studio workflows, and what keeps showing up in real production, here's what the landscape actually looks like.
Mapping and Spatial Layout
Tiled and LDtk are the go-to dedicated editors for 2D level design. LDtk, built by the creator of Dead Cells, has earned a loyal following for its auto-tiling and entity placement. Tiled has been around longer and has broader engine integration. Both are free and open source.
For 3D, most designers work directly inside their engine. Unity's ProBuilder and Unreal's BSP tools handle blockouts. Some designers still use Blender for early spatial prototyping — not ideal in theory (you should prototype in the engine you're shipping in), but in practice, familiarity wins. If you know Blender's shortcuts by muscle memory, you'll iterate faster there than in an editor you're still learning.
TrenchBroom serves a niche but passionate community building retro FPS-style levels.
Documentation and Planning
Google Sheets combined with draw.io is a surprisingly common power combo. Sheets handle the systemic side — tracking what gameplay elements appear where, when new mechanics are introduced, managing pacing across an entire game. Draw.io handles the spatial and flow side — room connections, critical paths, gating logic.
The limitation of draw.io, as many designers note, is speed. Drawing in it is significantly slower than paper. But it earns its place when you know you'll be rearranging elements across many iterations — moving loot placement, adjusting enemy spawns, reorganizing secrets. You build the base layout once, then shuffle components on top of it.
Figma and Miro show up increasingly for collaborative level planning, especially on remote teams. Microsoft Visio is powerful but expensive — Open Office Draw does much of the same job for free.
For narrative-driven or progression-heavy games, the Rational Level Design (RLD) framework deserves mention. It's a structured methodology for planning levels around player experience curves, and Google Sheets happens to be an excellent tool for implementing it — tracking intensity, introducing mechanics, and ensuring the game doesn't swing between boring and overwhelming.
Procedural and Generative Tools
For games with procedural elements, the tooling shifts. Wave Function Collapse libraries, Houdini for rule-based generation, and custom scripts are common. Procedural level design creates a unique challenge: you need to iterate not on individual levels, but on the rules that generate them. This requires heavy testing and simulation — running your generator hundreds of times to find edge cases where it produces unplayable or trivially easy results.
Where the Real Gap Is: Systems and Economy Design
Level design — despite the scrappy tooling — has a relatively clear workflow. You sketch, you blockout, you playtest, you iterate. The feedback loop is visual and intuitive. You can see when a room feels wrong.
Game economy design doesn't have that luxury.
Economies — the resource flows, progression curves, crafting loops, reward schedules, and currency sinks that define how a game feels over tens or hundreds of hours — are invisible systems. You can't look at a spreadsheet of drop rates and feel whether the mid-game grind is too punishing. You can't eyeball a conversion formula and know if players will run out of crafting materials at hour 15.
This is where the tooling gap gets serious.
Most studios still model economies in spreadsheets. And spreadsheets are genuinely good for certain economy tasks — defining item tables, calculating expected values, setting up price curves. But they model economies as static snapshots. They answer "what are the numbers?" but not "what happens when someone actually plays with these numbers for 100 hours?"
Machinations was one of the first tools to address this, introducing a node-based visual language for modeling game economies as resource flow networks. It brought academic rigor to a problem that was previously solved through intuition and Excel. It works well for conceptual modeling and understanding flow dynamics at a high level.
Large studios often build custom internal tools. Supercell, Riot, and others have proprietary balance simulators tailored to their specific games. These work, but they cost significant engineering time to develop and maintain — and they're locked inside the company that built them.
The interesting evolution happening now is tools that combine visual economy design with actual simulation. Itembase.dev is a notable example — it uses a node-canvas approach where you build economy systems visually (resource sources, conversion nodes, conditional logic, sinks) and then simulate them. Instead of calculating a static output, you model a player going through hundreds of matches or progression stages and watch where the economy breaks.
The distinction matters. Designing an economy and simulating an economy are fundamentally different activities. A crafting loop can look perfectly balanced in a spreadsheet and still feel terrible in practice because the spreadsheet didn't account for how resource generation compounds over time, or how a player's changing needs shift which resources become bottlenecks.
Simulation-first tools let you ask temporal questions: What does the resource curve look like at hour 5 vs hour 50? Where do players hit dead zones? What happens if they make suboptimal choices? These are the questions that determine whether players stay or quit — and they're nearly impossible to answer without running the system forward in time.
Building Your Toolkit
There's no single tool that covers game design end to end. Most working designers use a layered approach:
For spatial design — start with the fastest sketch medium you're comfortable with (paper, Paint, Figma), move to a dedicated editor (Tiled, LDtk) or engine tools (ProBuilder, BSP) for production.
For documentation and flow — Google Sheets plus draw.io covers a surprising amount of ground. Upgrade to Figma or Miro if you need collaboration features.
For systems and economy design — spreadsheets for static parameters, a simulation tool for dynamic behavior. The more complex your economy, the more you need to actually run it before shipping it.
The common thread across all of these is that the best game design tools are the ones that keep you iterating. Fast sketching beats slow perfection. Simulated playthroughs beat theoretical math. And the tool that gets out of your way is always better than the one that impresses your team in a screenshot.
The craft is still evolving. The tools are catching up. The designers who build the best games will be the ones who pick the right tool for each stage of the process — and aren't afraid to use Paint when Paint is the right answer.
Top comments (0)