How to Launch an Indie Game in 2026: The Three Pillars

Pillar one: an anchor people recognize#

Before the engine, before a single line of code, you need something to build around. For me that was a character.

Meet Leiloo Sharkind. She’s a colorful girl who loves helping others, and she is half-human, half-shark. You might not tell just by glancing at her, but the sharp teeth and the fact that she breathes underwater give it away.

Her mission isn’t to save the world. It’s to help her Shark Friend collect pies.

That sounds small. It’s supposed to. A goal that fits in one sentence is a goal you can actually build a game around, and it’s hers, which is the part that matters.

Here’s what makes an anchor work, and it’s the same three things every time. A silhouette you’d recognize in one color. A palette that stays the same everywhere she shows up. One detail that makes no sense until you know her, like teeth on a girl who mostly wants to be helpful.

Don’t build a generic soldier. Don’t build a blob. Spend the time on a character with a specific look and a specific goal, because once you have one, the world stops being a thing you invent from nothing. It becomes a place they need. You aren’t forcing a game into existence anymore. You’re building them a home.

If you want to see how far one character can carry a project, the whole cast and world of my game lives in the Shark’s Request album.

Pillar two: open the engine and break it#

Second, you actually open Unity or Unreal. Not a tutorial about opening it. The engine itself.

The best advice I can give you is to stop trying to make the whole game at once.

Don’t build level ten. Make the character move. Then make them jump. Then spend an afternoon making the jump feel good, because that afternoon teaches you more than ten tutorials will.

You will break the code. The physics will glitch and send your character into the sky. The art won’t load and you’ll get a bright pink rectangle where your sprite should be.

Good.

That frustration is the actual job. If nothing is breaking, you aren’t building anything new, you’re copying. The work was never typing code perfectly. The work is fixing it when it breaks, and every fix is a thing you now know that you didn’t know yesterday.

Start with one small thing that works, then make the next small thing work. That’s the whole method, and it’s easier in 2D, which is why I’d start there. Two of the fixes that ate my early days are written up here: getting rid of sticky walls in Unity and adding a 2D collider to sprites.

Pillar three: believe in the scale of your own work#

Third, and this is the one nobody tells you: you have to treat your project as if it’s already big.

My game premiered in a cinema. Seeing Shark’s Request projected on a screen that size proved something I keep coming back to.

The screen doesn’t care how big your team is. It only cares about the vision.

That’s not a motivational line, it’s a practical one. It changes what you make. Design an icon that would survive being blown up ten feet tall. Write a description you’d be fine reading out loud to a room. Pick a name you’d want on a poster. When you respect your own project, other people take the cue from you.

Design your game as if it belongs in a theater, because one day it might.

The part that comes after#

Three pillars: a character worth anchoring to, an engine you’re not afraid to break, and the nerve to treat small work seriously.

None of them costs money. All of them cost attention.

Shark’s Request is coming to Steam soon, and everything above is what got it there.