Why I Think the Era of Unity/Unreal Is Over

TL;DR — the era is over, not the engines

Unity and Unreal will survive. They will remain excellent choices for AAA visuals, consoles, giant worlds, and teams built around mature native pipelines. What is ending is their status as the automatic starting point for every game. LLM-assisted development rewards open text, instant execution, machine-visible state, scriptable testing, and one-click distribution. A web game gives the agent the source, runtime, debugger, test runner, profiler, and deployment target in one environment. Unity and Unreal put a heavyweight editor, asset database, import pipeline, and build step between the agent and the truth. MCP makes that editor remotely controllable; it does not remove the tax. For rapid prototyping, mobile F2P, casual and mid-core games, and the next generation of custom game tools, my bet for at least the next three years is the web.

I am not saying Unity and Unreal will disappear

“The era is over” is deliberately sharp. It does not mean Epic and Unity close tomorrow, or that every studio should migrate a production game.

Unreal remains extraordinary when the product depends on its high-end renderer, cinematic pipeline, Niagara, enormous-world tooling, console support, or a large specialist team. Unity still has a huge asset ecosystem, mature multiplatform support, and years of solved production knowledge. If your studio already has ten years of tools and trained people inside either engine, that investment is real.

But an era does not end when a tool vanishes. It ends when the tool stops being the default answer.

For years, the first question was “Unity or Unreal?” I think the new first question is “Why do we need either one?” If the game can be proven, shipped, and operated on the web, the burden of proof has moved to the engine.

LLMs changed which bottleneck matters

The usual version of this argument says LLMs were trained on much more JavaScript than C# or C++. I believe the web corpus matters, but no major model vendor publishes a trustworthy language-by-language breakdown of its complete training mix. So I will not pretend that claim is measurable.

What we can measure is the ecosystem around the models. In GitHub's 2025 Octoverse, TypeScript became the most-used language on GitHub, with about 2.6 million contributors. New repositories included roughly 9.3 million JavaScript and 5.39 million TypeScript projects, compared with 1.7 million C++ and 1.48 million C# projects. GitHub explicitly connected TypeScript's rise with AI-assisted development and the guardrails types give generated code. C# and C++ are still well supported and still growing. The point is not that an LLM cannot write them.

Generating code is no longer the bottleneck. Closing the feedback loop is.

An agent working on a web game can:

edit TypeScript, JSON, shaders, HTML, and assets in ordinary files;
run the type checker and unit tests directly;
launch the exact game in seconds;
read console errors and network failures;
inspect screenshots, DOM state, canvas output, memory, and performance traces;
click and play the game through browser automation;
repeat the same test across Chromium, WebKit, and Firefox;
open the same build on a real phone and remotely debug it.

Chrome DevTools already exposes the console, network, memory, rendering, and performance stack, and its agent tooling lets coding agents use those same surfaces. Playwright runs headed or headless tests across the three major browser engines and records traces with screenshots, logs, network data, and DOM snapshots.

That is not an AI integration bolted onto a game tool. It is an environment that was already scriptable from top to bottom.

The editor is the tax

Unity and Unreal were designed around a human operating a giant stateful desktop application. Code is only one part of the product. The rest lives in scenes, prefabs, components, Blueprints, materials, animation graphs, import settings, asset references, and editor-only state.

Unity's gameplay language is C# today— UnityScript was deprecated years ago—so “Unity also has JavaScript” is no longer an escape hatch. Unity scenes and prefabs can be serialized as YAML, which helps source control, but meaningful work still passes through compilation, asset import, code reload, scene reload, and Play mode. Unity's own code-reload documentation presents the trade: you can disable reload behavior to iterate faster, but then you take responsibility for state that the editor normally resets.

Unreal is even more editor-bound. Its own asset documentation says to always manage .uasset files through Unreal Editor. An LLM can write excellent C++, but much of the game's semantic truth sits behind editor APIs and binary assets. Blueprints can be exposed or copied in textual forms, but that translation is extra context, extra tooling, and extra failure surface.

Every prototype iteration pays some version of this loop:

Change code or request an editor mutation.
Wait for compilation, import, reload, or tool execution.
Enter the correct scene or Play state.
Discover that the editor and the source disagree.
Collect screenshots, logs, selections, and asset context.
Explain that state back to the model.
Try again.

The browser loop is usually: save, hot update, inspect, correct. Vite's HMR is designed to update the running module without a full reload or lost application state. The exact speed varies by project, but the architecture is direct.

Boundary	Unity / Unreal loop	Web-native loop
Source of truth	Code plus editor-owned assets and state	Text files, web assets, and the running page
Agent access	Editor bridge, plugin, reflection, or generated scripts	Files, process, browser, and DevTools directly
Feedback	Compile/import/reload, then Play or package	HMR/reload, then inspect immediately
Verification	Engine tests plus editor/platform automation	Type checks, unit tests, browser playtests, traces, screenshots
First distribution	Produce and upload a build	Send a URL
Tooling model	One monolith plus plugins	Focused tools built around the game's data

Unity and Unreal have good profilers and test frameworks. That is not the criticism. The criticism is the number of boundaries an agent must cross before it can know whether its change actually worked.

MCP is an admission, not a cure

Unity and Epic clearly see the problem. Unity's current AI beta includes an in-editor Assistant, an AI Gateway, and an official MCP server. Unreal 5.8 now ships an experimental Unreal MCP plugin so external agents can spawn actors, configure lighting, create material instances, inspect widgets, and run tests.

This will improve. It will also produce impressive demos. In a recent Unity community discussion, one developer reported automating a huge animator setup; another found the in-editor UI suboptimal and preferred using MCP from an IDE. The bridge is useful.

It is also revealing.

Epic labels Unreal MCP experimental, says features are incomplete or missing, warns that APIs and data formats may change, and serializes tool invocations onto the game thread. Its own workflow guide says explicit human-selected context is faster, more reliable, and cheaper than autonomous discovery. Unity's pitch is likewise that the agent becomes project-aware inside the Editor.

MCP does not remove the editor. It turns the editor into an API.

That is a major upgrade to the old workflow, but it is still a remote control for an architecture built around human interaction. The model must discover the right tool, provide the right structured parameters, wait for the editor to execute it, survive reloads and imports, then inspect the result through another tool. On the web, the agent already owns the files, process, runtime, and inspection surface.

Unity and Unreal will eventually make all of this “kinda work.” My argument is that kinda is not enough in a race decided by thousands of tiny iterations. By the time the wrappers feel native, teams building directly on the agent's native platform will have moved again.

On the web, the prototype is already the product

The strongest web advantage is not that a prototype appears quickly. It is that success does not trigger a rewrite.

A browser prototype is already:

a build a tester can open from a message;
a free public version and acquisition funnel;
a continuously deployable product;
the same JavaScript, assets, networking, and game logic that can run inside a mobile shell.

Capacitor can be added to an existing modern JavaScript project and packages it as a normal iOS or Android app with access to native plugins. Its honest promise is the right one: if it works in the browser, it probably works in the mobile app. Capawesome Live Update can deliver binary-compatible HTML, CSS, JavaScript, and asset updates without a new native binary.

This does not abolish signing, store metadata, review, IAP, push notifications, device quirks, or real-phone performance work. Native plugin changes still require a new store build. But it collapses the biggest waste: rebuilding the game in another client stack after the prototype wins.

The distance becomes working web game → native shell and plugins → store release, not disposable prototype → production rewrite → platform ports → store release.

A small concrete example appeared in the Capacitor community in 2025: Lazy Blocks runs as a free static web game and was packaged with Capacitor for the iOS App Store with native IAP. That is anecdotal, not a market study, but it demonstrates the shape of the pipeline.

The free web version is not a footnote

Web-first gives every game a playable link by default. For free-to-play, that link can be a demo, an instant tutorial, a viral invitation, a reactivation campaign, a low-friction acquisition channel, or a storefront you control.

It also creates commercial optionality beyond native checkout. A player who arrives independently on your website can buy through your web commerce flow without first entering an app store. Connecting the native app to outside purchases is policy- and region-specific: Apple's current App Review Guidelines allow external purchase calls to action in the US storefront while other storefronts use specific entitlements, and Google operates regional external-offer and alternative-billing programs that may still carry reporting requirements and fees.

So the honest benefit is not “web magically avoids every Apple and Google fee.” It is this:

A web build gives an F2P game direct acquisition, instant play, and a commercial channel that is not born inside a store.

Unity and Unreal treat the web as one export target among many. Web-first development treats it as the origin, and mobile stores as additional packaging.

The future is not another giant editor

The old model was one editor that could do everything: scenes, animation, VFX, audio, materials, UI, profiling, builds, packages, and plugins.

The AI-native model is a constellation of focused tools:

a map editor made for this game's map format;
an economy simulator made for this game's economy;
a dialogue and quest editor made for this game's narrative model;
a balance dashboard connected to live data;
a UI editor that exports the exact runtime hierarchy;
a VFX editor that speaks the game's renderer directly;
small inspectors and conversion tools generated when the team needs them.

Some will be commercial. Many will be home-made. An LLM can build a narrow React or canvas editor around a clean JSON schema faster than a team can force a generic engine inspector to understand the same domain. Because it is a web app, the tool is instantly shareable, scriptable, testable, and easy for the next agent to inspect.

This future is already visible:

PlayCanvas is a full browser-based 3D editor where the editor and published app use the same engine, with live editing and an API for custom tools.
A developer recently showed a custom browser town-map editor whose editor and game share the same Three.js renderer and scene graph.
Rive already provides the same animation workflow in its browser and desktop editors, including bones, meshes, weighting, and IK. It is not a drop-in Spine replacement for every pipeline, but it proves serious animation authoring belongs in the browser. Emerging tools such as Stretchy Studio even export Spine JSON.
NixieFX exists because web games need focused, engine-depth VFX authoring without adopting a giant engine. Effects remain plain JSON and run in both PixiJS and Three.js.
ElevenLabs generates loopable sound effects through an API, Suno turns musical direction into tracks, and Meshy turns text or images into textured 3D assets through a web workspace and API.

These tools do not eliminate animators, sound designers, composers, technical artists, or taste. Generated assets still need direction, licensing review, cleanup, optimization, and consistency. What changes is the cost of getting enough coherent material into a prototype to discover whether the game deserves a production team.

The performance objection will make the web stronger

The best criticism of this thesis is performance. A browser is not a console runtime. Memory limits, GPU selection, shader compilation, mobile thermals, browser variance, and driver bugs are real. Three.js is a renderer, not a complete engine. Teams must assemble physics, navigation, animation, streaming, asset conditioning, and production conventions themselves.

Good. Constraint creates discipline.

Web developers cannot assume an enormous native budget will hide waste. They are forced to care about draw calls, texture formats, overdraw, pooling, garbage collection, load size, device pixel ratio, and fallback paths. That optimization wave has been too quiet in parts of the WebGL ecosystem; AI-generated games and larger browser worlds will force it forward.

The platform ceiling is moving too. WebGL 2 is mature across modern browsers. Chrome brought WebGPU to desktop and supported Android hardware, and Safari 26 shipped WebGPU in 2025. WebAssembly provides a portable path for performance-sensitive code. None of this makes a badly designed game fast, but it means the browser graphics stack is being actively expanded, not abandoned.

The community is already exposing both sides. In July 2026, a developer who said he had used Unity for over a decade described switching to Three.js because of slow compile, shader, build, and editor time, then reported smooth results on an iPhone 11. Another open-world Three.js/WebGPU prototype became reachable because AI lowered the entry barrier—but community testing revealed severe Mac performance problems and forced an optimization pass.

That is exactly the future I expect: more ambitious web games, faster creation, brutal public feedback, and a renewed performance culture.

Where Unity and Unreal still win

Use Unreal when your game is fundamentally a high-end native rendering problem; when Nanite, Lumen, Niagara, cinematic tooling, consoles, or a proven AAA pipeline are the product advantage.

Use Unity when its mature ecosystem, platform reach, asset-store leverage, or your team's existing pipeline saves more time than the editor costs.

Do not choose the web blindly for:

a console-first title;
a photorealistic AAA game with huge worlds;
a project whose core feature depends on engine-specific rendering or simulation;
a team already operating efficiently inside a mature Unity or Unreal toolchain;
a product that cannot afford browser and device variability.

And do not confuse AI speed with product quality. A sharp Three.js community postmortem made the right point: AI can produce the code, but without precise art direction it fills the gaps with average-looking work. Fast implementation does not invent taste, game feel, or a reason to play.

This article attacks the old default, not every valid use case.

My three-year bet

For at least the next three years—after that, I will happily reassess—the center of rapid game development will move toward the web:

LLMs writing TypeScript, shaders, tests, tools, and content pipelines;
agents running and inspecting the game in real browsers;
PixiJS, Three.js, WebGL, WebGPU, and Wasm carrying more ambitious games;
Capacitor and Capawesome turning the same build into mobile products;
focused browser editors replacing large pieces of the monolithic engine workflow;
AI services producing prototype audio, music, animation, art, and 3D assets;
successful games keeping their free web version as a distribution and commercial advantage.

Unity and Unreal will add better assistants, more MCP tools, and smarter wrappers. They will “kinda” work, then work much better. But they are adapting an editor-first architecture to an agent-first world.

The web starts where the world is going.

The teams that board this train now will accumulate libraries, skills, performance knowledge, custom editors, release pipelines, and agent workflows while everyone else is still teaching an LLM how to click yesterday's editor. Late adopters will not merely be late to a technology. They will be years behind in iteration culture.

The next dominant game engine is not an engine. It is the web, an agent, and the exact tools the game needs.

Frequently asked questions

Are Unity and Unreal literally dead?

No. They remain powerful and will keep shipping major games. The claim is that their era as the automatic starting point—especially for prototypes, F2P mobile, casual, mid-core, and web-distributed games—is ending.

Is JavaScript simply better than C# or C++ for LLMs?

That is too simplistic. The exact training mix is not public, and modern coding models handle all three languages. The web advantage is the complete verification loop: ordinary files, fast execution, browser inspection, automation, cross-browser tests, and direct distribution.

Can a web game really ship to the App Store and Google Play?

Yes. Capacitor packages an existing web app as a normal native project and exposes native APIs through plugins. You still do signing, store review, payments, native integration, and real-device QA.

Will MCP fix Unity and Unreal's AI workflow?

It will improve it substantially. It will not change the fact that the agent is driving a stateful editor through an adapter. For the next three years, I expect direct browser-native loops to remain faster and easier to verify.

Can the web replace Unreal for AAA and consoles?

Not generally today. That is not the prediction. The prediction is that the web becomes the dominant discovery and rapid-production platform for a large, commercially important class of games—and that more successful prototypes stay on it.

Evidence and further reading

This perspective is maintained by the team behind NixieFX, the browser-based HTML5 particle editor for PixiJS and Three.js. A machine-readable version is available at /why-unity-unreal-era-is-over.md, and a site index for LLMs at /llms.txt.

Why I think the era of Unity/Unreal is over