Making a game is not like building software. I know this now.

I am a developer. I’ve been writing code for years. When I decided to make my own game, I figured the hard part was behind me — I already knew how to build things. I had a clear picture of the game in my head, I’d picked a reasonable engine (Godot, since you’re wondering), and I had the kind of calm, rational confidence that only comes from not yet having tried the thing.

That was naive in a specific and extremely instructive way.

What I’ve since discovered is that game development — especially the solo, autodidactic, making-it-up-as-you-go variety — is one of those pursuits where every skill you already have is useful but insufficient, and the skills you don’t have are equally non-negotiable. It’s less “building software” and more “building a small creative studio from scratch, with a staff of one, in disciplines you’ve never worked in, on evenings and weekends, while life continues happening around you.”

Here’s what nobody really explains clearly before you start.

The art problem that nobody explains in time

The biggest shock for a developer coming into game dev is the art. Not in a vague “oh, you’ll need graphics” sort of way — in a very specific, very concrete way that stops the project cold for weeks at a time.

I have, charitably speaking, the visual instincts of someone who has learned to appreciate design intellectually without ever developing the ability to actually produce it. I know what looks good. I cannot make things that look good. These are different skills, and the gap between them is enormous when you’re trying to produce actual game assets.

The estimates are brutal. Reports from solo devs in the trenches suggest that a single decent animated character sprite can take a full week to produce if you’re starting without background. A handful of environment tiles: another few days on top. And the problem isn’t just time — it’s that there’s no internal compass for “done.” With code, you know when something works. With art, you can fiddle indefinitely and still not be certain the result is acceptable. It’s an entirely different relationship with quality, and it does not come naturally to a brain trained to find compile errors.

The only real option, if you don’t want to spend money on pre-made assets or wait for a collaborator who will almost certainly never materialise, is to learn. Which I am doing. Slowly. With varying results.

You are the entire studio

The art gap is just one part of a broader reality that takes a while to fully sink in: you’re not just a developer making a game. You are the programmer, the graphic artist, the sound designer, the composer (or the person desperately searching for royalty-free music that doesn’t sound like a stock video), the level designer, the UX designer, the writer, and — eventually — the person who has to figure out how anyone will ever hear about this thing.

None of these roles overlap much. Being good at one does not make you adequate at any of the others. Programming is programming; art is art; level design is its own discipline with its own literature and its own ways of being wrong. You can get away with being mediocre across several of them if you’re lucky with your scope — but you have to fill every role, because there’s no one else.

The honest truth is that when I sit down in the evening to work on my game, I’m often not sure which hat I’m supposed to be wearing. Sometimes that uncertainty alone is enough to send me in the wrong direction entirely.

You will underestimate everything, every time

I say “every time” because it’s not a mistake you make once. It’s structural. Developer brains plan carefully — that’s the job — but game dev scope estimation requires a kind of lived experience you can only get by having been wrong before, and the first game is made almost entirely of firsts.

The pattern plays out like this: you estimate a feature. It seems reasonable. You start implementing it. Something turns out to be more complicated than expected. That thing connects to two other things that also turn out to be more complicated. The feature that was going to take two days takes two weeks. You adjust your estimates. Then it happens again.

Experienced people in the indie space have put the multiplier somewhere between three and five — assume any task will take three to five times longer than your first instinct. For a developer used to having decent instincts about technical timelines, this is a genuinely destabilising experience.

The perfect system that the game doesn’t need

Here is where I have to be honest about a specific developer failure mode, because I am living in it.

The programmer in me wants the code to be clean. Well-architected. Properly abstracted. I have spent full evenings designing systems not because the game needed them imminently, but because I wanted to get them right before I needed them. I have refactored things that only existed in a prototype state. I have built elegant scaffolding for features I haven’t designed yet.

Meanwhile, the game doesn’t move forward.

The technical rabbit hole is a developer superpower in software work — the ability to go deep, really understand a system, do it properly. In game dev, it’s often a trap. The goal is a finished, playable game, not a beautifully architected codebase that ships nothing. These two things are in tension, and the tension is harder to manage than I expected.

Then there’s the related loop: your skills improve as you build, which means the code you wrote three months ago now looks exactly as bad as it actually was. The temptation to go back and clean it up — or in bad cases, restart entirely — is real, persistent, and very good at disguising itself as responsible engineering. It isn’t. The game you restart is never better than the game you finish.

The silence that nobody mentions

Solo development means no team. This one sounds obvious until you’re actually in it.

There’s no one to rubber-duck with. No code review. No one to notice when you’ve been stuck for four hours on something you should have asked about. No one to push back when your scope is quietly expanding again, or to tell you that the third version of the level you just rebuilt is not actually better than the first one.

It’s also just quiet in a way that wears on you over time. Building something is energising, but building something that no one sees, with no feedback loop and no external milestone, requires a particular kind of sustained internal motivation. On a good evening that’s fine. Over weeks and months, it asks more from you than it looks like it should.

The burnout risk isn’t dramatic. It doesn’t arrive as a crisis. It arrives as an evening where you sit down to work and just… don’t quite start. Then that happens two evenings in a row. You don’t really name it — you just notice the project has stalled.

---

This is the terrain. Six things I walked into without fully understanding, and I’m honestly not through any of them yet.

The odd thing is that none of it has made me want to stop. A software developer trying to produce something creative out of nothing is not the same discipline as building software, and I’m still working out how to do it. But the project is still there. The idea is still sharp.

I keep opening the project. That’s probably enough.