Which Engine Should You Use to Make a Game with AI?

People ask me this a lot, so let me lay out the background first. I've used both Unity and Unreal for at least four years each, and this year I spent four months building a game with Unreal + AI, with a Demo already up on Steam. But I used Unreal because I already knew it well. Recently I tried the much-talked-about Godot + Codex combination — and that was the first time I understood what people mean by "taking off."

There are really only three mainstream game engines right now: Unity, Unreal, and Godot. Each has its own strengths across the board. But after using them, my sense is that for someone starting out with AI, the engine's most important capability is AI participation — and that splits into two layers: how far AI can take part, and how hard it is to let it.

The further AI can take part, the less you actually need to learn the engine itself — how to write its code, how to drive its editor. And the lower the friction, the less tooling you have to wrestle with at the start, the faster AI runs, and the fewer tokens it burns. Godot's real strength is that, of these three engines, AI can take part the most fully — which comes down to the engine's underlying design, and I won't go into that here.

Here's how it went when I used Unreal with AI: I already knew the engine, so AI would write some of the pure logic and calculations, and then I'd wire those together with Blueprints inside the engine. Where I got stuck, AI would tell me how to connect the Blueprint nodes, and I'd follow its lead. And if something broke at that point, I still had to isolate and test what I'd written separately from what it had written.

Even with the 5.8 MCP now, reading Blueprints is still a slow process — never mind the tokens, the Blueprints AI writes are hard to read. My Unreal project is gradually replacing that Blueprint content with C++, precisely because Blueprints are so hard for AI to parse that it can't understand the logic of my whole project.

Switching to Godot was a completely different story. I wrote up a design doc, told the AI "I've installed Godot over here," and it just went to work: it even created the project folder itself. It set up the project files, did the configuration, wrote the code, ran it, hunted the bugs — and then, from a visual reference I gave it, it drew a rough first pass at the UI and packaged a build for me to test. Through the whole flow, I never once opened the editor.

And I still can't use Godot at all: I don't know GDScript, I don't know the interface, I just know there's a play button up top that runs the thing. That's how extreme it is. On the side, I ran a little bottom-of-the-screen idle-game experiment with it — a few days in, a good chunk of the core features and art are already there.

This is the real point I want to make. Before AI, "learning to make games" mostly meant learning how to use an engine to build out the project. Now, the focus can shift much more toward the entire path — from a game concept all the way to a finished, shipped result.

For instance, you can put far more of your energy into questions like these: who's your platform audience, and what's the business model — an ad-supported casual game, a premium indie title, or a live-service mobile game? Who are your players? Where are they when they play? Why do they enjoy games like this? What's the core loop? How do you design positive feedback? How do you settle on an art style? How do you build atmosphere? How does the player experience actually get delivered? How do you plan the project timeline, control the schedule, and market the thing?

These parts matter enormously, but they get overlooked all the time — and that's what sinks projects in the end. These are what a solo dev or small team should learn first — not, as before, pouring all your energy into "what's this panel for, what's that panel for, what's object-orientation, how do I print a Hello World."

The technical thing worth learning is the logic and flow of how a game engine implements its various features: scenes, lighting, materials, models, collision, animation, particles, and so on — and most of that is shared across engines.

The only reason I could get a roughly-right result out of AI on an engine I don't know at all, just by handing it a design doc, is that my experience with the other two engines was doing the work. I know, for each piece of tech in the game I've designed, what the implementation logic is; I can build the path and the final result in my head. That's what let me use AI to get a fully controllable result on an engine I can't use myself. And Godot happens to be the easiest place to pick up this shared, cross-engine technical logic.

1. 01Choose the engine by "AI participation."If you don't have a fixed career direction or a language you're tied to, start with Godot — of the three mainstream engines, AI can take part the most, with the least setup to wrestle.
2. 02Move your energy from "learning the tool" to "learning to make games."Audience, business model, core loop, positive feedback, art style, timeline, marketing — the things that used to get overlooked yet decide whether a project lives are what to learn first.
3. 03Learn the shared technical logic.Scenes, lighting, materials, collision, animation, particles — the cross-engine implementation logic is what lets you get a controllable result on any engine, with AI's help.

I think future game developers will gradually reach "engine independence." No longer, as before, boxed into one engine by how well you know a language and an editor — where learning Cocos meant you'd make casual games, Unity meant mobile, Unreal meant AAA. From now on, once you understand the logic these engines share, moving between them with AI's help becomes easy. You're no longer married to any one engine; you can switch whenever you like. As for locked-down "local special editions" and expensive watermark schemes — against this direction, they only matter less and less.

You're no longer married to any one engine. You can switch whenever you like.