I’m pretty sure GAS will get a complete Verse overhaul.
Think that too. Same for Mover.
1 Like
yup, maybe even CMC… maybe
From what I understand, everything in the viewport window labeled “Blueprint” will disappear. Therefore, the data flow, PCG, metasound and materials will remain as they are. Furthermore, work is already underway to replace the animagraphs.
Seems like every team is responsible for what to do with their respective subsystem. The removal of the “Blueprint” wording doesn’t mean discarding the node base system:
But that’s how it has always worked.
I work as a designer: I write a document explaining that I want a weapon system, how it should behave, which inputs control it, and what the player needs to be able to do. I don’t know exactly how it is implemented under the hood, nor do I need to. I don’t even particularly care which engine is being used. That part is the programmer’s responsibility.
Now it works the same way, except that instead of handing it directly to a programmer, I explain it to an AI.
And, feeling briefly possessed by an AI bro who wakes up at 6 a.m. and drinks water, I’ll say this: yes, I think it’s possible.
I hope that, eventually, every part of the engine can be controlled through MCP. And I don’t mean that only from a technical point of view, but also from the point of view of a lazy person who doesn’t want to open seven windows, dig through three menus, and repeat the same task twenty times when it could be described in a single sentence.
Well, I have been a Technical Designer throughout my career, and in some studios it leaned more toward Technical Art. Wherever I was, I always coded in various languages and frameworks, including some long-gone ones.
From my perspective, for a designer, understanding, internalizing, and solving the problem is a must. That is something that really separates many designers, especially from a programmer’s perspective. Design is not just “write what I want.” It requires intense thinking, deep thinking, and focus.
Design process exists in many job families, including programming. Good design taste also makes you a better engineer.
You can write a design document for a weapon system: inputs, damage, ADS, attachments, deployment, pickup, recoil, reload, etc. Then a programmer needs to decipher that from the document.
But if you write that same system in a more precise computer/system language, or prototype it, you start realizing the gaps in your design: logic errors, design pitfalls, communication errors, or sometimes complete design mindset errors.
That is why designers prototype. They do it to evaluate the design. Technical designers often build whole systems without needing a programmer most of the time, or share the work because everyone has limited time. This also unlocks systems thinking: how to encapsulate logic, which system talks to which system, where data flows, and where responsibility lives.
So for AI, I see a big difference:
- Give a design doc to AI: good luck making something that actually works well in the end.
- Give a technical design document to AI: it will probably do a better job, but you may still hate it later if you did not review and guide it.
- Give AI an existing architecture, patterns, naming convention, and a precise task inside that system: only then it can maybe do a good job.
For example:
“In my weapon deployment state machine, observe the existing patterns. Add a new enum for HitScan Deployment and the respective function following the current naming convention. For hit data, use the existing UMyDamageSystem interface. For hit evaluation, use or extend UMyWeaponSubsystem’s EvaluateHits function.”
That kind of instruction can work, because you are not asking AI to invent the architecture. You are asking it to operate inside one.
Even then, AI often chooses the shortest, ugliest, least elegant path unless you explicitly guide it: use an interface, keep functions reusable, move this into a subsystem, follow this folder structure, preserve this pattern, etc.
So yes, you can design with AI. But I would not expect AI to design something good for you by itself, at least not in the near future.
PS : Fixed my grammar with LLM using prompt : Re organize my answer, keep it my tone, don’t loose meaning, don’t interfere structure. Try make it better in terms of flow and grammar. If there is a wording that can be misunderstood warn me about it as bullet points in the end.
It didn’t write it for me, it analyzed, corrected (if necessary hopefully), informed.
2 Likes
If Epic genuinely wants AI to become a professional production tool, Unreal Insights should be one of the first places to implement it. Moving between GPU and CPU profiling and lots of stats can mean days or weeks of detective work even on an AA project. There are many areas like this where AI could save weeks of work without generating or directly modifying game content.
Prioritizing vibe-coding features instead feels more focused on lowering the entry barrier than on solving production-scale problems. Multithreading parts of the game thread may be valuable, but pursuing that direction while the editor still contains basic stability and validation failures - such as crashing because an oversized lenght (1024) was pasted into a name field - suggests that professional workflows (even on indie) are no longer receiving the same attention.
I cannot know Epic’s internal motivation, but companies are ultimately defined by the priorities visible in their actions. The Epic that developed the earlier Unreal Engine generations appeared to operate differently. UE3 changed substantially after the release of UDK, and Blueprint later removed many of the workflow barriers associated with UnrealScript. In that sense, the current situation feels less like a new problem and more like a repetition of the past.
It’s basically Ubisoft’s approach, which is bad for the public engine and all their users. Tim Sweeney keeps saying he doesn’t like it (Apple, Valve), but they’re going in the same direction.
3 Likes
Could be. As you said, we cannot really know, we can only guess or have a gut feeling. But as you mentioned, and as I mentioned in the post above, that is one possible concern.
I am not even sure lowering the entry barrier in that way is fully good for aspiring developers. It reminds me of: give a man a fish, and you feed him for a day; teach a man to fish, and you feed him for a lifetime.
I also agree with the “new problem” part. Maybe we can sense it at the moment, but we cannot really prove it yet.
Even though I am okay with Verse, a new language, multithreading, and ECS-style architecture, I still asked the question: why not C#, or a safer subset of it?
There are technical arguments: entry barrier, safer code execution, simulation aspects, AI, UGC, etc. Many people brought good points in this thread, and I agree with some of them.
However, since you mentioned Ubisoft, it fired some PTSD neurons 
I want to disagree with the idea that the intention is to push users/devs into an Epic-owned, controlled, or future-locked language. That would feel very contradictory to what Epic has generally provided and demonstrated publicly with Unreal.
If that ever became the real direction, then yes, for me that would feel like a second agenda, maybe even an “evil idea.” My response to that would be simple: free the code.
Thanks by the way. Your perspective is unique, even if controversial and speculative. I honestly hope the motivation behind the movement is not what you describe.
But I wasn’t talking about designing—I was talking about writing the code, which is what this post is actually about.
There may not be a visual verse editor anymore, but will we even need one? Or will AI be able to write the code for your game design?
You’ll still need to understand Unreal Engine and follow best practices so you can guide the AI effectively. And yes, you’ll probably still need to review the code it generates from time to time.
But will you stop spending your days wiring everything in thar hell? I think so.
2 Likes
Yeah, then I think we mostly agree.
AI can reduce a lot of boilerplate / wiring work, and that is good. I just see visual scripting as a workflow preference too: readability, debugging, discoverability, quick iteration, and communication.
Maybe some people will prefer AI + Verse, some will still prefer a visual layer. For me the question is which workflow feels better and safer in real production. I really don’t know. All I know I like C++ to BP exposed workflow already.
I will see how Verse feels. Maybe it will feel like a game changer, or maybe it will feel like a narrow shoe on my big foot We will see. I am genuinely excited to see if the game changes.
Same here ue6 is a dead duck in the water. I simply refuse to learn another language, I’m too old, this is exactly why I chose blueprints.
2 Likes
I think the concern is valid. Blueprint has become a core part of Unreal’s appeal, especially for designers and creators who don’t come from a programming background.
Hopefully Epic doesn’t treat this as a replacement of one workflow with another, but instead gives users options. A visual way to work with Verse or a tighter SceneGraph + Blueprint integration would make the transition much easier.
The direction is exciting, but the key will be keeping Unreal accessible for all types of creators, not just programmers.
1 Like
If you’ve read the thread you’ll know BP is out and they’ve abandoned inhouse implementation of visual verse.
As of last week they have pretty much consolidated BP and removed dependencies on the UE6 main branch.
By 6.2 or 6.3 Actors and BP will no longer work in the engine.
If you’re locked in on BP then you need to stick with 5.8 or wait for the community to develop a verse visualizer plugin.
They basically said it out loud, what about AI:
"Thus, for UE6, we see LLMs, generative AI models, and tools like Claude and Codex playing a central role in helping you build content faster while maintaining the creative control you need. A big part of our effort is going into exposing a broad set of engine capabilities through the MCP protocol, so that developers can mix and match the best leading-edge models and build custom integrations of all sorts on an open Unreal Engine 6 MCP foundation. We are also improving the Epic Developer Assistant (EDA) as an optional turnkey solution, available to all by default.
Our goal for UE6 is to greatly reduce the tedious work in authoring content to leave more time for creative exploration, and increase the amount of iterations a team can make to polish their content. UE6 will ship with tools and workflows where you can choose to bring your own favorite models, battletested against internal development and in UEFN.
Also, internally at Epic, we’ve been doing a lot of investigation to see what works and what doesn’t for code generation. We recently opened up pretty broad usage for code generation and AI analysis across our backend, engine, and game development engineering teams.
We’ve had particular success with people writing custom tools for their own work, fast code indexing tools for helping LLMs deal with large codebases like Unreal Engine, fast incidence response analysis, automated root cause crash and CIS job failure analysis, automated test generation, and of course the acceleration and parallelization you’d expect on backend service development.
What’s interesting is that most of these use cases aren’t even generating mainline Unreal Engine code, though that will probably come eventually as well. You can expect Unreal Engine 6 to also include all of the key learnings for using codegen for engineering along with content workflows."
Good, think we will do some tools anyway on it. We will use it, and I will code Verse anyway. Even if I use LLMs, I can still review the output and make sure it does not ruin the architecture.
Nothing can fully stop bad coding anyway. Not Verse, not Blueprints 2.0, not AI. Bad engineering is just bad engineering.
2 Likes
I don’t think this will happen very early in the UE6 lifecycle.
Epic would not merely be abandoning a technology. They would be disrupting a huge ecosystem of established FAB assets, tutorials, and production pipelines that a large part of Unreal developers rely on. Unless they provide a revolutionary workflow improvement, along with reliable migration tools and strong compatibility for existing assets, I don’t see a realistic scenario where Actors and Blueprints are completely removed anytime soon.
Anyway, Unity can run with Unreal rendering now. You can publish into the Fortnite metaverse using Unity and C# instead of Verse.
https://x.com/unity/status/2079386635100135883
6.2, 6.3 are in the 2030’s.
Production 6.0 won’t be ready until 2029.
By that time coding REALLY won’t matter at all.
Well by the look of the garbage I see on a daily I think actual programmers are safe for quite some time.
Train on Garbage, Output Garbage
3 Likes