DEV Community

Cover image for Your indie game didn't fail because of bad code. It failed because of bad design.
Hiroshi TK
Hiroshi TK

Posted on

Your indie game didn't fail because of bad code. It failed because of bad design.

I've had this conversation more times than I can count.

Someone tells me they're making a game. I ask what they do on the project. "I'm a game developer," they say. I ask if they have a game designer. Blank stare. "Isn't that the same thing?"

No. It is not the same thing. And this confusion this seemingly harmless mix-up is quietly killing indie games before they ever have a chance.


Let me be blunt about what game design actually is

Game design is not making assets. It's not writing code. It's not even making levels, necessarily.

Game design is the discipline of making decisions about how a game feels, behaves, and communicates with the player. It's asking: what does the player do, why do they do it, and how do they feel when they do?

A game designer decides that the jump in a platformer should have 12 frames of coyote time. They decide that a reward should come every 90 seconds on average to maintain engagement. They write the design document that explains why a mechanic exists and what it's supposed to accomplish emotionally.

A developer builds the jump. A designer decides what the jump should feel like and why it matters to the player.

Neither role is more important than the other. But they are completely different jobs, with completely different skill sets, and completely different ways of thinking about problems.


Why does this confusion exist?

Honestly? Because the word "game" is in both titles and that's enough to make people assume they overlap.

There's also a cultural thing happening. Game development tutorials are everywhere. You can learn Unity in a weekend. You can ship a prototype in a game jam. So when someone wants to make games, they learn to code, they make something that runs, and they call themselves a game developer. Which is completely valid.

But game design isn't taught the same way. It doesn't have a tutorial. You can't just follow along and produce an output. It requires studying player psychology, understanding feedback loops, analyzing what makes an interaction feel satisfying and then making thousands of small decisions that nobody notices unless they go wrong.

So most indie devs skip it. Or more accurately, they do it accidentally, without realizing it, and without the vocabulary or frameworks to do it well.


Here's where indie games actually die

I want to push back on something the indie dev community tells itself.

We love blaming failure on marketing. "The game was good, it just didn't get seen." Sometimes that's true. But more often and I say this as someone who has played a lot of indie games the game wasn't good. The core loop wasn't satisfying. The progression felt arbitrary. The player never understood what they were supposed to want.

That's not a code problem. The code works fine. That's a design problem.

A technically perfect game with a broken design loop will feel like work. Players will put it down in 20 minutes and not know why. They'll say "it wasn't for me" but what they mean is "I was never told why I should care."

Player retention, the feeling of progression, the moment-to-moment satisfaction of interacting with your game world all of that is designed, intentionally, by someone who understands systems and psychology. When nobody on your team is doing that job, it shows.


What game design actually looks like in practice

Here's a simple example. You're making an RPG. You add a loot system enemies drop gear. A developer's job is to make it work: the drop rate is a float, the item table is populated, the UI shows the item when it drops.

A designer's job is to decide: what drop rate creates excitement without frustration? How rare is rare enough to feel special, but not so rare the player gives up? Should legendary drops feel surprising or expected? What's the emotional beat of getting a rare drop and how do you amplify it through sound, animation, and UI so it actually lands?

That's the work. It's invisible when it's done well. It destroys games when it's missing.


So what do I actually want you to take from this?

If you're building an indie game solo or with a small team, I'm not saying you need to hire a dedicated game designer. I'm saying you need to do the game design intentionally, explicitly, not as an afterthought.

That means before you code a system, you ask: why does this exist? What is the player feeling when they interact with it? What behavior am I incentivizing?

It means playing your own game critically, not just testing if the bugs are gone, but asking: is this fun? Why or why not? What would make this feel better?

It means understanding that "it's not fun yet" is a design problem with a design solution not a bug to be fixed or a feature to be added.

Most indie games fail because someone built a technically functional product and called it done. Design is the gap between "it works" and "I can't put this down."


Are you an indie dev who does both roles yourself, or do you have a dedicated designer on your team? I'm curious how others split this drop a comment below.

Top comments (0)