We use Claude to write C++, modify Blueprints, and manage our entire production pipeline at Sackbird Studios. The hardest part has nothing to do with AI. It's the file format.
Unreal Engine stores nearly all editor-created content (Blueprints, materials, animation state machines, UI layouts, level files) as binary .uasset files. An AI agent with filesystem access can't read any of it.
Unity and Godot store that same content as text, and that one difference has become the biggest gap in AI-assisted game development. Binary formats exist for good reasons — load times, package size, console memory budgets — and those tradeoffs made sense when only humans needed to read project files. This isn't an argument to switch engines, it's about understanding what the format costs when AI tooling arrives.
And it's not a new problem. The game industry has been paying for binary assets since Perforce became the standard. AI just made the bill bigger.
What lives in a .uasset
Every .uasset file starts with the same four bytes: 0x9E2A83C1.[1] After the magic number comes a variable-length header (FPackageFileSummary) containing version fields, package flags, and byte offsets to three core tables: the Name Map (all string identifiers), the Import Map (external dependencies), and the Export Map (objects defined in the file). Every time you create something in the Unreal Editor, this is where it goes.
versions, offsets, flags
"None", "MyBlueprint", "EventGraph", ...
referenced by index
component hierarchies
The format itself is well-specified and the modding community has reverse-engineered it thoroughly, and UAssetAPI can parse everything from ~UE 4.13 to 5.3[2]. The problem isn't that we can't read the container. It's what's inside.
Blueprint logic compiles through a 9-stage pipeline[3] from visual graph nodes to Kismet VM bytecode. Opcode instructions stored as a TArray<uint8> in UFunction::Script.[4] The visual graph has spatial layout, pin connections, comment blocks, semantic groupings. The bytecode has jump offsets and flat instruction streams. Going from one to the other is compilation, and going back is decompilation. The closest attempt at decompilation, KismetKompiler[34], handles some UE4 Blueprints but does not support UE5 and acknowledges incomplete coverage.
It's like having a perfect .exe parser but no decompiler. You can map every byte in a .uasset file, but you can't recover the source. Tools like the Binary Reader MCP server can parse the binary structure, but they cannot decompile a Blueprint into human-readable code. That's a property of the format, not a gap waiting for a better parser.
8,000 characters vs. 14
The fastest way to see what the binary format costs is to compare the simplest possible operation across engines: printing "Hello" to the screen.
print("Hello")
Debug.Log("Hello");
Begin Object Class=/Script/BlueprintGraph .K2Node_CallFunction FunctionReference=( MemberParent=Class'" /Script/Engine .KismetSystemLibrary"', MemberName="PrintString") NodePosX=528 NodePosY=592 NodeGuid=77FD3D6E4C... CustomProperties Pin ( PinId=6C21D5174D..., PinName="execute", PinType.PinCategory="exec", PinType.PinSubCategory="", PinType.bIsReference=False, PinType.bIsConst=False, PinType.bIsWeakPointer=False, ... 20+ more flags ... ) ... 8 more pin definitions for: then, self, WorldContextObject, bPrintToScreen, bPrintToLog, TextColor, Duration ... End Object
That clipboard text is what you get when you copy a single PrintString node with Ctrl+C. The exact count varies with project path length. Most of those characters are pin metadata: PinType.PinSubCategory, PinType.bIsUObjectWrapper, PersistentGuid. Flags that tell you nothing about what the node does. And that's just the text representation. The actual .uasset on disk is compiled bytecode, which is even less readable.
You can paste this format back into the Blueprint editor. blueprintue.com has operated on it for years[5]. But you can't save it as a .uasset file. The file-level import path (T3D) was removed in UE4 v4.13[6]. A clipboard convenience, not a workflow.
Three engines, three levels of access
Godot: self-describing text
Godot was built text-first. A .tscn file tells you the node type[35], parent, properties, attached scripts, signal connections, animation keyframes, even PBR material parameters. No GUID database, no running editor. You just open the file.
[gd_scene load_steps=3 format=3 uid="uid://cecaux1sm7mo0"] [ext_resource type="Script" path="res://player.gd" id="1_abc"] [sub_resource type="CapsuleShape3D" id="CapsuleShape3D_abc"] radius = 0.5 height = 1.8 [node name="Player" type="CharacterBody3D"] script = ExtResource("1_abc") speed = 200.0 [node name="CollisionShape3D" type="CollisionShape3D" parent="."] shape = SubResource("CapsuleShape3D_abc") [connection signal="body_entered" from="Area3D" to="." method="_on_body_entered"]
GodotIQ builds a three-layer intelligence system on top of these files. A raw parser reads individual .tscn/.gd files. A scene resolver expands instances recursively and calculates world-space transforms. A project index scans all files and builds cross-reference maps for signals, dependencies, and assets. All from disk reads. No editor running. 35 tools, 1,100+ automated tests[7]. You can't build this for Unreal without the editor running. The files won't let you read them from disk.
The Godot community has a one-liner for creating a full AI context of an entire project:
shopt -s nullglob globstar
cat **/*.{godot,tscn,tres,gd,gdshader,json,csv} > all.txt
This works because the meaningful game logic and structure lives in text files. The number of MCP servers isn't the point; the architecture is. Godot MCP servers read text files from disk while Unreal MCP servers have to proxy through a live editor, and that difference is the gap.
Unity: YAML as API surface
Unity uses a custom subset of YAML with type tags: !u!1 is a GameObject, !u!4 is a Transform, !u!114 is a MonoBehaviour[9]. "Force Text" serialization has been the default for new projects since ~2020[8]. Any tool that can emit valid YAML with the correct type tags can create Unity content.
%YAML 1.1 %TAG !u! tag:unity3d.com,2011: --- !u!1 &1234567890123456 GameObject: m_Name: PlayerCharacter m_Component: - component: {fileID: 1234567890123457} --- !u!4 &1234567890123457 Transform: m_GameObject: {fileID: 1234567890123456} m_LocalPosition: {x: 0, y: 0, z: 0}
The guid references are real. Referencing project-specific scripts means cross-referencing .meta files. But built-in component GUIDs are stable across all Unity projects. Image, Button, TextMeshPro all have fixed GUIDs any tool can hardcode. The unity-prefabs-claude-code-skill[10] demonstrates this: Claude authors and modifies .prefab files directly, without Unity open, using documented stable GUIDs. Ask it to add a TMP_Dropdown and it generates all 12 required GameObjects with correct cross-references.
Unity's CEO announced on a February 2026 earnings call[11] a beta where developers can "prompt full casual games into existence with natural language only." Whether Unity delivers on that claim remains to be seen. But the architectural foundation that makes it plausible is the text format. The AI Assistant's /run mode creates GameObjects, wires components, generates scripts, and builds scene hierarchies from natural language. You can make that claim when your file format is text. Unity also ships its own MCP server as part of the AI package (com.unity.ai.assistant@2.0.0-pre.1, currently in preview[12]). They're betting on the ecosystem, not just their own tools.
Unreal: binary
C1 83 2A 9E 00 00 00 00 04 00 00 00 00 03 00 00 AE 0B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 97 3C 0B 67 00 00 00 00 05 00 00 00 05 00 00 00 2F 53 63 72 69 70 74 2F 45 6E 67 69 6E 65 2E 42 6C 75 65 70 72 69 6E 74 47 65 6E 65 72 61 74 65 64 43 6C 61 73 73 00 42 50 5F 50 6C 61 79 65 72
You can pick out /Script/Engine.BlueprintGeneratedClass and BP_Player buried in the bytes. That's about as far as you get.
| Content type | Unreal | Unity | Godot |
|---|---|---|---|
| C++ / C# / GDScript | Text | Text | Text |
| Scene / level layout | Binary (.umap) | YAML (.unity) | Text (.tscn) |
| Visual scripting / logic | Binary bytecode | C# scripts (text) | GDScript (text) |
| Materials / shaders | Binary (.uasset) | YAML (.mat) | Text (.tres, .gdshader) |
| UI layouts | Binary (.uasset) | YAML (prefabs) | Text (.tscn) |
| Animation state machines | Binary (.uasset) | YAML (.controller) | Text (.tscn) |
| AI can work offline | C++ only | Most assets | All assets |
The MCP gap
MCP servers let AI agents interact with game engines through standardized tool interfaces. Every major engine has them, and the architectures tell you everything.
Unreal MCP servers proxy through the live editor API. AI sends a command, MCP calls the Python scripting API, the editor executes and returns. The editor must be running, and the AI never reads the file directly. And here's the thing that shapes everything else: Epic's official BlueprintEditorLibrary Python API exposes no methods that can create or connect individual nodes.[13] The pin manipulation functions (MakeLinkTo, BreakLinkTo) aren't wrapped with UFUNCTION, so Python can't see them[14]. Every MCP server has had to write its own custom C++ plugin to expose these operations. Six independent teams have each written their own implementation to work around the same missing API.
Godot MCP servers just read text files from disk. GodotIQ parses .tscn files, resolves instanced scenes recursively, and builds project-wide dependency maps. No editor needed, because you can't do that with binary.
| Engine | Top MCP server | Stars | Requires live editor |
|---|---|---|---|
| Unity | CoplayDev/unity-mcp[15] | ~7,800 | Optional for many assets |
| Unreal | chongdashu/unreal-mcp[16] | ~1,700 | Always required |
| Godot | GodotIQ (35 tools) | — | Never required |
The most-starred Unreal MCP server carries an explicit warning: "EXPERIMENTAL, not recommended for production use." The best-documented one supports 23 Blueprint node types[32] out of the hundreds in UE5. The commercial one (Aura, $40-200/month[31], built on its proprietary Telos reasoning framework) had at least one user report in January 2026 that it refused to edit existing Blueprints despite having the setting enabled. Creating new simple Blueprints works. Modifying existing ones? That's the thing production teams actually need.
Epic's own AI can't do it either
Epic has an AI strategy, it's just not for UE5 Blueprint developers.
The Epic Developer Assistant launched in June 2025 for UEFN/Verse[17], expanded to UE5 C++ in September 2025[18], and was integrated into the UE5.7 editor in November 2025[19]. It generates C++ code and answers documentation questions, but it does not support Blueprint. The community has asked directly in an October 2025 forum thread[20], with no response from Epic.
This isn't an oversight. The Developer Assistant supports Verse (text) and C++ (text). Blueprint is a visual graph stored as binary bytecode. The same constraint that prevents community AI tools from working with Blueprints prevents Epic's own assistant from working with them. The binary format blocks Epic just as much as it blocks everyone else.
Epic's most visible AI tooling investment has gone to UEFN and Verse, not traditional Blueprint workflows. Persona Device (AI NPCs for UEFN)[17], Loci acquisition (3D asset tagging for Fab)[22], MetaHuman Animator, NNE (neural network inference at runtime), Learning Agents. All player-facing, marketplace-facing, or runtime tools. None address gameplay authoring, which is the core workflow where Blueprint developers spend their time.
Epic is investing in Verse as a modern, text-based scripting language. Based on Sweeney's comments on the Lex Fridman podcast in April 2025[21] (2-3 years to a preview), UE6 is likely 2027-2028. Whether Verse eventually supplements or replaces Blueprints is still an open question. In the meantime, UE5 Blueprint developers have no AI workflow tools from Epic. Unity and Godot developers have them now.
Twelve years of asking (and two abandoned text formats)
-
UE1 era (1998)
T3D (Unreal Text File) exists as a readable text format[36] for map objects.Begin Map/Begin Actor/Begin Brushsyntax. Human-readable. An AI could parse and generate it. -
2015
"Pain of Unreal Engine binary assets" thread opens on Epic forums[23]. Developers cite diffing, merging, and code review as pain points. Epic acknowledges the performance rationale. -
2016 (UE4 v4.13)
T3D import removed after hard crashes during the preview period. Epic chose to remove the text format rather than fix it. The format that existed since Unreal 1 is gone. -
2019
"Plaintext Asset Files" feature request posted[24]. An experimentalTextAssetFormatSupportsetting appears around UE4.21[25], allowing right-click "export to text asset" on Blueprints. -
UE 5.x
The experimentalTextAssetFormatSupportsetting persists through at least UE 5.2[26]. Its status in later versions is unconfirmed. No changelog entry, no announcement either way. -
Sept 2025
"Export the entire Blueprint as AI-processable text"[27] feature request, again with no official Epic response. -
February 2026
Unity's CEO announces on an earnings call that developers can "prompt full casual games into existence with natural language." You can make that claim when your file format allows it.
Epic had a text format. It crashed, and they removed it rather than fixing it. They had an experimental text export. It persisted through at least UE 5.2, then went quiet — no changelog entry, no announcement, no evolution. The pattern is clear: text formats get abandoned rather than invested in.
The version control prequel
The reasons developers complained about binary files in 2015 are the same reasons AI agents can't work with them in 2026: you can't diff them, you can't merge them, and you can't review them. Version control tools and AI agents both need text.
| VCS problem | AI problem | Root cause |
|---|---|---|
| Can't diff binary files | Can't read binary files | Not text |
| Can't merge changes | Can't modify content | Not text |
| Can't review in PR | Can't reason about content | Not text |
| Must lock files (one editor at a time) | Must proxy through live editor | Can't access directly |
| Lost work on same-file edits | Can't improve existing content | No merge path |
The industry's workaround has been Perforce: centralized VCS with file locking. Perforce's own 2024 survey reports that over half of game studios use Helix Core[28], concentrated at mid-to-large companies. Between licensing ($39/user/month), infrastructure, and dedicated admin time (Perforce's own blog estimates "at least $100,000 per year" for in-house Helix Core talent), total cost of ownership can reach $50,000-$150,000/year for a 50-100 person studio. According to a survey by Diversion (a VCS provider), 64% of game development organizations familiar with the subject[29] maintain dedicated teams just to manage VCS infrastructure.
Perforce doesn't solve the problem, it just accepts it. File locking prevents parallel work on the same asset. When two people edit the same Blueprint, someone loses work. The "merge tool" is a three-panel manual copy-paste interface with no automation and no text diff.
And Blueprint code review? Kokku Games published a tutorial[30] titled "Stop guessing what changed in your Blueprints." The best available workflow uses UE5's built-in Diff Tool to compare Blueprints inside the editor. There's no text diff, no PR comments on specific changes, and no audit trail outside the editor.
Unity's Force Text decision, made the default around 2020, now enables Git workflows, text-based merge, PR review, and AI access. Architectural decisions compound. Godot's text-first philosophy means standard Git works out of the box.
If version control was the dress rehearsal, AI is the main event.
What we built at Sackbird
Sackbird Studios is 8 people building a multiplayer game on UE 5.6, and we ran directly into this wall.
We built a three-layer system: a TypeScript MCP server talks over WebSocket to a native C++ editor plugin (McpAutomationBridge) that exposes 36 MCP tools with 200+ automation actions across every major UE subsystem. Built on top of ChiR24/Unreal_mcp (open source, MIT)[33], extended through 11 development phases and 4,400+ lines of changes for production use.
The trick is using Unreal's own FProperty reflection system to marshal any UObject property to and from JSON. A 1,356-line reflection utility translates between what Claude can work with (structured JSON) and what Unreal stores (binary properties). The AI never touches .uasset files directly. It sends commands through MCP, and the C++ plugin translates them into native UE API calls.
This isn't a "spawn a cube" demo. The plugin manipulates Blueprint graphs (create K2 nodes, wire pins, compile), material graphs, Niagara particle systems, Behavior Trees, Animation Blueprints, UMG widgets, Sound Cues, State Trees, and Gameplay Ability System assets. 56 C++ handler files organized by domain. _GASHandlers.cpp, _NiagaraGraphHandlers.cpp, _WidgetAuthoringHandlers.cpp. Every creation operation has a corresponding read-back so Claude can verify its own work.
It works. We use it daily to build actual game features. NPC AI, combat systems, UI, multiplayer sessions. This is an internal tool, not a product — we built it because we had to, and we wrote 70 C++ source files and a TypeScript server to give Claude access to Unreal's binary world, including Blueprint graphs that are otherwise locked on disk.
What this means
We're staying on Unreal. It's fully featured, well documented, and widely used. Engine selection is still dominated by ecosystem maturity and team expertise. AI workflow compatibility is not yet a deciding factor.
But the gap is real and it's widening.
At least nine community tools have tried to bridge the Blueprint binary gap. None succeed completely. The official Python API still doesn't expose the operations they need. Six independent teams have each written their own C++ wrapper around the same unexposed editor functions.
That fragmentation is the proof: at least nine tools, zero complete solutions, and six independent reimplementations of the same missing API. If the problem were solvable without a native text format, one tool would dominate, and a native text format would make all of them obsolete overnight.
This isn't just a game engine problem. Most DCC file formats and the interchange formats that connect them made the same binary design choice decades ago. I spent years as a technical artist fighting binary formats across the entire art pipeline before AI made it everyone else's problem too. More on that another time 😊
If you're shipping on Unreal today: invest in the translation layer. Build or adopt MCP tooling that bridges the gap. Budget for it as infrastructure, not as a nice-to-have. And keep an eye on Verse. If a text-based scripting path matures in a future engine version, the studios that already have AI workflow infrastructure will be the ones ready for it.