They want to remove Blueprint in UE6

Development Programming & Scripting Blueprint
,
345

I don’t wait to be hand fed information that affects me. I seek it out. Dig into the details.

Downside of learning something new like verse isn’t going to hold me back. Game dev is littered with having to learn new things.

E.g. lighting, physics, animation, rigging, modeling, texturing, shaders, collision logic, visual fx, audio, audio concurrency/attenuation, networking, RPCs, 3 proxy split coding, modules…

World partition vs World comp, level streaming, STEAM & EOS, match making, server configs

This is game dev. Just like SWE, you constantly have to learn new things and languages.

Biggest thing for me is the performance upgrades that are coming. I can do more at the same or lower tech debt cost.

2 Likes
346

That’s correct. It’s a cycle of learning, learning something else, forgetting parts of it because we also need to allocate memory in our own brains, then refreshing / learning again when needed.

I like learning. That is what game dev requires anyway: a natural curiosity for things and for creating things.

There may also be an increase in the mid-level technical roles with this change, so it could actually be good for many people, still production wise we will see how it goes for big and small fishes.

347

Big fishes…

Halo is coming. There’s word that the next Fallout from Obsidian may be on UE. PUBG 2 currently in development on 5 may push up to 6. God knows they should based on what they’re doing.

ID TECHs layoffs and rumors of UE usage in the pipe for future games.

All the changes to the game thread, multicore etc and verse autothreading… Big fish will come. For sure. I’m not going to second guess that for a second.

Being able to do my own game and not have to rely on dlss or fsr for basic performance frames is a huge win.

348

Yeah, performance upgrades can absolutely attract big teams, no disagreement there. I just wouldn’t be too confident that performance alone erases production reality and pipeline stability concerns.

I worked in big studios many times. Changing engines comes with cost. Yes, you are no longer maintaining a full custom engine, which is a win, but now you may need to branch / derive Unreal to fit needs that your old engine already handled. That is not even mentioning employee migration cost, training, tooling, workflows, and production habits. I know multiple engineers who hated that kind of transition.

Not creating an argument btw, just pointing out that this is also a reality. Even if there is Visual Verse, it would still be a pipeline change that everyone has to go through.

I hope it unlocks big teams to make better games, rather than making the same games with better performance. But that part is not only about engine, money, talent, or performance. At a high level, it is about mindset and how you approach games and making games.

I am excited about multithreading, ECS architecture, and I am even curious about Verse. I like the modular “using/module” mindset, but I need to see how it feels in real production.

349

For the sake of argument, does anyone think it’s worth giving UEFN a try just for Verse and Scene Graph, knowing it’s not the full version of Verse?

350

I check some tutorials etc but didn’t dive into it. Seems UEFN when you write verse code, it compiles the project and launches a Fortnite session where you can test the scripts.

There are bunch of tutorials etc. generally writing something like a custom UI, a device which you can basically access underlying game logic / data, like agent data, spawned event, access an already existing widget spawn a copy pass data etc. etc.

It doesn’t look much like a full game development and creation process yet. It feels closer to a modding or scripting workflow inside Fortnite. Still, if you want to get your hands dirty with Verse early, why not? Although I think the way it is used will change dramatically once Verse becomes a middle layer inside Unreal Engine itself.

351

What’s strange to me is how Epic gave out this information. It was like a throwaway sentence in a presentation at Unreal Fest. No explanation. No reasoning. And getting rid of actors? Everything works with actors. And do components go away too? This is basically a completely new engine at this point.

This whole thing seems like a bad April fools joke.

2 Likes
352

Components still exist in Verse. At a creative level, the scene graph system isn’t really that different than the current actor focused framework. Just instead of making an actor, you make an “entity,” which for all practical purposes is basically an empty actor with nothing but a transform. To make a character/creature/door/whatever, you add mesh/collision/etc.. components and write a verse script to tell them what to do, sorta like one would a do a with a new blueprint actor.

While the underlying architecture is vastly different, the workflow sorta feels like a flashback to UE3, where one would make an empty actor, add meshes and stuff to it, then attach an UnrealScript to it for gameplay logic. Likewise, the ECS pattern is kind of like some of the newer subsystems they’ve added (like smart objects and gameplay abilities) where the systems are aware of the related components and don’t really care about actors.

353

I agree this could have been handled differently… the ue6 ‘general public’ communication is bad and people tied it to fortnite and ai when it’s not about that.

To be honest, though, this path has been laid for more than three years. Publicly. In the open. With the developers specifically asking for feedback. Here is a 2023 GDC presentation on Verse and the changes to unreal:

For those of us that have been paying attention this is not a shock, but more of a ‘finally’ moment.

354

The fundamental idea is that you will no longer need to learn programming to make medium-sized games.

LLMs can already generate code of sufficient quality, probably better than what a designer could produce alone using Blueprints. So the real challenge will no longer be knowing how to program, but knowing how to explain clearly what you want. Simply saying, “Make me a game,” will not be enough.

In reality, it is quite similar to how designers already work with programmers: the designer prepares documents explaining the systems, and the programmer implements them, usually adding a few bugs and some things that were never mentioned in the documents.

So yes, it is progress.

355

Well in some studios like that, there are roles like Technical Game Designer, Technical UX Designer, Technical Artist, Technical Designers where programming / designing can blur and do blur.

I don’t need a programmer/engineer to write an entire combat, interaction, movement or some visual system but that doesn’t make me a programmer / engineer, however it does makes me an indefinitely a better designer simply cause I can convey my thought in an organized, grounded, working, prototyped, documented. Some people can live in many roles lets not forget, but I do upmost respect for engineers/programmers who dive in low level code do real engineering.

However I noticed that a lot of people do consider themselves as programmer/engineer where they can’t write a custom movement/networking or a compute shader, but consider themselves that they don’t even need programmer or act like it. This is specifically visible in current Unreal Pipeline which is a problem of experience and self awareness. Verse is a potential win for many and loss for many.

Even though I like how my custom classes from C++ flows through neatly designed Blueprint Nodes, working with harmony in the game providing experience: I don’t consider blueprints is a loss or verse is a win.

I see over here in this thread, people do really binary about this change. It’s like black and white. Game design choices are not black and white in my opinion and “This is a progress” idea can vary from people to people, I think it’s not that obvious at the moment.

Like you said, add few bugs even solve some that never considered or designed/thought about. However let’s not forget LLM can not create problems / define problems but I can.

356

From a programmers pov i’d say this is true.

I would argue the quality of ai generated code still depends heavily on the knowledge of the person using it. Knowing how to explain what you want is important, but understanding software engineering is what lets you ask the right questions.

AI wont make someone a better programmer, but it will certainly make a good programmer much faster.

1 Like
357

Unless the programmer has higher WPM than AI and much more elegant design judgment :slight_smile:

358

Fingers from Ghost in the Shell Gif : r/woahdude

359

:smiley: I"ve seen it. I was lucky enough to sit one beside using stenograph for a while until she got laid off for not a reason at all.

1 Like
360

It’ll be worth getting your head wrapped around the flow and structure.

Heavy building I’d say no. UEFN is bottlenecked and restrictive.

1 Like
361

Nah. Blueprints were also nice because the blueprint system wasn’t just for scripting the actor blueprints themselves, but for animation blueprints, level blueprints, etc. Once you learned one, you could easily work in others (even scratchpad)… now, on the contrary, another layer will be added in the future, and not for everyone - with lower accessibility. And it would be bad to switch to the new UE6 with an optimized game so that you have more work to do and then change it while they meantime change it…

They can put their script there. But there’s no reason to throw away the Node interface (since they already tried it anyway, so they have it and remove it)…

On the contrary, seeing it as an investment is definitely good for the younger generation – in 7-10 years they will have a polished and usable engine.

1 Like
362

Add more layers, more complexity, make it more usable with AI, then with time nobody starts to understand how games work, how engine work besides AI at that very moment sell your own AI .

I see a pattern here so we are the product, not the engine? :slight_smile:

363

My understanding is that Anim Graph and Material Graph will stay node based. I’m assuming Substrate and MetaSounds will too.

1 Like
364

Just joking btw about “we are the product.”

As far as I understand, many graph-based systems will stay: Materials, probably Substrate / MetaSounds etc. Graphs/Designer facing things for plugins like gameplay camera etc. will stay.

I am not sure about UMG though, and I am also wondering what the workflow is going to look like for plugins / frameworks like GAS or even GameplayCamera.

For example, a lot of current Unreal workflows are not just “Actor Blueprint scripting.” They are editor tooling, UI, animation, gameplay framework integration, exposed C++ classes, asset workflows, and so on.

Let’s say we have some GAS effects, this effects tags detected by Camera to change its statemachine/rig, then maybe I want gameplay camera call back something maybe even GAS. What do we do, this goes on Verse or we wrap some C++ function to call to avoid verse ?

–
Edit: I also suddenly realized GameplayAbility graphs.

What will happen to them?

GAS could maybe maintain its current workflow almost unchanged, but with some internal differences. Or GAS itself may also change, with Verse-authored abilities. Or maybe GAS gets its own dedicated graph layer, while the C++ core stays mostly the same and we expose/wrap functionality into that graph.

That is another workflow question for me, because GAS today is not just Actor Blueprint scripting either. A lot of ability logic, tasks, events, tags, effects, animation, UI, and camera reactions can be wired through GameplayAbility Blueprints.