DEV Community: Sam Novak

Game Prototyping: How to Find the Fun Before You Build the Wrong Thing

Sam Novak — Fri, 29 May 2026 07:37:45 +0000

Most studios do not fail because the idea was bad. They fail because they spent too long on the wrong version of it. Prototyping fixes that.

The Four Stages

Every solid prototyping workflow runs through the same loop. Skip a step and you pay for it downstream.

01 | Define core mechanics
Find the essential interactions. Test them alone. If they are not fun in isolation, they will not become fun under complexity.

02 | Rapid prototyping
Move from concept to playable as fast as possible. Speed here is a discipline, not a shortcut.

03 Feedback and iteration
Real players, short cycles. Your team already knows too much to give you clean signal.

04 | Concept validation
Does the prototype answer its own question? That is the only job it has right now.

Common Mistakes

01| Overambitious scope — Lock the core loop before layering anything else on top. Complexity hides broken mechanics.

02| Skipping feedback — Short cycles with real users consistently beat long internal reviews.

03| Polishing too early — If it looks great before it plays great, you have made a mistake more expensive to delete.

04| Poor onboarding — If players cannot figure it out in the first session, the problem is the introduction, not the mechanic.

Metrics That Tell the Truth

Pick the one that answers the question your current prototype is asking. One question per prototype.

Win Rate
Level Churn
D1 Retention
CPI
Playtime

Seven Rules

01| Ugly is fine
You are testing the idea, not the aesthetics. Nobody ships a prototype.

02| Speed beats polish
A prototype in three hours beats a mockup that took three weeks.

03| Real users, not teammates
Your team already knows too much. They cannot unsee what they built.

04| One question per prototype
If you cannot name the question it is answering, it is not a prototype.

05| Kill bad ideas early
A failed prototype costs a day. A failed product costs a year.

06| Do not fall in love with version one
The first prototype starts a conversation. It is not the answer.

07| Prototype the riskiest part first
Start where you are least certain. That is the part most likely to break everything.

Prototyping is not the step you skip. It is the step that saves everything that comes after it. Fail fast, learn faster.

Which rule hits closest to where you are right now? Drop it in the comments.

Should You Add a Battle Pass to Your Mobile Game in 2026?

Sam Novak — Wed, 27 May 2026 13:51:37 +0000

Should You Add a Battle Pass to Your Mobile Game in 2026?
Battle passes now appear in 60% of top-grossing mobile titles and drive 22% of all IAP revenue — but building one badly is worse than not building one at all.
The system works because it's a behavioral contract, not a reward track. Sunk cost keeps players logging in. Structured daily challenges eliminate decision fatigue. Seasonal exclusives create permanent social signals. Get the design wrong and you destroy both retention and trust at the same time.
Before you scope it: your D30 retention needs to be at or above 15%, your season completion rate should land between 40–60%, and your premium currency return should cover 50–70% of the pass price. If you can't hit those targets, fix your core loop first — the battle pass won't save a game players don't already want to play.
The full breakdown with KPIs, design principles, and a build/skip decision framework → itembase.dev

The Game Industry Burned?! Here's What's Actually Being Built in the Ashes.

Sam Novak — Tue, 26 May 2026 11:31:52 +0000

I want to start with an admission.
A few months ago I wrote a piece arguing that the game industry burning down was, in a strange way, interesting. That disruption is where the durable ideas come from. That constraint forces the decisions comfort keeps deferring indefinitely. People mostly agreed, some pushed back, and a handful — the ones who were actively losing their jobs at the time — pointed out that chaos is a lot easier to find interesting when you're not the one on fire.
They were right, and I've been sitting with that since.
So this follow-up isn't a victory lap. The industry isn't rebuilt. The ash is still warm in a lot of places. But I've been watching closely, and enough has shifted that I think it's worth talking about what the next chapter actually looks like — not the optimistic version, the observable one.
The studios that made it through didn't survive by finding some magic formula. They survived by getting honest about their cost structure before everyone else did. The ones now quietly hiring again aren't rebuilding what they had. They're coming back smaller, more deliberate, and reaching for tools that let tighter teams do what used to require bigger ones. That pattern keeps repeating across studios of different sizes and genres, which tells me it's not strategy — it's the market selecting for something.
The solo developer story is the one I find myself thinking about most, though. When I wrote the original piece I was careful not to romanticize it, because for most people it isn't a dream — it's what happens when the options narrow enough that you stop waiting for someone to hire you. But something genuinely shifted in the last year. The tooling caught up to the ambition in ways I didn't fully anticipate. The distance between what one person can ship and what a small team can ship has compressed, and it's starting to show up in the actual games coming out. You look at the credits, then you look at the game, and the math stops adding up the way it used to.
None of this is about any single tool, though. That's the thing I keep trying to say when people ask me what changed. It's not the AI art generators or the code assistants in isolation — it's the compounding effect of faster iteration everywhere, combined with something less glamorous that barely gets talked about: better frameworks for thinking through game economy and progression before you've written a single line of code.
The teams moving fastest right now aren't the ones with the best artists or the sharpest engineers. They're the ones who nailed their design logic early. Who stopped rebuilding their economy system every time a number felt off. Who found a way to simulate a decision before committing to it.
And that's where I think the real story is, because it points at something the industry got consistently wrong during the boom years. The bottleneck was never raw production capacity. It was decision-making speed. It was the ability to know — before month six, before the playtests, before you've sunk the budget — whether the economy you designed is going to feel rewarding or punishing or just quietly hollow in a way players can't articulate but definitely feel.
Big studios had people for this. Economy designers, analysts, internal simulation tools that never got written about because they weren't the interesting part of the postmortem. Everyone else had spreadsheets and the courage of their convictions. That gap is part of why so many mid-tier games shipped with broken economies — not poorly conceived ones, broken ones. The vision was fine. There was just no way to test whether the system actually behaved the way the designer imagined it would.
That gap is closing. Not closed — closing.
The next chapter of this industry isn't going to be written by whoever hires back the fastest or raises the biggest seed round. It's going to be written by the people who figured out how to move the hard thinking earlier in the process. Who got serious about validating their design before the build, so they weren't making structural decisions under deadline pressure with money already spent.
I know that sounds less exciting than "AI generates your sprites now." But I think it's actually the more important shift — and the one that will separate the games that feel designed from the ones that feel assembled.
The industry burned. Some of what burned needed to. The question is whether the people building now are making genuinely different decisions, or just making the same ones faster with better tools.
I'm betting on different. But I'm watching.

Most games don’t really have loot systems. They have reward calculators.

Sam Novak — Mon, 18 May 2026 10:39:33 +0000

Most loot systems today are mathematically optimized.

But very few are emotionally designed.

That’s the real problem.

A 0.9% legendary drop rate means nothing by itself. Players never experience “0.9%.” They experience anticipation, tension, disappointment, surprise, status, and memory.

And those emotions are shaped by far more than the spreadsheet.

The best loot systems were never just probability tables. They were social systems. A rare drop mattered because:

people witnessed it
the item changed player identity
the moment carried emotional weight
the rarity created stories players remembered for years

Modern systems often copy the visible structure:

rarity tiers
chest openings
weighted drop tables
pity systems

…but skip the invisible architecture that made those systems meaningful in the first place.

The result is a system that works mechanically, but feels hollow after a few weeks.

In the new Itembase.dev article, I go deeper into:

why rarity alone does not create excitement
how probability becomes emotional pacing
why most “rare” items stop feeling rare
how to simulate reward cadence before launch
and why many loot systems fail socially, not mathematically

If you work on progression, economies, rewards, or live-service design, this article goes much deeper than standard drop-rate discussions.

Read the full article:

itembase.dev

The piece also includes a full loot-system audit framework for designing rewards that create stories — not just retention metrics.

The Most Powerful Item Wasn't a Weapon. It Was a Key.

Sam Novak — Fri, 15 May 2026 12:53:59 +0000

This is a crosspost. The full article is on Itembase.dev.

It opened one door. No stats. No rarity color. No tooltip.
Players kept it for the entire playthrough — because they didn't know which door it opened.
That key taught me more about item design than anything I'd read in a GDD.

The principle: deferred meaning
An item doesn't need to be useful right now to feel valuable. It just needs to feel like it will be.
The key created a question the moment players picked it up: what does this open? That question - unrealized, unknown - made it more valuable than any weapon in the game.
Once you see this mechanism, you see it everywhere:

The strange coin an NPC gives you in act one
The locked chest you find before the lockpick
The empty crafting slot with a silhouette you can't fill yet

None of these have immediate utility. All of them have weight.

Two layers every item has — and one that gets ignored
Every item has a functional layer (stats, effects, use cases) and a meaning layer (name, description, context, how it feels to hold).
Most item design focuses entirely on the functional layer. The meaning layer gets filled in at the end, if at all.
That order is backwards.
A sword called "Iron Sword" with 50 attack is a tool. A sword called "The Last Argument" with the same stats and a description reading "Forged the night before a battle no one came back from" is a story.
Same function. Completely different emotional relationship.

The full piece
The full article on Itembase.dev covers:

Why the meaning layer shapes how players relate to the functional layer
How I kept running into this problem in my own design work
How Itembase puts the meaning and functional layers side by side
A practical checklist for designing deferred meaning intentionally

Read it on Itembase.dev

Itembase is a game design tool for building, balancing, and simulating item systems — with the meaning layer built in from the start. Try it free.

The Invisible Systems That Run Every Game (and Why They Break)

Sam Novak — Thu, 14 May 2026 08:40:28 +0000

This is a crosspost. The full article — including how to design, simulate, and debug invisible systems — is on Itembase.dev.

A player puts down your game after three weeks.
Nothing crashed. The story wasn't over. They just… stopped.
Ask them why and they'll say something vague. "It got boring." "It stopped feeling rewarding." "I don't know, I just lost interest."
What they experienced was the failure of a system they never knew existed.

Every game has two layers
The visible layer is what players interact with: the art, the controls, the story, the levels, the UI.
The invisible layer is what runs underneath all of that — the systems governing how resources flow, how difficulty scales, how rewards land, how progression accelerates or decelerates, how the economy breathes.
The visible layer gets most of the attention in game design discourse. The invisible layer gets mentioned but rarely examined in depth, because it's genuinely hard to see. You can't look at a game and see its economy. You can only feel what happens when the economy does or doesn't work.

The six invisible systems running almost every game
SystemWhat players seeWhat's actually runningEconomyGold, items, pricesEarn rates, sink depth, inflation rateProgressionXP bars, level upsCurve shape, power delta per level, catch-up mechanicsRandomnessLoot drops, critsPity timers, pseudo-random distribution, streak preventionDifficultyEnemy health, damageDynamic adjustment, rubber-banding, fail-state softeningRetentionDaily rewards, streaksVariable ratio reinforcement, re-engagement hooksAI behaviorEnemy decisionsGoal weighting, threat radius, illusion of intelligence
None of these are experienced directly. All of them are felt constantly.

The core asymmetry
Here's the gap that causes most invisible system failures:

Players experience games emotionally. Invisible systems operate mathematically.

A player doesn't experience "the earn rate on this source node is 40% higher than intended." They experience "I feel rich, so spending doesn't feel like a decision."
The feeling is real. The cause is invisible.
Players can always describe the feeling. They can almost never describe the cause.
That asymmetry is the invisible system designer's entire problem.

How broken invisible systems announce themselves
They don't break with error messages. They break with feelings:

"This game is too grindy" - earn rates don't match sink costs
"I hit a wall" → XP curve has a spike that breaks expected pace
"The loot feels rigged" - pity timers too long for average session length
"It doesn't feel rewarding anymore" - reward scheduling became predictable
"The AI is cheating" - dynamic difficulty adjustment became visible
"I don't know why I stopped" - multiple systems degraded simultaneously

Why the economy is the most invisible system of all
The game economy isn't just complex — it's the connective tissue between every other invisible system.
XP curves determine progression speed - which gates what players can buy → which determines how currency flows - which feeds back into whether grinding feels worth it - which affects retention - which changes how often players trigger the reward schedule.
When the economy is wrong, it doesn't just break the economy. It breaks everything downstream, silently.

The full article
The complete piece covers:

Why invisible systems break in five predictable ways
How to make them visible to you (without making them visible to players)
How to simulate multiple player archetypes over 30, 60, 90 days before launch
How to design emergency valves before you need them
Why the most dangerous invisible system is the one you're confident about

Read the full article on Itembase.dev

The Thin Line Between a Reward Loop and a Trap

Sam Novak — Wed, 13 May 2026 14:13:21 +0000

Here's a question I keep coming back to every time I tune an economy or launch a live event:

When does game design stop being craft and start being coercion?

Reward loops are the backbone of almost every game ever made. Action -reward - anticipation - action. That pattern isn't evil — people love progress, love feedback, love feeling competent. Good design aligns those instincts with meaningful play.

But somewhere between "this game is addictive in the best way" and "I can't stop but I'm not having fun" — there's a line. And a lot of live service design is sitting right on top of it.

The hollow loop is easy to spot in retrospect. You've "progressed" — bars filled, numbers climbed — but you weren't actually playing. You were clearing checklists. Grinding for the fifth identical XP bump. Repeating tasks that teach nothing and go nowhere.

Repetition isn't inherently bad. Dark Souls is brutally repetitive. But dying in Dark Souls feeds learning. Learning feeds adaptation. Victory feels earned because the loop scales with you. Challenge and reward stay proportional.

That's the version of addictive that designers should be chasing.

The version to avoid looks like this:

A timer was tuned not for pacing but for friction, and the shortcut costs $2.99
A login streak punishes absence instead of rewarding presence
Progress gates behind spend rather than play
Players keep clicking but can't explain why

The "it's just engagement" framing is where I get uncomfortable. Optimizing for engagement often means stretching sessions past the exact moment fun stops. It's exploiting the gap between "I'm enjoying this" and "I can't stop." Once you've seen the retention graphs, it's hard to unsee the temptation to chase them.

I wrote about where I think the actual line lives — and a practical framework I use to check which side a design is on. Not a universal test, because design is messy. But honest enough to be useful.

If you build live games, economies, or anything with a reward structure, this one's worth a read.

Full post → [Read More]

Modeling item sinks and sources in a node graph

Sam Novak — Tue, 12 May 2026 10:02:55 +0000

A practical breakdown of how to map game economy flows visually — and why node graphs make sink/source balance easier to reason about than spreadsheets.

Every game economy has the same underlying problem: stuff comes in, stuff goes out, and the ratio between the two determines whether your game feels good or broken. The concepts are simple. The hard part is seeing them clearly enough to make good decisions.
Spreadsheets are the default tool for this — and they're fine for calculating. But they're bad at showing you flow. You can't look at a spreadsheet and immediately understand whether gold is accumulating in one corner of your economy, or which mechanic is the biggest drain, or how a new item type will ripple through everything downstream.
Node graphs fix that. This post is about how to model sinks and sources as a graph — and what patterns to look for once you can see the whole picture at once.

The core model: nodes and edges
In a node-based economy model, each node represents either:

A resource — gold, wood, gems, energy, reputation, whatever your game uses
A mechanic — a process that transforms or moves resources between nodes

Edges represent flow: currency moving from one node to another, with a rate or quantity attached.
A minimal economy looks like this:
[Quest Reward] ──── gold ──→ [Player Wallet] ──── gold ──→ [Upgrade Shop]
That's a complete economy. One source, one pool, one sink. Everything else is elaboration on this pattern.

Sources: where resources enter the system
A source node is any mechanic that creates new currency or items — effectively pulling them from outside the economy into the player's hands.
Common sources:
SourceNotesDaily login rewardFixed rate, predictable. Easy to model.Quest completionVariable by quest. Use average expected earnings.Enemy dropsProbabilistic. Model as expected value per hour.Selling itemsConverts one resource type to another — technically a source and a sink depending on your frame.Battle pass rewardsTime-gated source. Important for controlling supply curves.
When modeling sources in a graph, each one gets its own node with an output rate — how much currency it pushes into the system per unit of time (usually per session or per hour of play).
[Daily Login] ──→ 50 gold/day ──→ ┐
[Quest Clear] ──→ 80 gold/hr ──→ ├──→ [Player Wallet]
[Enemy Drop] ──→ 30 gold/hr ──→ ┘
The total input rate here is ~160 gold/hour of play + 50/day. That's your baseline supply number.

Sinks: where resources leave the system
A sink node is any mechanic where currency or items are consumed and effectively removed from the economy. The player spends — the resource is gone.
Common sinks:
SinkNotesUpgrade costsScales with progression. Should grow faster than earn rate.Crafting recipesMulti-resource sinks are powerful — they drain multiple currencies at once.Cosmetic purchasesPure sink with no gameplay return. Healthy for live economies.Gacha/loot boxesProbabilistic sink. Risk of over-draining players at bad luck.Trading feesTiny but constant sink. Useful for controlling player-to-player economies.
In a node graph, sinks are terminal nodes — resources flow in, and nothing flows out. They're where your graph ends.
[Player Wallet] ──→ 200 gold ──→ Upgrade: Level 3
[Player Wallet] ──→ 500 gold ──→ Cosmetic Shop
[Player Wallet] ──→ 150 gold ──→ Crafting: Iron Axe

The balance check: input vs. output
Once you have sources and sinks mapped, the key question is: does the total output rate exceed the total input rate?
Total sources: 160 gold/hr + 50/day
Total sinks: ~350 gold/hr (if player is actively spending)
In this example, a player who plays actively can spend faster than they earn. That's fine — it creates demand for the harder-to-reach sources (battle pass, seasonal events). But if a casual player earns 50 gold/day and the cheapest sink costs 500, you have a problem.
This is where the graph earns its value: you can see at a glance whether any player archetype — casual, mid-core, hardcore — has a path through the economy that feels good. Spreadsheets show you totals. Graphs show you paths.

Intermediate nodes: the economy gets interesting
Real economies don't just go source → wallet → sink. They have intermediate nodes — resources that are themselves the output of one process and the input of another.
Example:
[Enemy Drop] ──→ Iron Ore ──→ [Forge] ──→ Iron Bar ──→ [Crafting: Sword] ──→ (terminal)
Here, Iron Ore is neither a pure source nor a pure sink. It's an intermediate resource — a conversion node. The Forge transforms it into something more valuable at the cost of player time and possibly other resources (fuel, gold for the forge fee).
Intermediate nodes are where economy design gets nuanced:

They create meaningful choices. Should I sell the Iron Ore or forge it? That's an interesting question.
They create bottlenecks. If the Forge is slow, Iron Bars become scarce even if Iron Ore is plentiful. Intentional scarcity is a design tool — unintentional scarcity is a frustration.
They hide inflation. If Iron Ore accumulates because no one forges, your economy looks balanced in the raw numbers but players feel rich in one resource and poor in another.

What to look for in a node graph
Once you have the full graph drawn, scan for these patterns:
Isolated nodes
A node with no outgoing edges (other than the expected terminal sinks) means a resource is accumulating with nowhere to go. Classic inflation indicator. Ask: is there a sink I'm missing, or is this resource actually useless?
Bottleneck nodes
A node that all other paths run through. If that node gets disrupted (rate change, bug, event), it affects everything downstream. These are high-risk, high-leverage points to watch.
Parallel paths to the same sink
Two different sources both feeding the same sink means that sink's drain rate needs to account for both simultaneously. Easy to miss in a spreadsheet; obvious in a graph.
Dead-end sources
A source node whose output has no path to any meaningful sink. Players earn the resource but can't spend it on anything they care about. A motivation killer.

Modeling this in Itembase
This is the exact problem Itembase was built to solve. You model each resource and mechanic as a node, connect them with edges, assign rates, and the tool simulates how currency accumulates or depletes over time across different player archetypes.
The visual representation forces a discipline that spreadsheets don't: you have to explicitly account for every connection. There's no way to miss a flow when you're drawing it.
If you're building an economy right now — even a simple one — mapping it as a graph before you start assigning numbers will save you a lot of painful rebalancing later.
Try it at itembase.dev

Designing Better Games with Curves, Data, and a Strong Community Mindset

Sam Novak — Mon, 27 Apr 2026 07:51:39 +0000

Game design is often described as an art, but the games that truly feel right are usually built on top of well-shaped systems. Behind progression, difficulty, rewards, and balance, there is a quiet layer of math and statistics guiding the experience.

You do not need formulas to use these ideas. What matters is understanding how systems behave and how players react to them.

Curves shape the player experience over time. When progression feels steady and predictable, the game becomes easy to understand but may risk feeling repetitive. When difficulty increases quickly, the experience becomes more intense but can also become frustrating if not handled carefully. A well-designed game usually starts gently, builds challenge over time, and then stabilizes so players can enjoy mastery instead of hitting a wall.
This balance is not accidental. It comes from adjusting how numbers grow and how systems respond as players move forward. Good designers think about pacing constantly, even if they are not thinking in mathematical terms.

Statistics play a different role. They shape randomness and uncertainty. Random systems appear in loot, combat outcomes, matchmaking, and many other areas. The challenge is that true randomness often does not feel fair to players. Long streaks of bad outcomes can feel broken, even when they are technically correct.
Because of this, many games guide randomness quietly. They reduce extreme streaks, slightly increase chances after repeated failures, or keep results within a reasonable range. The goal is not perfect randomness but a sense of fairness that players can trust.

Balancing systems is ultimately about feeling. A system can be logically correct and still feel frustrating. What matters is whether players feel rewarded, challenged in a fair way, and in control of their progress.
Sharing your work with others is one of the fastest ways to improve as a designer. A healthy community makes a huge difference in how ideas evolve. When people communicate respectfully, discussions become more useful and more honest. When creators share their work thoughtfully instead of flooding the space, others are more willing to engage and give feedback. It also helps to take part in the community before promoting your own work. Joining conversations, asking questions, and helping others creates trust and makes people more interested in what you are building.
Being honest about your work is just as important. If something is unfinished or experimental, saying so builds credibility. People respond better to transparency than to exaggeration.
Using tools, including AI, can be helpful during the design process, but the final result should always feel intentional and refined. Low-effort output stands out quickly, while thoughtful work earns attention.
Keeping communication clear and accessible allows more people to take part in discussions. When everyone can understand and contribute, the quality of feedback improves.
Promotion works best in the open. Sharing ideas publicly invites discussion and creates opportunities for improvement, while unsolicited messages often push people away.

In the end, strong game design comes from combining structured systems with human insight. Curves and statistics help shape the experience, but player perception defines whether it succeeds.
When designers build carefully, share honestly, and support each other, they create not only better games but also better spaces to grow.

itembase.dev

The Scoring Gap: What a Carnival Shooter Teaches Us About Real Design

Sam Novak — Mon, 20 Apr 2026 14:41:07 +0000

There’s a story Jesse Schell tells in The Art of Game Design that every developer and designer should have pinned to their desk.

It starts with a carnival shooter game built for families. During playtests, everyone was having a blast—moms, dads, kids. The smiles were there, the engagement was high. But the data showed something odd: Men were consistently outscoring women.

The team dug in, expecting a skill gap. What they found was a behavioral gap.

The Men: Tended to "spray and pray," firing as fast as possible to hit as many targets as possible.

The Women: Tended to slow down, line up their shots, and play for precision.

The game only tracked raw points. Because "spray and pray" generated more hits per minute, the system quietly rewarded one strategy and punished the other. The fix? They added a second score column for accuracy.

The mechanics stayed the same, but the experience changed for half the audience. Suddenly, both styles had a way to "win."

The Demographics Trap
It’s easy to look at that story and see a "gender" lesson. It’s not. It’s a behavioral lesson.

As devs, we often build "loops" that accidentally favor a specific type of user:

Tutorials that assume you already know the genre's "unspoken" rules.

Scoring models that only value speed over quality.

Onboarding flows that ramp up in difficulty only if you’ve used similar SaaS tools before.

These aren't demographic failures; they are observation failures. When we only reward one interpretation of our system, we leave users behind without even noticing they were there.

"A Game for Everyone is a Game for No One"
We hear this mantra all the time. It’s about 60% right. If you sand off every edge to please everyone, you end up with "design oatmeal"—bland and unmemorable.

But there’s a better way to read it: Make your system readable from multiple angles.

Think about RPGs. They’ve mastered this for decades. A world contains tanks, healers, glass cannons, and stealth players. They all exist in the same ecosystem, but the system supports their distinct behaviors. That’s not a compromise; that’s depth.

Playtesting > Personas
The reason Schell’s team caught the issue wasn’t because they had a "Female Persona" slide in a deck. It’s because they watched real humans play.

The most important skill for a designer isn't creativity—it's listening.

Creativity gets the prototype built.

Listening tells you if the prototype actually works.

Designing Beyond Yourself
The old advice "Design the product you want to use" is a great starting point, but it's a terrible finish line. You are one person with one set of habits. A pacing choice that feels "snappy" to you might feel "stressful" to someone else.

The goal isn't to please the entire planet. The goal is to ensure that if your audience is narrow, it’s because you intended it to be—not because you accidentally locked the door on everyone else.

The Takeaway
Don’t design for demographics. Design for behaviors. Watch how people actually use your software. Notice when two groups approach the same system differently. Then, ask yourself: Does my design reward those differences, or does it punish them?

The gap between a product that accidentally excludes people and one that purposefully serves a focused audience is the gap between carelessness and craft.

Want to dive deeper into how we apply these design principles?
You can see more about this and other deep dives over at our blog:
👉 https://itembase.dev/blogs/design-for-behaviors-not-demographics

The Part of Your Game That Breaks First

Sam Novak — Wed, 15 Apr 2026 10:49:42 +0000

At first, building my game felt almost too easy.
I had a pretty modern setup - Claude for planning and design, Claude Code for implementation, GitHub Desktop for version control. Features that used to take days suddenly took hours.
But once the project grew, things started to feel… heavier.
Not in an obvious "this is broken" way. More like small friction everywhere.
What Actually Helped Early On
The first real improvement I made was separating planning from implementation.
Instead of mixing everything together, I created two clear spaces: one for decisions, systems, and structure - another for actually building and updating code.
That alone fixed a lot of weird issues. Before that, it felt like too many things were happening at once. Once they were split, things became more predictable.
Then the Subtle Problems Started Showing Up
After some time, a different kind of problem appeared.
Nothing crashed. Nothing failed completely. But things stopped feeling clean.
Repeating the same context, every time.
Every new session meant bringing everything back up again — how systems work, how things are named, what decisions were made earlier. Even with notes, it never felt fully "remembered."
Small inconsistencies creeping in.
A weapon called "Iron Blade" in one place becomes "iron_blade" in another. A reward chest gives 50 gold in one system and 75 in another. An edge case that was solved last week gets reintroduced because the fix only lived in a conversation.
None of these are big enough to notice immediately. But over time, they create a kind of invisible mess that slows everything down.
The Real Issue
At some point it became clear — the problem wasn't the tools.
It was structure.
The actual "source of truth" was scattered. Some things lived in code. Some in notes. Some only existed during a session and then disappeared.
That works early on. But once things grow, it starts to fall apart quietly.
The Missing Piece
The biggest shift for me was treating game data as its own layer.
Not just code. Not just planning. A separate, dedicated place for things like items, rewards, progression values, configs, and balancing — all the parts of a game that change constantly and touch everything else.
Because games aren't just logic. They're a massive web of structured data that evolves over time. And if that data isn't clearly defined and consistent, everything depends on memory. Changes become harder to track. Small mistakes spread fast.
Most of the friction I was feeling came from this — not from writing code.
What Changed After That
Instead of thinking:
planning - implementation
I started thinking:
planning - implementation - data
Where planning defines what should exist, implementation builds it, and data holds everything that changes.
That made things feel noticeably more stable. Less repetition. Less confusion. Fewer surprises.
Where Itembase Comes In
This is the space I've been working on with Itembase.dev.
Not as another tool for building code — but as a structured home for game data to live and evolve.
Because right now, most people are managing this manually, dumping everything into JSON files, or just dealing with the mess until it becomes unmanageable.
And when your game data finally has a real home, something shifts. You stop second-guessing values. You stop re-explaining systems. You start building on top of what's already solid instead of constantly patching what drifted.
Final Thought
At a small scale, almost any setup works.
But as things grow, the problems shift. It's not about speed anymore. It's about keeping everything consistent.
And from what I've seen, that's the part that breaks first.

What Game Designers Actually Use: A Honest Look at Level Design and Economy Tools in 2026

Sam Novak — Fri, 10 Apr 2026 07:35:32 +0000

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.