DEV Community: Sam Novak

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.

Game Design in 2026: Your Players Think Your Math Is Wrong

Sam Novak — Thu, 09 Apr 2026 07:10:43 +0000

For years, we’ve been taught to balance systems using math.

Expected value.
Drop rates.
Probabilities.
Simulations.

We run the numbers.
We validate the curves.
We make sure everything is “fair.”

And still…

Players log in, lose a few times, and say:

“This game is rigged.”

Here’s the uncomfortable truth:

You can build a system that is perfectly fair…
and players will still experience it as broken.

Because players don’t experience math.

They experience outcomes.

The moment everything breaks

A player misses three 80% chances in a row.

On paper? Completely fine.
In reality? That player is already frustrated.
In their mind? The system is lying.

They don’t think:

“Ah, yes, variance.”

They think:

“This game is cheating me.”

And once that thought appears, you’ve already lost them.

The real problem isn’t RNG

It’s perception.

The gap between:

what is mathematically true
and what feels true

That gap is where most design problems live.

And in 2026, that gap is only getting bigger.

Games are more complex.
Systems are deeper.
Players are louder, faster, and more opinionated.

“The math checks out” is no longer a defense.

You’re not designing systems. You’re designing reactions.

Modern game design is quietly shifting from:

→ “Is this system fair?”
to
→ “Does this system feel fair?”

That’s not a small change.
That’s a completely different mindset.

Because players don’t walk into your game as rational evaluators.

They bring baggage:

They remember losses way more than wins
They expect 80% to behave like 95%
They hate streaks (even when streaks are normal)
They think they’re better than they actually are

So when things go wrong, they don’t question themselves.

They question your game.

What actually changes in 2026

This is where things get interesting.

We’re already seeing a shift — not in theory, but in how real systems are built.

RNG is no longer “pure”

Pure randomness sounds fair.

But pure randomness creates streaks.
And streaks feel terrible.

So designers intervene.

They add:

streak protection
pity systems
dynamic probabilities

Not to “cheat” —
but to make randomness behave the way players expect it to behave.

Trust becomes a feature

Players don’t trust what they can’t see.

So games are starting to show more:

drop rates
history logs
distribution stats

Not because players asked for math…

But because visibility reduces frustration.

If players can see the system, they’re more likely to accept it.

Balance shifts from math → experience

Before:

“Is this distribution correct?”

Now:

“How does this feel after 10 minutes?”

Teams are starting to measure things like:

How often does a player feel unlucky?
How long do negative streaks last?
When does a win actually feel meaningful?

Because a system can be statistically perfect…
and still feel awful to play.

Emotion becomes the core system

Here’s the reality most teams already know (but rarely say out loud):

Small losses are acceptable
Big losses feel unfair
Rare big wins feel amazing
Frequent small wins feel empty

This isn’t new.

But in 2026, it’s no longer “juice” or “polish.”

It’s the system.

The tradeoff nobody likes to talk about

There’s a tension at the center of all this.

If you adjust randomness to match player expectations…
you’re no longer truly fair.

If you don’t adjust it…
players will believe your game is broken.

So what do you do?

The answer: live in the middle

Most games in 2026 won’t choose one side.

They’ll combine both approaches:

Bend the system where frustration is highest
Keep it honest where trust matters most

Because fairness isn’t just math.

It’s perception.

And perception is what players remember.

What we’re thinking about

As we build toward our next game in 2026, this is a core question for us.

Not:

“Is this system balanced?”

But:

“What does this feel like after 3 losses in a row?”
“What does a win feel like after frustration?”
“Where does the player start blaming the system?”

Because design doesn’t end when the numbers look right.

It ends when the experience matches what players believe should happen.

One question worth asking

If you’re building games today, ask yourself:

Are you designing for probability…

or for perception?

Full breakdown of player bias & randomness:

itembase.dev

Game Balance

Sam Novak — Tue, 07 Apr 2026 12:57:01 +0000

Game Balance Explained: How to Know if a Game Is Balanced

What does game balance actually mean? How do you measure it? And why does it feel so hard to define?

Game balance is one of the most discussed — and most misunderstood — topics in game design.

After analyzing dozens of perspectives from developers and players, one thing becomes clear:

Game balance is not a fixed number. It’s a dynamic relationship between systems, player perception, and experience.

What Is Game Balance?

Game balance refers to how well a game’s systems create a fair, engaging, and meaningful experience for players.

But balance does not mean:

equal stats
identical options
perfectly even outcomes

Instead, balance means:

players feel their choices matter
multiple strategies are viable
the game feels fair for its intended audience
the experience remains engaging over time

Why Game Balance Is Not Just Numbers

Many developers try to balance games using spreadsheets and metrics:

win rates
damage values
cooldowns
time-to-kill
resource accumulation

These are important — but they are not enough.

A game can be mathematically balanced and still feel:

frustrating
boring
unfair

This is because players experience games emotionally, not mathematically.

Perceived Fairness: The Core of Balance

Players don’t calculate balance — they feel it.

They ask:

Did I understand what happened?
Did I have a fair chance?
Did my decisions matter?

If yes → the game feels balanced.
If no → the game feels broken.

This concept is known as perceived fairness, and it is central to game balance.

PvP vs PvE Balance (Key Difference)

PvP (Multiplayer Games)

Balance is critical because:

dominant strategies break competition
players optimize quickly
meta forms rapidly

Key metrics:

win rates
pick rates
strategy diversity

Goal:
prevent a single dominant strategy

PvE (Single Player Games)

Balance is more flexible.

Here, balance = player experience.

Examples:

Overpowered items can increase excitement
Easy sections can create relief
Difficulty spikes can be satisfying if fair

Goal:
create engaging pacing (tension + release)

The Meta: Why It Always Exists

A common myth:
“A balanced game has no meta”

Reality:
A meta always exists

Players naturally optimize strategies.

The real problem is when:

one strategy dominates everything
all players converge to the same solution

A healthy game has:
multiple viable strategies
evolving meta
room for adaptation

Meaningful Choices vs Equal Choices

Good balance is not about equality.

It’s about meaningful decision-making.

Rules of thumb:

No option should be so strong everyone picks it
No option should be so weak nobody picks it

When choices become obvious, the game becomes boring.

Asymmetrical Balance (Why It Matters)

Two types of balance:

Symmetrical balance

similar power levels
easier to understand

Asymmetrical balance

different roles and strengths
deeper gameplay

Most great games use asymmetry.

The goal:
different roles still feel valuable

Difficulty vs Clarity (Critical Insight)

One of the most important distinctions in game design:

If players understand and fail → difficulty
If players don’t understand → design problem

Many “balance issues” are actually clarity issues.

How to Actually Test Game Balance

1. Watch Players

Observe:

where they struggle
where they quit
where they get confused

This reveals more than data alone

2. Use Metrics (Telemetry)

Track:

win rates
failure points
time-to-kill
usage rates

Metrics help find outliers

3. Combine Both

Best approach:

Data finds problems
Players explain them

Why You Can’t Fully Balance a Game Before Launch

Players will always:

find exploits
discover new strategies
break systems

Balance is ongoing, not final.

Balance Is About Curves and Timing

Balance is not static — it happens over time.

Important curves:

difficulty curve
reward curve
progression curve

Problems happen when:

rewards come too late
difficulty spikes too early
progression feels flat

The Truth: You Never Fully Know

You don’t know a game is balanced.

You:

gather data
observe players
iterate
adjust

And then you ship.

Final Definition of Game Balance

A game is balanced when:

It consistently creates fair, meaningful, and engaging decisions for its intended players — across time, skill levels, and playstyles.

Final Thought

Perfect balance doesn’t exist.

But great games don’t need perfect balance.

They need:
clarity
variety
fairness
and most importantly — fun

And if players stop questioning the system and just keep playing…

That’s probably the closest thing to balance you’ll ever

After posting a simple question — how do you actually know a game is balanced? — I got back a much better answer than I expected:

You usually don’t know.

Or at least, not in the clean, final, spreadsheet-friendly way people sometimes talk about balance.

The responses pushed me toward a view of balance that feels much more honest: balance is not a fixed state. It is a moving relationship between systems, player expectations, skill levels, dominant strategies, pacing, clarity, and fun.

That sounds broad because it is. And maybe that’s the point.

The First Mistake: Treating Balance Like Pure Math

When people talk about balance, they often default to numbers:

win rates
damage values
cooldowns
time-to-kill
resource accumulation
progression curves

Those things matter. Of course they matter.

But one of the clearest themes that came up in discussion was that numbers alone never tell the full story.

A game can be hard and still feel fair.
A game can be easy and still feel dull.
A reward can be correct on paper and still feel wrong if it arrives too late.
A weapon can have a perfectly reasonable win rate and still be miserable to play against.

That gap between mathematical correctness and player experience is where a lot of real balance work happens.

Balance Is Often Just Another Word for Fairness

One of the most useful ways to think about balance is as perceived fairness.

Players are not running calculations in their heads while they play. They’re asking simpler questions:

Did I understand what happened?
Did I have a fair chance?
Did my decisions matter?
Was the payoff worth the effort?

If the answer is yes, the system often feels balanced.
If the answer is no, it often feels broken — even if the math says otherwise.

That’s why the same system can feel balanced to one audience and terrible to another. A punishing roguelike and a cozy farming sim can both be “balanced,” but they are balanced toward completely different player expectations.

In PvP, Balance Usually Becomes Concrete Fast

In competitive games, balance becomes harder to dodge as a concept.

If one strategy is clearly dominant, players converge toward it. If one character, weapon, race, or build is significantly stronger, the competitive layer starts to collapse around it. Suddenly the game is less about expression and adaptation and more about whether you picked the right thing early enough.

That doesn’t mean PvP balance is simple. In fact, it may be where balance is most demanding.

Because in PvP, balance changes based on:

skill level
matchup knowledge
current meta
community discovery
psychological play
long-term optimization

One of the strongest observations people made was that skilled players often reveal imbalance rather than smoothing it out. Something that feels fine in casual play can break apart under expert play because better players are much better at pushing systems to their limits.

Chess is the classic example people brought up. At casual levels, it feels fair. At the highest level, first-move advantage starts to matter more. The game didn’t suddenly change. What changed was the players’ ability to expose what was always there.

A Meta Always Exists — the Question Is Whether It Collapses

A lot of discussion circled around “meta.”

Some people argued that a game is balanced when no meta exists. I think the more accurate view is this:

A meta always exists.

Players naturally search for optimal play. They copy what works, refine what works, and develop shared assumptions about what is strongest.

The actual problem is not the existence of a meta. The problem is when the meta collapses into one dominant strategy and crowds out everything else.

That’s when:

experimentation shrinks
variety disappears
the game starts to feel solved
viable choices stop feeling viable

A healthy game usually doesn’t eliminate the meta. It keeps the meta diverse, dynamic, and contestable.

Rock Paper Scissors is a neat example here. On paper, there is no dominant option. But there is still a psychological strategy layer: prediction, conditioning, bluffing, opponent reads. That is still a meta. It just isn’t a collapsed one.

Multiple Viable Choices Matter More Than Equal Choices

A lot of the best comments came down to one practical test:

No option should be so good that everyone takes it.
No option should be so bad that nobody takes it.

That’s simple, but it gets at something deep.

Balanced games do not require every option to be equal in all situations. They require options to have meaningful value inside the system.

That means:

a card should have a reason to be picked
a class should have a role
a build should have a context where it shines
a weapon should create a tradeoff, not just a hierarchy

When choices stop being situational and start becoming obvious, the decision space shrinks. The game may still function, but it starts losing texture.

This is especially noticeable in strategy games, deckbuilders, RPGs, and competitive systems where the fun comes from navigating a space of tradeoffs rather than executing the same answer every time.

Asymmetry Is Not the Opposite of Balance

Another strong theme was the confusion between balance and sameness.

Some people react against the word “balance” because they think it means flattening all differences. But that is not what good balance has to mean.

In fact, some of the best balanced systems are highly asymmetric.

Symmetrical design tends to be easier to compare and easier to perceive as fair. But asymmetrical design often creates more depth because different roles, powers, and tools matter in different situations.

The key is not that everything does the same thing equally well.
The key is that different parts of the system remain meaningfully valuable.

That’s why team-based or class-based games can feel balanced even when roles are wildly different. A class does not need to be equally strong in every context. It needs to contribute something real to the overall structure.

PvE Balance Is a Different Problem Entirely

Single-player and cooperative games make the topic even messier.

A lot of people made the point that in PvE, “balance” is often less useful as a strict goal than player experience.

That feels right.

In PvE, some imbalance can actually improve the game:

a rare overpowered item can create excitement
a huge spike in player power can create a satisfying rush
an easy section can give relief after intense play
a hard boss can feel great if the challenge is clear and earned

What matters is not equality. What matters is whether the growth in player power, difficulty, rewards, and novelty creates a compelling rhythm.

A great comment framed this as a cycle of tension and release. That feels more useful than asking whether every encounter or item is perfectly calibrated.

A game like The Binding of Isaac uses disparity as part of the excitement. A game like Final Fantasy VII uses stronger gear and better stats as a more reliable form of progression. Both can work. Both can feel balanced. But they are producing different emotional outcomes.

Difficulty Is Not the Same Thing as Clarity

One of the smartest distinctions anyone made was this:

If the player knew what to do and still failed, that’s difficulty.
If the player didn’t know what to do, that’s a design problem.

That’s such a useful way to think about so-called “balance” problems.

A lot of what gets labeled as imbalance is actually:

poor communication
unclear feedback
bad signposting
hidden information the player couldn’t reasonably read
systems that violate the expectations the game taught earlier

When players lose because they misunderstood the game rather than because the challenge exceeded them, the experience feels unfair fast.

That’s why observing real players matters so much.

Watching Players Often Teaches More Than Tweaking Numbers

Several developers said some version of the same thing: just watch people play.

Not dashboards. Not theory. Not your own expert brain. Just real players.

Watch where they:

stop
hesitate
die
disengage
misunderstand
stop experimenting
put the controller down

That kind of observation reveals things telemetry often misses. It catches the difference between a system that is technically functioning and one that is actually producing the intended experience.

If balance is partly a feeling, then direct observation becomes one of the best ways to study it.

Telemetry Still Matters — Especially at Scale

At the same time, metrics are not optional, especially in larger or competitive games.

If you are balancing a live game or any system with enough complexity, you need ways to catch the worst outliers.

Useful signals include:

win rates
pick rates
ban rates
time-to-kill
clear rates
failure points
resource accumulation
usage frequency
completion timing

Those metrics do not answer the whole balance question, but they help identify what deserves scrutiny.

A good way to put it is:

Telemetry catches outliers. Playtesting catches feel.

That combination came up repeatedly and feels about right.

You Rarely Finish Balancing Before Launch

Another consistent point: players will find exploits faster than internal QA.

That’s not pessimism. That’s just what happens when thousands or millions of people start pushing a system from angles you didn’t anticipate.

So balance is rarely something you “solve” before shipping. It’s more like you:

establish strong baselines
remove obvious outliers
validate feel with real people
ship with reasonable confidence
learn what the larger player base discovers
iterate carefully

In complex games, post-launch balance is often where the real work begins.

Even Perfect Fairness Can Be Uninteresting

One of the most interesting examples people raised was mirror matchups in competitive games.

On paper, a mirror matchup is perfectly fair. Both players have the same tools. But sometimes those matchups become stale, overly long, or strategically boring.

That matters.

Because it shows that balance is not just about fairness in the narrow sense. It is also about whether the system produces interesting, satisfying, and expressive play.

A system can be fair and still need change.

The Audience Changes the Meaning of Balance

This came up again and again.

Who is the game for?

That question changes almost everything.

A game for young children may be balanced precisely because it is nearly impossible to lose.
A masocore game may be balanced because it destroys the player repeatedly before mastery emerges.
A cozy game may intentionally keep friction low.
A gacha may tie rewards more to engagement than effort.
A competitive PvP title may prioritize high effort, high reward expression.

These are different balance targets because they are different experiences for different audiences.

So whenever someone says a mechanic is “unbalanced,” the next question should probably be:

For whom?

Balance Is Also About Pacing and Curves

A lot of the thread indirectly circled back to curves:

difficulty curves
reward curves
progression curves
power curves
tension curves

This matters because balance is often not about isolated numbers at all. It is about how things change over time.

Something can be balanced at a single moment and still fail across the larger experience if it:

ramps too quickly
ramps too slowly
gives rewards too early
delays rewards too long
frontloads complexity
creates flat stretches with no meaningful change

Players don’t just experience systems statically. They experience them as sequences.

So a lot of balance becomes visible through pacing.

Sometimes “Balanced Enough” Is the Right Answer

One of the more practical responses was basically: if the game is consistently fun, maybe it is balanced enough.

I think that’s worth taking seriously.

Not because standards should be low, but because “perfect balance” is often a false destination. In many cases, chasing mathematical purity can flatten the game, remove surprise, reduce contrast, or accidentally sand off the moments that make the system memorable.

Sometimes the better question is not “is this perfectly balanced?”

It’s:

is this compelling?
is it fair enough for the intended audience?
are the choices still interesting?
does the system support the experience we want?

So How Do You Actually Know a Game Is Balanced?

You don’t know in any final sense.

You gather signals.
You watch people play.
You study the outliers.
You look for dominant strategies.
You test whether choices remain meaningful.
You ask whether the experience feels fair for the target audience.
You pay attention to pacing, clarity, progression, and payoff.
You ship when you are confident enough.
Then you keep listening.

If I had to reduce everything from the discussion to one answer, it would be this:

A game is balanced when its systems consistently create meaningful, fair, and engaging decisions for the people it was designed for — and keep doing so even as players get better at understanding the game.

That still isn’t a fixed definition.

But maybe balance was never supposed to be fixed in the first place.
If you want to go deeper into how balance actually works in practice - from systems, curves, and player behavior - you can read more about game balance here too:

How Do We Know If a Game Is Balanced?

Sam Novak — Mon, 06 Apr 2026 11:12:40 +0000

his post is inspired by a piece on the Itembase Dev's blog. I wanted to expand on the ideas there because they nail something designers wrestle with constantly.

itembase.dev

Saying a game is "balanced" is about as precise as saying it's "fun." Everyone nods, nobody agrees on what it actually means. But there is a practical framework hiding behind the vagueness, and it starts with three dials.
The Three Dials
Every balance conversation, whether you're tuning a single boss fight or a full free-to-play economy, comes down to three variables:
Difficulty — Is it too easy, too hard, or just right? This isn't only about combat. It's the cognitive load of a puzzle, the pressure of a timer, the friction of a crafting loop. A game can be mechanically simple and still feel brutally difficult if the decision space is overwhelming.
Quantity - Are there too many or too few of something? Resources, enemies, loot drops, skill points, players in a lobby. Quantity problems are sneaky because they rarely announce themselves. They show up as boredom (too few meaningful choices) or paralysis (too many).
Timing - Are things arriving when the player expects them? A reward that lands three minutes late feels stingy. A difficulty spike that hits before the player has the right tools feels unfair. Timing is the dial that separates a game that "flows" from one that "drags."
These three dials interact with each other constantly. A generous quantity of healing items can mask a difficulty problem. Perfect timing on power-ups can make a brutal encounter feel fair. The art is in how they combine.
Dials Without Context Are Meaningless
Here's the part many balance discussions skip: the dials only work when you know what range to set them in. Three modifiers define that range.
Target audience. A family board game and a competitive strategy title can both be perfectly balanced, but for completely different pressure thresholds. What feels "just right" for a casual mobile player would bore a hardcore optimizer, and vice versa. Knowing who you're building for isn't a marketing question — it's a balance question.
Designer intent. A masocore platformer and a meditative exploration game should not share the same difficulty curve. The intended emotional arc dictates what "balanced" even means. Dark Souls is balanced. Animal Crossing is balanced. They have almost nothing in common mechanically.
Purpose. This is the uncomfortable one. Are you balancing for fun? For session length? For retention? For monetization? These goals overlap, but they also conflict. A system balanced for maximum monetization pressure will feel different from one balanced for pure player satisfaction. Being honest about your purpose keeps you from accidentally building something that feels manipulative.
Progression Is the Silent Test
Players might not articulate it, but they notice when difficulty flatlines. A common design baseline is something like "each level should feel roughly twice as demanding as the last." The exact ratio varies, but the principle holds: by the time a player finishes one challenge, they should be psychologically tuned for the next step up.
When progression stalls, the game feels "off" even if individual encounters are well-designed. Players describe it as the game getting boring or repetitive, but the real issue is that the difficulty-to-skill ratio stopped moving.
The Chess Problem
Is chess balanced? It's been played for centuries, and at elite levels, white has a measurable (possibly psychological) first-move advantage. This raises an interesting point: more skill can reveal more imbalance, not less. Experts exploit asymmetries that beginners never notice.
But in multiplayer games, skill itself can be a balancing mechanism. In Catan, experienced players instinctively refuse to trade with the leader, which reins in runaway advantages. Novices don't do this, so the same game feels less balanced at lower skill levels.
This means "balanced" isn't a fixed state. It's a moving target that shifts with the skill level of your players, which loops right back to knowing your target audience.
So How Do You Actually Know?
You playtest. Relentlessly. You watch where players quit, where they get stuck, where they skip content, where they stop spending (or start spending too much). You build dashboards that track the dials — difficulty curves, resource accumulation rates, time-to-reward — and you compare what you see against what you intended.
Balance isn't a destination. It's a practice. The dials are difficulty, quantity, and timing. The range is set by audience, intent, and purpose. Everything else is iteration until the feeling clicks.

Progression Curves in Game Design: Why Good Systems Feel Invisible (and Bad Ones Feel Like Grind)

Sam Novak — Fri, 03 Apr 2026 12:05:43 +0000

Progression systems are everywhere in games.

Leveling up. Unlocking content. Improving stats. Scaling difficulty.

But most players don’t think in terms of curves or formulas.
They feel something else:

momentum
fairness
excitement
frustration

Behind all of that is a simple idea:

Progression is the relationship between effort and reward over time.

And that relationship is defined by curves.

Progression Is Not Just Growth — It’s a Tradeoff

At its core, progression is not about “getting stronger.”

It’s about trading one resource for another:

time - XP
effort - skill
currency - power
attention - progress

This is why progression is tightly connected to economy design.
Every system answers the same question:

How much should a player give to get something in return?

The Hidden Layer: Relationships Between Numbers

Numbers in games don’t exist in isolation.

A sword that deals 250 damage is meaningless unless:

enemies have 25,000 HP
or 200 HP
or your previous weapon did 50

As noted in game economy theory, numbers only make sense in relation to other numbers .

This is where curves come in.

A curve is simply:

How one resource changes as another increases.

The Core Curve Types (and When They Break)

Identity (1:1)

The simplest possible relationship.

1 point → 1 stat
1 resource → 1 outcome

Useful for clarity, but often too flat to drive interesting decisions.

Linear (y = mx)

Predictable scaling.

+10 power → +100 cost
steady, consistent growth

Good for:

readability
balance stability

Bad for:

excitement
long-term engagement

Exponential (y = a^x)

The most seductive — and dangerous — curve.

slow start
rapid escalation
extreme late-game values

Used for:

early progression acceleration
creating long-term goals

The Problem

Exponential curves break at scale.

They:

create grind walls
inflate numbers beyond meaning
force designers to intervene

That’s why most systems:

cap them
flatten them
or transition into custom curves later

Triangular (Controlled Growth)

A middle ground between linear and exponential.

They:

increase steadily
avoid runaway scaling
feel “natural” to players

This is why they appear often in:

board games
progression systems
resource costs

Custom-Crafted Curves (The Real World)

In practice, most systems are hand-tuned.

Designers:

break patterns intentionally
introduce irregularities
adjust for perception, not math

Because perfectly smooth curves often feel… wrong.

Why Smooth Systems Feel Bad

A perfectly balanced system can still feel terrible.

Why?

Because players don’t experience math.
They experience contrast.

That’s why designers add:

spikes → sudden power, breakthroughs
valleys → weakness, tension

These create:

memorable moments
emotional pacing
perceived progression

Without them, systems feel flat and forgettable.

Shared Resources: Where Systems Collide

The real complexity appears when systems share resources.

Example:

gold used for:
- upgrades
- crafting
- progression

Now every decision becomes a tradeoff.

This is where:

strategy emerges
friction appears
balance becomes fragile

The Real Challenge: Multi-Player-State Design

Live games introduce a deeper problem.

You’re not designing one progression system.

You’re designing for multiple players at once:

new players → need fast onboarding
mid-game players → need structure
long-term players → need stability

These goals conflict.

A change that helps onboarding can:

inflate the economy
devalue progression
break long-term balance

This is why many systems feel like compromises.

Hybrid Systems: Predictable + Random

Modern games often combine:

steady progression → structure, fairness
random rewards → excitement, unpredictability

This hybrid approach:

maintains engagement
controls pacing
hides system complexity

But it also introduces risk:

perceived unfairness
loss of player trust

Progression and Monetization

In free-to-play systems, curves are not just design tools.

They are business tools.

Designers may:

slow progression at key points
introduce friction strategically
create resource scarcity

Sometimes even:

obscure real-world value through multiple currencies

The goal is not just balance.

It’s retention and conversion.

Sidequest: Analyzing a Real Game

Take any game with levels.

Plot:

X-axis - Level
Y-axis - XP required

Observe:

Does it start exponential?
Does it flatten later?
Are there spikes or irregularities?

In most cases, you’ll find:

early game - fast progression
mid game - structured growth
late game - controlled slowdown

Because pure curves rarely survive real players.

The Real Insight

Progression is not a math problem.

It’s a perception problem.

Players don’t ask:

“Is this curve correct?”

They ask:

“Does this feel fair?”
“Does this feel rewarding?”
“Does this respect my time?”

Final Thought

If your progression system feels wrong, the issue is rarely:

“the numbers are off”

It’s usually:

“the relationship between effort and reward feels broken”

Fix the relationship - not just the numbers.

Further Exploration

[https://itembase.dev/blog-curves.html]After reading this blog, I realized that progression systems are not just about numbers or formulas.
Good progression is not mathematically correct, it feels correct to the player.

How do you approach progression systems in your projects?
Do you design the curve first, or the player experience?

Designing Game Economies: Why Spreadsheets Eventually Break

Sam Novak — Thu, 26 Mar 2026 13:01:33 +0000

Game economy design almost always starts the same way:

You open a spreadsheet.
You define a few currencies, maybe sketch a progression curve, add some reward tables — and things feel under control. At first. But as your game grows, the economy grows with it. And the tools you started with begin to show their limits.

The Standard Workflow Most Teams Use

If you’ve worked on a game economy, this setup will probably look familiar:
Google Sheets - balancing, numbers, simulations
Miro - mapping systems and flows
Notion - documenting logic and decisions

Each tool solves a different problem. Together, they form a patchwork system.
And that’s exactly where the issues begin.

The Hidden Cost of Spreadsheets

Spreadsheets are incredibly flexible — which is both their strength and their weakness.

1. Complexity Creeps In

What starts as a simple table turns into:

Dozens of interconnected sheets
Deeply nested formulas
Hardcoded assumptions
References that are hard to trace

At some point, the sheet stops being a tool — and

2. Systems Become Invisible

Game economies are systems:

Currencies flow between features
Sources and sinks interact
Changes ripple across the entire game

But spreadsheets don’t show systems — they show data.

So designers compensate by building diagrams in tools like Miro.

Now you have:

Data in one place
System logic in another

And they drift apart over time.

3. Simulation Becomes Fragile

You can simulate an economy in spreadsheets.

But in practice:

Simulations are hard to scale
Small mistakes break large models
Iteration becomes slow

This leads to a subtle but important problem:

Designers test less.

And fewer simulations mean more risk in the live economy.

4. Knowledge Gets Fragmented

When you split your workflow across tools:

Sheets - numbers
Miro - structure
Notion - explanations

There’s no single source of truth.

This creates:

Misalignment between team members
Outdated documentation
Repeated questions and rework

The Real Issue: Tools vs Systems

The core problem isn’t spreadsheets themselves.

It’s that general-purpose tools are being used to manage system-level complexity.

Game economies are:

Interconnected
Dynamic
Continuously evolving (especially in LiveOps)

But the tools are:

Static
Isolated
Not system-aware

That mismatch becomes more painful over time.

When Do These Problems Start Showing?

Not immediately.

Usually when your game reaches:

Multiple currencies (soft, hard, event-based)
Several progression layers
LiveOps features (events, battle passes, offers)
Frequent balancing updates

At that point:

Small changes have large side effects
Tracking impact becomes difficult
Confidence in changes decreases

*What Teams Usually Do Next
*
Different teams solve this in different ways:

Build more complex spreadsheets
Add more documentation
Create more detailed diagrams
Rely more on experience and intuition

These help — but they don’t solve the underlying issue.

They just manage it.

Final Thoughts

Spreadsheets are an excellent starting point for economy design.

They’re flexible, fast, and accessible.

But as your system grows, the cost of maintaining that flexibility increases:

More manual work
More risk of errors
Slower iteration

At some point, the challenge shifts from “how do we design this?”
to “how do we manage the complexity of what we’ve already built?”

And that’s where the real difficulty of game economy design begins.

Recently, while dealing with these exact issues, I came across tools like Itembase.dev that try to approach economy design as a system rather than just a collection of tables.

Not saying it’s the solution — but it did make me realize how much friction in our workflow actually comes from the tools we use, not just the design itself.

If you're working on game economies, I'd be curious:

At what point did your spreadsheet setup start breaking down?