The .uasset Problem, Revisited: Epic Bet the Engine on Text

A few months ago I wrote that Unreal's binary .uasset format was the wall between AI agents and the engine, and that the fix was text. Then Epic stood up at Unreal Fest, its State of Unreal keynote, and announced that the next engine moves its gameplay model to text. I'd like to say I planned the timing. To be clear about the headline up front: "bet the engine on text" is the direction Epic committed to on a multi-year roadmap, not a thing you can download today.

The first article^[1] argued a narrow, concrete thing: Blueprints compile to binary Kismet bytecode stored in .uasset, AI agents are text-native, and that mismatch is why every Unreal AI tool has to proxy through a live editor while Godot and Unity tools just read files off disk. I guessed UE6 was probably 2027-2028, based on Sweeney's "two to three years to a preview" on the Lex Fridman podcast^[2], and I left "does Verse replace Blueprints?" as an open question.

At State of Unreal 2026 on June 17, Epic answered both. The gameplay programming model moves to Verse, which is text. Blueprints get deprecated. Early Access is targeted for the end of 2027.^[3] I'd guessed 2027-2028; Epic said "end of 2027," which is close enough that I'll take it.

This isn't a victory lap. The honest version is more interesting than the headline anyway. Epic did not blow Blueprints up, and the part that vindicates me is a bet years out. The thing I cared about most, where an AI and a human edit the same logic, still isn't solved. So this is a follow-up on what Epic actually said, what's overblown in the reaction to it, and the gap that's left over, which is the gap I ended up building something to fill.

What Epic actually announced (and what it didn't)

First, the correction I had to make to my own draft: this is UE6, not UE 5.8. UE 5.8 shipped on the same day, June 17, 2026, and it is the last planned major release of Unreal Engine 5.^[4][3] Its release notes contain no Blueprint deprecation, no Verse-in-mainline, nothing of the sort.^[5] The Blueprint plan lives in a separate blog post, "The Road to Unreal Engine 6," by Marcus Wassmer, who leads the development team at Epic.^[3] Conflating the 5.8 release with the UE6 roadmap is the single easiest way to get this story wrong, and most of the coverage I saw did exactly that.

UE6 is the merger of two streams: "Over the next two years, we'll be unifying the two major streams of Unreal Engine development (UE5 and Unreal Editor for Fortnite) into a single product: Unreal Engine 6."^[3] Sweeney's shorthand, on stage: "it's UE5 plus UEFN equals UE6 plus some more cool stuff on the way."^[6] A few changes from that roadmap matter if you work in text. The table below is the short version; the words after it are the part you actually have to read carefully.

Here is the deprecation language verbatim, because the exact words are the whole story: "Our philosophy through this transition is to bring existing projects along, not to force a hard break… To allow for this, Actors and Blueprints will be in early versions of UE6. Eventually, these will be deprecated when the new framework is sufficiently mature, and you'll have conversion tools to move projects from one framework to the other."^[3] Epic's official account put it the same way: "Blueprints will be supported in Early Access and the initial UE6 releases, but deprecated in the future… Deprecation will mean a feature continues to be available without improvements, then is eventually removed."^[7][3]

On timing: "We're targeting a Unreal Engine 6 Early Access release at the end of 2027, with the full release of UE6 coming 12-18 months later."^[3] That lands the mainline transition somewhere around 2028-2029, and "targeting" is doing real work in that sentence; Epic dates slip.

"Deprecated" is not "deleted"

The fear is real, and I don't want to be glib about it. The most-cited thread I found, "They want to remove Blueprint in UE6,"^[9] has people writing things like "I've spent the last 10 years learning blueprints, and now they're throwing it away" and "a decade of tutorials useless." A "Save Blueprints" petition went up the same day.^[10] If you have built a career on visual scripting, "deprecated" is not a reassuring word, and you can see where the AI-conspiracy read comes from (one developer: "LLMs can't generate Blueprints, so that's why they're getting rid of the best feature"^[8]).

But the panic outran its own size. That petition had about ninety signatures when I checked, not ninety thousand.^[10] The fear is loud; it isn't large yet. And the rebuttal doesn't require me to spin anything, because it's Epic's own words doing the work. Blueprints are supported through Early Access and the initial UE6 releases. Deprecation comes only "when the new framework is sufficiently mature." There are conversion tools. The full release is 12-18 months past an Early Access that is itself more than a year out. Nobody's existing project breaks this year, or next, or the year after.

One concession stays standing, and pretending otherwise would just be spin: Epic announced no visual authoring successor. The replacement is a text language plus a component framework. Until some visual layer exists, there is a real accessibility gap for the artists and beginners for whom "it's just text" is not a feature. That gap is the thing the rest of this article is about.

Epic chose text

The core argument of the first article was that the binary format was the problem and the fix was text. On the go-forward path, Epic chose text.

Verse source is plain-text .verse files on disk, edited in VS Code through Epic's official extension, with modules organized as folders of .verse files.^[11] For gameplay logic, that is the exact thing I was asking for: code an agent can read off disk without the editor running, diff in a pull request, and merge like any other source file. It's where Godot already is with .gd and Unity with .cs. The binary Blueprint bytecode that no general-purpose decompiler can recover is, on that path, simply gone.

The interchange-format thread is the one I didn't expect Epic to pick up. At the end of the first article I tucked an editor's note about how this isn't only a game-engine problem, that DCC and interchange formats made the same binary choice decades ago, and that I'd say more about it another time. The roadmap got there first: "Where existing standards such as glTF or USD are capable of fulfilling UE6's needs, we will make them first-class formats within the engine. Where a standard doesn't yet exist… we will open up Unreal Engine's own systems as open specifications with Verse APIs, defined asset conventions, and documentation."^[3]

That's the interchange thread I teased, answered by the engine vendor. First-class open formats plus open specs is a different posture than a proprietary binary container that needs the editor to crack it. Nobody's trying to make .uasset diffable. The move is to let the content live in formats that were text or open to begin with, and stop fighting the container.

A short Verse primer

If Verse is the language the next engine runs on, it's worth thirty seconds. It's a functional-logic language conceived by Sweeney and built with Simon Peyton Jones (of Haskell fame) and Lennart Augustsson.^[20] Its formal core, "The Verse Calculus," was peer-reviewed and published at ICFP 2023, as "deterministic functional logic programming."^[12]

Epic's own framing in the roadmap: Verse "draws ideas from functional, logic, and imperative languages, and should feel immediately familiar to anyone who has worked with languages like Python or C#… starting with its unique software transactional memory model." All functions "run as part of atomic transactions, which can be rolled back and resimulated."^[3] The "transactionalizes C++" line in the roadmap means the same thing: Verse and C++ stay inside the same transactions through AutoRTFM, a custom LLVM compiler pass Epic built to give C++ Verse's transactional-memory semantics.^[19] You don't need to care about the theory to use it; you do need to know it's a real language with real semantics, not a Blueprint reskin.

Here's the canonical hello-world, straight from Epic's UEFN tutorial:

using { /Fortnite.com/Devices }
using { /Verse.org/Simulation }
using { /UnrealEngine.com/Temporary/Diagnostics }

hello_world_device := class(creative_device):

    OnBegin<override>()<suspends>:void =
        Print("Hello, world!")
        Print("2 + 2 = {2 + 2}")

The flavor you can read off that: := binds a definition, <suspends> is an async specifier, { } does string interpolation. Functions look about how you'd hope. From the community Verse book (not an Epic source, so label it as such^[13]):

ProcessData(Name:string, Age:int, Score:float):string =
    "{Name} is {Age} years old with a score of {Score}"

Two things about where it runs. Today, Verse is UEFN and Fortnite only; it is not in mainline UE5, including 5.8. It comes to mainline with UE6.^[14][3] And as of the roadmap, "the Verse language implementation has moved out to be visible" on GitHub, "though it's not intended for general adoption."^[3] The language is real and shipping in one place. The engine that makes it the default is still on the runway.

There's a wrinkle worth naming. My own hunch about the answer to the Blueprint/C++ divide isn't Verse. It's AngelScript. Hazelight's open-source UnrealEngine-Angelscript, the text-scripting tech they shipped It Takes Two and Split Fiction on (with other studios' games behind it too), gives you hot-reloadable, plain-text gameplay code today, on shipping UE5.^[18] So a plain-text scripting layer for Unreal already shipped real games, from the community, well before this roadmap existed. Epic is building its own from scratch anyway.

The irony: Epic's shipping AI still runs through the editor

This is the part that keeps me from declaring victory. Everything above is the future bet. The thing Epic actually shipped on June 17 is the architecture I spent an entire article criticizing.

UE 5.8 introduced an experimental Model Context Protocol plugin. From the State of Unreal recap: "Unreal Engine 5.8 introduces a new Experimental Model Context Protocol (MCP) plugin which enables developers to connect models like Claude directly to UE projects… these models can become active collaborators that understand and operate within specific Unreal Engine workflows."^[15] That sounds great until you read how it works, because the implementation is editor-driven: a server running inside the editor process. As described on stage, "[Claude] Code is talking to Unreal through the MCP server, reading the scene, and taking actions directly inside the engine."^[6] The editor has to be running. The AI never touches a file on disk.

That is the proxy model. It has the same shape as every community Unreal MCP server, and it's the bridge we had to build at Sackbird. The demo even had Claude author Blueprint logic, a proximity trigger driving a material change, a Niagara effect, and a HUD update, all through the live editor.^[6] Which means Epic's flagship AI demo is an agent driving Blueprints through the editor: precisely the workaround I documented, now blessed and shipped by Epic itself.

That's not really a contradiction. It's what you'd expect. What ships today has to run through the editor because today's content is binary and there is no other way in. The vindication, text on disk an agent can read directly, is the part that's still a roadmap. Epic is living in the same gap I am. They just have a plan to climb out of it.

Theorizing "Visual Verse"

Everything past here is speculation and a design pitch, not reporting. Labeling it loudly so nobody mistakes it for something Epic said.

The fact first: Epic announced no visual scripting successor to Blueprints. The roadmap blog doesn't mention one. The State of Unreal recap doesn't. The full show transcript doesn't; "visual scripting" appears zero times on stage. The announced replacement is Verse (text) plus Scene Graph (Verse-scriptable components), full stop. The only real signal of anything visual is that Epic surveyed UEFN creators about a future Verse visual front-end, node-graph versus Scratch-style blocks.^[16] Not announced, not dated, not committed. The term "Visual Verse" itself is community coinage, not an Epic product name, though Epic did file an intent-to-use trademark on it back in 2021 and has quietly kept it alive, for whatever that's worth.

So when I talk about "Visual Verse" below, I am describing a thing I want to exist, not a thing Epic has promised. With that caveat as loud as I can make it, here is my argument.

The original sin of Blueprints was never that they were visual. It was that the visual graph compiled to opaque binary bytecode, so the only readable representation lived in the editor's head. Visual UX, binary substrate. The right design keeps the visual editor but changes what lands on disk: a node graph that serializes to text Verse, so the artifact in version control is the same plain-text source an agent reads. One file, authored as nodes by the person who likes nodes, read as text by the agent and the diff that can't see nodes at all.

That's the synthesis of everything the first article argued: you don't have to choose between a visual front-end and an AI-readable backend. Blueprints forced the choice because the only place the graph existed was binary bytecode. Make the on-disk format text and the choice disappears, whichever side you treat as canonical while editing. The honest open design questions are real ones, though: does the graph generate the text, or the text the graph, and what does that cost you? Where does node layout live, in the text or a sidecar? And is the generated Verse something an LLM can author correctly, or only read? Those are the questions that decide whether the idea is good or just pretty.

So I tried building one

The UE6 news nagged at me, so for the fun of it I spent a few evenings building a small version of the thing I'd just described, to see whether it actually holds together. I'm calling it the Verse Nodegraph Editor, and it's what it sounds like: a Blueprint-style node graph you edit visually (drop nodes, wire typed pins, fan an output into several inputs) that writes plain-text Verse to disk instead of binary bytecode, and reads it back. Nothing ambitious; a side project the announcement talked me into. It's a web app built on Vite, React, and React Flow for the canvas. It started life text-canonical, with the .verse file as the source and the graph a view, and I rebuilt it the other way once it was clear that's not how you actually want to edit. The graph is now the canonical editing model, the way Blueprints are; the Verse text on the right is generated from the graph. What never changed is the part the thesis depends on: the artifact you'd commit is still plain-text Verse. The graph emits to it, and an Import button parses Verse back into a graph. Visual for the human, text on disk for the agent and the diff. No binary anywhere in the loop. You can try it at verseeditor.adamhafez.co.

The reason I flipped it is the reason Blueprints are a graph and not a text box. Connecting two pins, fanning one output into three inputs, dragging a wire into empty space to spawn the node it should connect to: those are graph gestures, and forcing every one of them to route through a text round-trip on each keystroke was the tail wagging the dog. So the editor is a real Blueprint-style editor now: typed pins, fan-out from one output into several inputs, and drag-off-a-pin to spawn a connected node, the gestures that only make sense as a graph. There's a searchable palette wired to the real Verse API: it searches an index built from Epic's published API reference, 37,583 members across roughly 3,700 classes, served behind a gated, rate-limited endpoint so the whole corpus never ships down to the browser, and a search hit drops a typed method-call node with its receiver, parameter pins, and return type already filled in. Here is the sample it loads by default, Epic's UEFN hello-world written as a plain function, and the Verse it generates from that starting graph:

HelloWorld():void =
    Greeting := "Hello, world!"
    Print(Greeting)
    Print("2 + 2 = {2 + 2}")

The graph that produces that text looks the way a Blueprint developer would expect: an entry node, a node per statement, white exec pins threading control flow, and colored typed data pins for values, so a string reads magenta and an integer teal. Variables are pure GET nodes wired into the pins that consume them. Layout is auto-generated with elkjs until you move something, after which your positions stick. The generator walks the exec chain from each entry node, resolves each data input from whatever's wired into it (or the pin's inline default), and prints Verse. The Import direction is the inverse: parse text to an AST, build the graph. That parser/emitter is the one piece I can pin down with a hard test, so I do, the boring way:

const ast  = parseProgram(src)
const back = emitProgram(ast)
expect(back).toBe(src)        // byte-identical
expect(emitProgram(parseProgram(back))).toBe(back) // idempotent

Each sample is checked twice: once that emit-after-parse reproduces the source exactly, and once that a second round-trip is stable. There are 167 tests passing across seven suites now. Most of them are the text-to-AST round-trip (interpolation, operator precedence, idempotence); the rest cover text-to-graph-to-text, the bundled examples, a handful of real UEFN scripts pulled from Epic's public corpus, plus type inference and static validation. What that proves is narrow and worth stating exactly: the text emitter and the text parser agree, so the Verse the editor writes is Verse the editor can read back. It is not a proof that a graph survives a trip through text untouched, because the graph is canonical and the text is generated, so that round-trip isn't the property on offer. The test guards the seam between the two representations, which is the seam that has to hold for the on-disk file to mean what the graph means.

I'll be straight about the scope, because a proof-of-concept that hides its limits isn't worth much. The parser and emitter behind Import and the generated text are hand-rolled, and they cover a deliberate subset of Verse, though a bigger one than I expected to end up with: free functions, nested and parametric functions, classes and structs and interfaces with members, methods, and inheritance, enums, the richer literals (arrays, maps, tuples, options), structured control flow (if, for, loop, case, both as statements and as expressions), the concurrency primitives and defer, with effect and access specifiers and attributes captured raw. Anything it can't parse becomes an opaque node that round-trips verbatim rather than an error. To find out how much of real Verse that actually covers, I ran it against published UEFN games with tree-sitter-verse, the community grammar, as a parse oracle: anywhere tree-sitter parses a script and mine doesn't is a gap. That caught and fixed a pile of them, including the awkward ones I'd half written off: brace-delimited bodies instead of indentation, and messy or over-indented blocks, both of which now parse and get normalized back to clean indentation on the way out. What's left is a genuinely niche tail: structured string interpolation, casts, and char literals, which for now degrade to verbatim text rather than structured nodes. Those are to-dos, not finished things, all tracked in a coverage doc.

It's a weekend proof-of-concept, not a product, and definitely not a prediction of what Epic ships. I put it together with Claude over those evenings, which felt apt for a thesis about AI and text: an agent helping write the tool whose whole point is that agents can read what it writes. It shows one thing: the claim from the section above isn't crazy. You can keep the visual UX and lose the binary lock-in, because the lock-in was never the visual part. It was the bytecode the visual part compiled down to. Edit the graph, write text to disk, and a file an AI and a diff can read falls out the other side. The editor stays.

What this means

The direction is now set, and it's the one I argued for: text plus open formats. Verse for logic, glTF and USD for content, open specs where no standard exists, and an open MCP foundation on top. At the same show Epic also open-sourced Lore, a version control system aimed at the binary-asset diff-and-merge pain I'd flagged as the dress rehearsal for the AI problem.^[15] The binary era at Unreal is ending, slowly, on a multi-year deprecation timeline, with conversion tools and no hard break, but it is ending all the same.

Three caveats I'd want you to keep, none of which I'm going to soften:

• Verse is logic only. Meshes, materials, and levels stay binary .uasset unless the glTF/USD first-class commitment actually follows through in shipping releases. Verse narrows the problem; it doesn't close it by itself.
• This is UE6, and UE6 is 2027 at the earliest. Early Access is targeted for end of 2027, mainline 12-18 months after that, and those are aims. What ships today is still editor-bound.
• Text-readable is not the same as AI-writes-it-correctly. Verse is a low-resource language; the research on LLM code generation for low-resource languages shows large gaps versus Python.^[17] Epic grounds its assistant in documentation precisely because raw Verse generation is shaky. An agent reading .verse off disk is solved; an agent writing correct Verse is not.

None of that undoes the through-line. I argued the binary format was the wall and text was the way through. Epic is rebuilding the engine around text, and from where I sit that reads as about the most expensive way a company can agree with you.