/ Game Dev With AI / How to Make a Game With AI and Actually Ship It
Game Dev With AI 14 min read

How to Make a Game With AI and Actually Ship It

The honest end to end of how to make a game with AI, where it helps, where it faceplants, and why finishing a small game is the real bottleneck.

How to make a game with AI and actually ship it

Almost every result for how to make a game with ai is selling the same fantasy. Type one sentence, get a finished game back. I build and ship small games in Godot, and I can give you the short version right now. You can't. AI will not hand you a done game from a prompt, and most of the tools promising exactly that are counting on you not knowing the gap between a playable toy and a thing you'd actually let a stranger play.

So here is what does work. You use AI where it genuinely helps, which is coming up with ideas, roughing in boilerplate code, and faking art and sound early so you can find out whether the idea is even fun. Then you build the real game yourself, in a real engine. The hard part was never the engine and it was never the AI. It's scope, and it's finishing. Almost nobody writing about this will tell you that, because "you have to finish the thing" doesn't sell a subscription.

What "Making a Game With AI" Actually Means

Go look at the first page of Google for this exact search. I did, the day I wrote this. Nearly the whole top ten is AI game generator landing pages, Rosebud, Astrocade, Replit, upit, a handful of others, plus one Reddit thread and a couple of YouTube videos. Every single one of those tool pages promises you a game from a description and none of them, not one, mentions a single limitation.

I don't hate those tools. Some of them are fun for an afternoon. But there's a difference between a tech demo you generated in your browser and a game, and the difference is roughly all the work. The generated thing runs. It has no reason to exist, no second minute of interest, no ending, nothing that makes a person stay. That last ninety percent is the game. The AI gave you the first ten and told you it was the whole thing.

The honest way to think about it is that AI is a very fast, very confident junior teammate. Brilliant at grunt work. Completely lost on judgment. Once you hold it to that, it becomes genuinely useful instead of a disappointment, and you stop waiting for a tool that's going to make the game for you. That tool isn't coming. If it were, the people selling it would just make hit games instead.

Where AI Pulls Its Weight

This is the part I want people to take seriously, because "AI is useless for games" is as wrong as "AI makes the game." Neither is true. It helps in specific places, and knowing which places is most of the skill.

Ideas first. When I'm staring at nothing, I'll ask a model for thirty tiny game concepts built around one constraint, like "cozy, one screen, no text." Most of them are junk. Three or four spark something, and one of those becomes a prototype. It's a better brainstorming partner than it is a designer, which is a real distinction. I wrote up how I actually run that step over in AI game design ideas, because it's easy to do badly and get thirty flavors of the same boring idea.

Then boilerplate. GDScript for a top down player controller, a spawn timer, a simple finite state machine, a save system skeleton. This stuff is close to identical across ten thousand projects, and AI writes it fast and mostly correct. I still read every line, and I still fix the parts where it invented a Godot method that doesn't exist, because it does that a lot. But roughing in the skeleton in twenty minutes instead of two hours is a real gift when your motivation is fragile, and early on your motivation is always fragile. There's a longer breakdown of the tools I lean on in the best AI game dev tools.

Art and sound, third. Here's the move almost nobody teaches. Before you commit a week to an art style, generate placeholder sprites and a rough music loop and drop them in, just to feel it. Does this cozy thing actually feel cozy with soft pastels and a slow pad underneath, or was that only cozy in your head? You find out in an afternoon instead of a week. The generated art usually won't ship, it wobbles between styles and the animation reads wrong, but as a way to test a vibe it's fantastic. I go deeper on that whole workflow in AI game art. I run most of that generation locally on an M4 Pro, so the marginal cost of throwing forty placeholder sprites at a bad idea is basically nothing, which changes how freely you experiment.

Where AI Faceplants

Now the other side, and this is the honest bit the tool pages skip.

AI cannot tell you if your game is fun. It has never been bored. It doesn't know that your third level drags, that the jump feels floaty, that the reward comes half a second too late to land. Game feel lives in your hands and your gut, and a model that has read every design book ever written still can't feel a single frame of your build.

It also falls apart the moment your project stops looking like a tutorial. The first hundred lines it nails. Then your scene tree has your specific weird structure, your signals are wired your specific weird way, and the "help" turns into confident nonsense that references nodes you don't have. I've watched it suggest the same non existent fix four times in a row, cheerfully, like a GPS routing you into a lake.

And it will not finish anything. It has no stake in the thing existing. It won't feel the drag of week three when the fun is gone and there's only bug list left. That drag is where games die, and no model is going to carry you across it. Here's the same idea as a table, because I think people need to see the two columns side by side.

Stage What AI Is Genuinely Good At Where It Faceplants
Idea and design Throwing thirty concepts at you, remixing genres, naming things Knowing which one is actually worth building
First code Boilerplate GDScript, movement, timers, a state machine skeleton Your specific scene tree once the project grows past a tutorial
Art Placeholder sprites so you can test a feeling before committing A consistent style across forty assets, animation that reads
Sound and music Rough loops to fill the silence while you build A final mix that actually fits the moment
Content and levels First pass layouts, filler variety Pacing, the difficulty curve, the third hour boredom problem
Game feel Suggesting tweaks once you describe what's wrong Noticing what's wrong in the first place
Bugs Reading a stack trace and guessing the cause Bugs that exist only because of how you wired three systems
Finishing Nothing, honestly Everything

That bottom row is the whole article, really. Finishing is the one stage the machine gives you zero help with, and finishing is the one stage that separates a game from a folder of abandoned prototypes.

The Real Pipeline, Idea to Something Playable

Let me walk the real path, the one I use, so this isn't all opinions and no steps.

It starts with an idea small enough to finish in a couple of weekends, not the dream game. That constraint is not a limitation, it's the single most important design decision you'll make, and I'll come back to why. AI helps me generate and narrow the idea, then I write a design doc that fits on one page. If it doesn't fit on a page, it's too big, and I cut until it does.

Prototype next. I open Godot, which is free and open source under the MIT license, no royalties, no per title fee, and you own your game outright. That last part matters more than beginners realize. Godot's own license page says it plainly, you are free to license your games however you see fit and you're the sole copyright owner. Compare that to engines that take a cut when you succeed. For a solo person shipping small things, keeping one hundred percent of the upside is the correct default.

Inside Godot I get the core loop running with a lot of AI assisted boilerplate and ugly placeholder art. Ugly on purpose. The only question at this stage is whether the loop is fun for sixty seconds with programmer art and no polish. If it's boring now, it will be boring later with nicer sprites, and a lot of dead projects are just boring prototypes someone decorated instead of fixing. If you have never opened the engine at all, I wrote a gentler starting point at make your first game in Godot, which walks the very first build without assuming you know what a node is.

If the loop survives that test, then I invest. Real art, real sound, the second minute of content, an actual start and end. This is the long unglamorous middle where AI helps least and quitting tempts most. Then testing, then a build, then it goes up somewhere a human can click it. I ship mine on my own site over at kevingabeci.com, which keeps the whole thing simple and mine.

Notice how little of that is AI, and how much of the AI that's there lives in the first third. That ratio is the honest shape of making a game with AI in 2026. It front loads the help and then leaves, right when the work gets hard.

Why Finishing Is the Real Bottleneck

Okay. The thing I actually came here to say.

The engine is not your problem. The AI is not your problem. I have a folder of shelved Godot builds, and I keep every one of them, because each abandoned project taught me exactly where I over scoped. Not one of them died because Godot couldn't do it or because I couldn't get an AI to write a function. They died because I designed something that needed three months of my life and I had two weekends of motivation, and the gap between those two numbers is where the corpse showed up.

Scope is the disease. Finishing is the cure, and it's a skill you build the same way you build any skill, by doing the small version enough times that your sense of "how big is this really" gets calibrated. New developers are catastrophically bad at estimating scope, myself very much included, and AI makes this worse, not better, because it will happily agree that yes, your MMO is a great first project and here's some boilerplate for the login screen. It has no instinct for what's finishable. You have to supply that, and at the start you barely have it, so you compensate by aiming embarrassingly small.

My honest advice, and I mean this, is to make the game so small it feels stupid. One mechanic. One screen. Ten minutes of play. Ship that. Because a finished ten minute game teaches you more than a beautiful unfinished dream game teaches you across a whole year, and the finishing muscle is the only muscle that actually transfers to the next project. Every working small dev I know got good at finishing before they got good at anything else. The order matters.

Getting It Out the Door

Shipping sounds like the end. It's really its own little stage that people forget to plan for, and then it stalls the whole thing at the finish line.

You need somewhere to put the game. For a first release I'd point you at itch.io, which costs nothing to publish. Their revenue sharing is what they call open, meaning you literally choose what percentage goes to them, which is unusually creator friendly and great for a first ship where you just want the thing live. Steam is the bigger storefront, but it charges a one hundred dollar Steam Direct fee per game, recoupable once that game clears a thousand dollars in sales, and it's a gatekept, higher effort release you probably don't want for your very first tiny thing. Your own site is the third option, zero platform cut, total control, but you bring every single visitor yourself, which is a real cost that just isn't denominated in dollars.

Where You Ship Cost To Publish The Cut They Take
Your own site Basically just hosting Nothing, but you supply all the traffic
itch.io Free Whatever share you choose to give them
Steam $100 per game, recoupable after $1,000 in sales The standard store cut, worth checking their current terms

Whatever you pick, the point is the same. The game has to leave your machine. A game only you have ever played isn't finished, it's a hobby with extra steps, and I say that as someone who spent a long time confusing the two. Getting one small thing all the way onto the internet where a stranger can break it teaches you more than the next five prototypes will.

Straight Answers to What People Keep Asking

The search results are full of the same handful of questions, so here are plain answers.

Can you create a game with just AI? No, not a real one. You can generate a playable prototype with just AI, and for a browser toy that might even be enough. But a game people finish and remember still needs a person making the judgment calls the AI can't, on fun, on pacing, on when it's actually done. The prototype is the easy ten percent.

Can ChatGPT make games? It can write code and design docs, and it can one shot a very simple single file browser game if you keep it tiny. What it can't do is be the developer. You're still the one deciding what to build, wiring it into an engine, testing whether it's fun, and dragging it across the finish line. Think of it as the fastest junior coder you've ever worked with, not a replacement for the work.

Is it legal to make a game with AI? Mostly yes, and I'm not a lawyer, so take this as a developer's read and not legal advice. Your code and your own assets are yours, and with an MIT engine like Godot you own your game completely. The genuinely murky part is generated art and audio, where the training data provenance and the ownership rules are still unsettled and vary by where you live and where you sell. If you're shipping commercially, that's the corner to actually research rather than guess at.

Do nearly ninety percent of game developers use AI now? There's a stat like that floating around the results, and I'd want to see who ran the survey before I lean on it. But say it's roughly true. Look at what it actually claims. Developers use AI. It does not say AI made the games. Those are very different sentences, and the whole confusion this article is fighting lives in the gap between them.

Your First Small Game

If you take one thing from all of this, make it the scope, not the tools.

Pick an idea you could finish in two weekends and then cut it in half, because your estimate is wrong and it's wrong in the same direction as everyone else's. Use AI to brainstorm it, to rough in the boring code, to fake the art and sound so you can test the feeling fast. Build it in Godot. Get it fun with ugly placeholder art before you spend one hour making it pretty. Then finish it, and put it somewhere a stranger can play it, even if it's small enough to embarrass you.

The developers who make it aren't the ones with the best AI setup or the fanciest engine. They're the ones who got good at finishing small things, over and over, until the small things stopped being small. That's the whole game, honestly, and no prompt is going to do it for you.