A game developer's firsthand experience with AI-assisted workflows
March 2026
The Moment It Clicked
I've been building a detective RPG inspired by Ace Attorney — the kind of game with branching dialogue trees, courtroom cross-examinations, and dozens of interconnected scenes. I started in Unity, which felt like the obvious choice. It's what I knew, it's what most tutorials cover, and it has a massive ecosystem.
Then I migrated to Godot and started using AI coding assistants — specifically Claude Code — to help me architect and build the game systems. The difference was so striking that I started paying attention to why. It wasn't that the AI was smarter with one engine. It's that one engine is fundamentally more readable to AI than the other.
This isn't a general Godot-vs-Unity debate. Both are capable engines. This is about a specific question: if you plan to use AI tools as a core part of your development workflow, which engine makes that collaboration smoother?
Everything Is a Text File
The single biggest reason AI works better with Godot comes down to file formats. In Godot, virtually everything your project contains is stored as human-readable text:
- Scripts (.gd) — GDScript is a Python-like language. Plain text, no compilation step needed to understand the code.
- Scenes (.tscn) — Godot's scene files are a text-based format that describes every node, property, and connection in the scene tree. You can open one in any text editor and read it.
- Resources (.tres) — Custom resources, materials, themes — all stored as readable text.
- Project config (project.godot) — A plain INI-style file listing autoloads, input mappings, and settings.
This matters because AI coding assistants work by reading and writing text. When an AI tool can read your scene file and understand that a DialogueBox node is a child of a CanvasLayer, with specific properties set to specific values, it can reason about your game's structure and make informed suggestions.
Unity's Binary Problem
Unity stores scenes (.unity) and prefabs (.prefab) in a YAML-like serialized format that is technically text, but barely human-readable. Every object reference is a numeric fileID, relationships are expressed through GUIDs, and the structure is deeply nested with Unity-internal metadata. Even with "force text serialization" enabled, a simple scene with a few GameObjects produces hundreds of lines of dense, ID-heavy YAML.
Here's the same scene from my game — a bedroom the player starts in — as it appears in both engines:
Unity (.unity) — 60+ lines just for render settings
%YAML 1.1
%TAG !u! tag:unity3d.com,2011:
--- !u!29 &1
OcclusionCullingSettings:
m_ObjectHideFlags: 0
serializedVersion: 2
m_OcclusionBakeSettings:
smallestOccluder: 5
smallestHole: 0.25
backfaceThreshold: 100
m_SceneGUID: 00000000000000000000000000000000
m_OcclusionCullingData: {fileID: 0}
--- !u!104 &2
RenderSettings:
m_Fog: 0
m_FogColor: {r: 0.5, g: 0.5, b: 0.5, a: 1}
m_FogMode: 3
...(continues for 40+ more lines of metadata)
Before the AI even reaches the actual game objects, it must wade through pages of rendering configuration, lightmap settings, and serialization IDs. None of this tells the AI anything about the game's logic or structure.
Godot (.tscn) — the entire scene in 10 lines
[gd_scene load_steps=3 format=3]
[ext_resource type="PackedScene" path="res://scenes/chapter_template.tscn" id="1"]
[ext_resource type="Texture2D" path="res://sprites/backgrounds/myroom.png" id="2"]
[node name="ChapterScene" instance=ExtResource("1")]
chapter_json = "chapter2_0_myroom"
[node name="Background" parent="." index="0"]
texture = ExtResource("2")
That's it. The entire scene. An AI can read this and immediately understand: this scene inherits from a chapter template, loads a specific conversation JSON file, and uses a bedroom background image. Every line carries semantic meaning — there's no noise.
When an AI assistant encounters a Unity scene file, it's essentially reading a database dump. It can parse the syntax, but it can't easily understand the intent. Godot's .tscn format, by contrast, reads almost like a description of the scene.
GDScript: A Language AI Actually Knows Well
GDScript is a small, focused language designed specifically for game logic. It has around 850 built-in classes, a consistent API, and Python-like syntax. Compare that to C# in Unity, where you're working with the full .NET ecosystem plus Unity's own APIs, editor classes, serialization attributes, and coroutine patterns.
This matters for AI in two ways:
Less Ambiguity
When you ask an AI to write GDScript, there's usually one idiomatic way to do things. Signals are signals, exports are exports, the node tree is the node tree. In Unity C#, the same task might be accomplished with UnityEvents, C# events, ScriptableObject channels, or a message bus — and the AI has to guess which pattern your project uses.
Smaller Surface Area
GDScript's API is entirely game-focused. An AI generating GDScript won't accidentally suggest patterns from web development, desktop applications, or server-side code the way it might with C#. The code it produces is specific to Godot's use case.
That said, there is a trade-off. GDScript has a smaller training corpus than C#, which means AI models occasionally hallucinate Python idioms that don't exist in GDScript. In my experience, this happens less with more capable models and is easy to catch — the Godot editor flags these immediately. The overall accuracy of AI-generated GDScript has been high enough that the speed gains far outweigh the occasional correction.
The Architecture Advantage: Signals and Scene Trees
Godot's design philosophy encourages a specific architectural pattern: scene trees with signal-based communication. Every game object is a node in a tree. Nodes communicate by emitting signals. Systems stay decoupled.
This pattern is extraordinarily AI-friendly because it's consistent and compositional. When I described my game's requirements to Claude Code, it immediately proposed an EventManager autoload (a global signal bus), a three-layer separation of data, systems, and UI, and a rule that systems never call each other directly. This wasn't generic advice — it's the natural architecture that Godot's design encourages.
Unity doesn't enforce a particular architecture, which is both a strength and a weakness. For AI-assisted development, it's mostly a weakness. The AI has to first understand which of the many possible Unity patterns you're using (MonoBehaviour singletons? ScriptableObject events? Dependency injection? ECS?) before it can help effectively. With Godot, the conventions are baked into the engine itself.
A Side-by-Side Comparison
Here's how specific aspects of AI-assisted development compare between the two engines, based on my experience building the same game in both:
| Aspect | Godot | Unity |
|---|---|---|
| Scene files | Text-based .tscn, AI can read and reason about them | Serialized YAML with GUIDs, hard for AI to interpret |
| Script language | GDScript: small, focused, game-specific | C#: powerful but large surface area, multiple patterns |
| Project config | Single project.godot file, plain text | Multiple meta files, ProjectSettings assets |
| Prefabs | Scenes (.tscn) — same readable format | .prefab files with nested GUID references |
| Architecture | Signals + scene tree (one clear pattern) | Many valid patterns (events, SO, DI, ECS) |
| Version control | All text, clean diffs | Requires force-text mode, still noisy diffs |
| AI code generation | One idiomatic style per task | Multiple approaches, AI must guess your pattern |
| Error feedback | Editor flags GDScript errors immediately | Compile-time C# errors (slower feedback loop) |
What This Looks Like in Practice
Let me share a concrete example from my project. I needed to design a courtroom cross-examination system — the core mechanic of an Ace Attorney-style game. This involves:
- A state machine cycling through testimony, cross-examination, and verdict phases
- Witness statements the player can navigate through
- A "press" action to question witnesses and a "present" action to show evidence
- A penalty system that tracks wrong answers
- Evidence matching against specific contradictions in testimony
I described these requirements to Claude Code. Because it could read my existing project files — the dialogue system JSON, the scene templates, the game data models — it designed a complete court system architecture that integrated naturally with what I already had. It proposed a JSON format for court cases, a state machine that reuses my dialogue system for narrative phases, and signal-based communication between the court logic and the UI.
The key insight: the AI could do this because my entire project was legible to it. Every script, every scene, every data file was plain text that it could read, cross-reference, and reason about. If my scene files had been binary blobs or dense GUID-laden YAML, the AI would have been working with far less context.
The Growing Ecosystem
The AI-assisted Godot development ecosystem is maturing quickly. Developers have built MCP (Model Context Protocol) integrations that let AI assistants interact directly with the Godot editor — creating scenes, reading errors, and modifying resources programmatically. There are Claude Code skills specifically designed for Godot that provide structured guidance on GDScript patterns and project architecture.
One project, Godogen, demonstrates that AI can generate complete Godot 4 projects from natural language descriptions — with proper scene trees, scripts, and asset organization. This works because Godot's formats are simple enough for AI to generate correctly. Attempting the same with Unity would require the AI to produce valid GUID references, serialized MonoBehaviour data, and properly linked meta files — a much higher bar.
When Unity Still Makes Sense
This isn't a one-sided argument. Unity remains the stronger choice in several scenarios, even with AI assistance:
- 3D-heavy or AAA-scope projects — Unity's rendering pipeline, asset pipeline, and tooling for large teams are more mature.
- Platform-specific features — Unity's console support and platform abstraction are deeper.
- Existing C# expertise — If your team is deeply fluent in C# and .NET, the familiarity advantage is real.
- Unity's own AI tools — Unity is investing heavily in its own AI features, including Muse for asset generation and an AI coding assistant that understands Unity's context.
The AI readability advantage I'm describing matters most for indie developers and small teams using general-purpose AI coding assistants (Claude, Cursor, Copilot) as a primary workflow tool. If you're a solo developer building a 2D narrative game and you want AI to be your architecture partner, Godot is the better foundation.
The Bottom Line
The reason AI works better with Godot isn't about the AI being trained more on one engine than the other. It's about transparency. Godot stores everything as readable text, uses a focused scripting language, and encourages a consistent architectural pattern. These are exactly the properties that make a codebase legible to an AI assistant.
If you're starting a new game project and plan to use AI tools as a core part of your workflow, consider this: the engine you choose determines how much of your project the AI can actually see. With Godot, the answer is everything.
About the Author
The author is an indie game developer building Legend of Tang, a detective RPG set in the Tang Dynasty. The game is built in Godot 4.2 with GDScript and developed with the help of AI coding assistants. My previous game was The Crack (壳中之物).
Top comments (0)