They want to remove Blueprint in UE6

Only reason I can make a game is ue5 blueprints. Learning C++ barrier is too high for me to do this as a hobby. I used to love how ue5 was very indie friendly with their pricing structure and their ecosystem. This move to verse is probably the biggest brain dead move I have ever seen. I will simply use ue5 for as long as it is supported and not put a single cent into their marketplace to support ue6. There are still so many things left for them to fix (new landscape system sucks ■■■ imo), why on earth are they bringing out a new engine when this one has not even been fully tapped?

5 Likes

The language was not create to be LLM-friendly, but it is more LLM friendly by virtue of simplicity, and not having a bunch of outdated, deprecated, or irrelevant information (if it was C# you could just as easily get something for Unity, Godot, or even XNA). It is LLM friendly by only having 1 source of truth, 1 real application, and a small sampling of “correct” data. For both C++ and C# the average code you find on the internet could just as easily be un-optimized garbage as it being the most optimized thing possible.

  • there is a situations with LLMs that because they cannot rationalize the quality of the input data, all input data must be trusted with the same accuracy, and then because LLMs by their nature are auto-complete with extra steps, or a probability word calculator, any amount of incorrect information can result in outright poisoning of the output result, which is why the big push to flag LLM generated content is coming from the LLM companies in an attempt to keep it from being feed back into the training data.

transaction limitation are not because of C++, Unreal C++ maybe, but many of the limitations are in spite of C++ in the general sense.
if there is ONE STATE at any point then the data must converge into that state, which is why a lot of games not just Unreal are bottlenecked by single thread performance to at the very least synchronize the asynchronous state changes, and spin up the other tasks. Which comes back to the question “Is multi-threading fasting? : Yes, No, Sometimes, Maybe”

Seamless Hot-Reloading: you can hot inject into C++ it just isn’t pretty, and very error prone, but also Blueprint already had this feature because a lot of stuff was run-time-resolved-path-strings you could replace that path string at any time during execution and as long as the resulting object resolves to the right type it will work. Verse didn’t introduce this, it is using a system that is already there (Epic was just “protecting” developers from themselves by making it hard to do). The downside of hot loading is that if there is ever a mis-match the application is in an indeterminate state, and the more tightly compiled the less gracefully the failure can be. Then in a Meta-Verse situations as is being proposed who is responsible if for our application the best answer to an indeterminate state is to Error->crash?

the security has little to anything to nothing to do with the language, because given the correct API, or just system calls anything can go wrong in this regards. As it stands every programmer that has a C compiler is on the honor system to not make a virus with just 3 to 5 calls to available system functions (at least Linux will ask you for a password first on many of those system functions).

  • this entire statement really means that there are some levels of optimization that can never happen, and some things will still absolutely require C++, but by locking out certain abilities it means that Epic is “not responsible” (the car manufacturer can never be liable for a high speed crash if the car can never go over 30 kph) because the secondary knock on is that if Unity and/or Godot ever have a Verse plug-in then they can just slot into Epic’s Meta-verse.
  • this is partially antithetical to the Hot-Reloading because that would mean there would need to be a high scrutiny system, and the only way to have any guarantees would be VMs which puts us right back at one of the big weights of Blueprints.
  • then a programmer, or more specifically a “hacker” is a problem solver, and where there is a will there is a way, and better locks just keep honest people more honest.

if everything is expected to be doable in the Verse Scripting language then it needs to have as much coverage as possible, and More coverage then even current blueprints has. At current Verse in UEFN doesn’t have close to the functionality as Unreal Blueprints. Which does not give me optimism for magically my UE 5 stand alone application to just go through a conversion tool, and slot into Fortnite because now UE6 has Verse scripting.

Yes, Epic is proposing to remove Blueprints for UE6, and this thread is giving feedback, concerns, and other options then just removing it. While you are stating “It is happening, and you will just need to accept it because it has been made”, which is antithetical to the concept of Feedback, and many large companies have made far reaching decisions in the past, and then because of Feedback they changed their direction, or at the very least re-evaluate the direction to a more mid-point.

the current proposed middle ground is that the following will still exist:

  • animation Blueprints
  • shader graph
  • Behavior Trees
  • Graph data, Data-asset
  • PCG graphical scripting
  • some kind of Entity Constructor

Blueprints is the easier entry point for inexperienced programmers over C++ and even Verse (there was this one tweet that ‘bringing a new dev up to speed on blueprints would be 5x as long as Verse’ which just on its face was laughable the entire time). I am glad that Epic is finely doing low level optimization of the engine. Blueprints has its issues, but the issue is removing THE sales feature that allows for probably the majority of indie developers to even use the Engine in the first place is short-sighted, because they believe that all of the ones that leave will be replaced with UEFN Verse devs.

Half of the ECS benefits could probably be accomplished by making UObject a first class base instead of having actor being the first class base. It would still take a fundamental re-implementation of the Engine, and it might be what ends up really happening, but that does not preclude Blueprint Scripting at all.

4 Likes

Rest assured, they aren’t going to export any of these superpowers to beginner developers. Everything that is more complex, difficult, dangerous will continue to be handled in C/C++ within the engine’s own implementation. Verse is one thing. Unreal modules are another.

…this entire statement really means that there are some levels of optimization that can never happen, and some things will still absolutely require C++…

That has always been obvious. The better they manage to implement the most relevant low-level functionalities, the less programmers will need to meddle in things they don’t know how to do right. That is precisely what game engines are created for.

…which is antithetical to the concept of Feedback, and many large companies have made far reaching decisions in the past…

You are confusing ethics with morals. There is nothing unethical about a company deciding what to do with its own resources. It is neither philanthropy nor communism. It’s a business
By the way
“Customers don’t know what they want until you show it to them.” (Steve Jobs)
“If I had asked people what they wanted, they would have said faster horses.” (Henry Ford)

…the security has little to anything to nothing to do with the language…

No one was talking about security in a general sense. The security aspect that was highlighted relates to the safer sharing of scripts designed to modify the game, rather than the user’s computer.

…LLM generated content is coming from the LLM companies in an attempt to keep it from being feed back into the training data…

People were repeating that 3 years ago. Nowadays, LLMs themselves generate much of their own training data, just as Chinese models have done.

In programming, the biggest problem is other—and it’s something hardly anyone talks about.
LLMs use a kind of POP: “patch-oriented programming”

They don’t seek to solve the root of the problems. They fix everything with quick patches.
That’s why even better “prompts”, “skills” and “specs” don’t solve it.
Because Code is like a “stack of plates”.
Everything goes crooked until it collapses and only rubbish remains.

LMs only seem wonderful and flawless to those who can’t perceive the root of the technical debts - beginners, noobs, sloppy programmers.

LLMs work well for creating clones of something that already exists
Or for small libraries to keep entropy isolated and controlled

It’s still better not to let an LLM handle architecture
because you’ll really just be wasting time most of the time

1 Like

you brought up optimization, and security as arguments in favor of Verse over Blueprint scripting,
Yes Blueprints because almost everything is runtime resolved path strings and inside a VM it has performance issues, and that has been fixed by putting more of it into compiled C++ byte objects

  • the size of Actor could be adjusted by anywhere from 5-10% by doing away with OOP “standards” of singular Public->Protected->Private blocks, and doing byte alignment optimizations
struct A                struct B
{                       {
public:                 private:
     bool var1;            int32 var1;
private:                public:
     int32 var2;            bool var2;
     bool var3;         private:
                            bool var3;
};                      };
// one of these is 50% bigger then the other in memory but OOP standard of 'public first then private' which is used throughout the engine 
  • there would also be monumental gains on memory optimization by running Blueprints through a Byte alignment optimization step as opposed to “leave it as it lay”
    • the number of systems in the professional world I have improved in performance by just adjusting byte alignment is criminal. with un-optimized byte alignment you can see similar to better results fixing that then going with a “faster” algorithm

you Raised these as 'so much can be done in Verse that C++ will be rarely needed, but then many real optimizations and speedups happen in C++.

The meta-verse part was about if my program needs to load an asset that doesn’t exist for some reason (which is a semi-common failure point of Blueprints) then the program needs to respond, and sometimes the answer is to let it crash.

“antithetical”: against the thesis, or underpinning of the argument/Idea. Not ethics, not morals, but the logical, and factual context of the discussion.
There is ethical and moral discussion to be had about for the better part of 15 years asking a large number of aspiring game devs to learn this tool, and then say “nah, we changed our minds”
allowing users to build up Engine plugins, extensions, tools, and assets that between the switch to ECS and the removal of Blueprints will just be wiped away, which is even less ethical for the people that have spent money on any of that stuff.

Chat GPT within the last 3 months has requested the tagging of information generated by LLMs, Anthropic has never stopped requesting the tagging of LLM generated content, both Google, and Meta are forcing the tag onto the content, and making it harder for 3rd party tools to remove it.

  • you could argue that they want the tag to ensure “low quality” output from the competitor is ignored.
  • but even now especially evident in image generation a data set with more then 10% LLM generated content will start to generated effectively noise in 2% of output, and the noise generation is exponential compared to the LLM content as training data.

Please Learn what those quotes are about, and the context of them:

  • “People [sic] don’t know what they want until you show it to them”

    • was about alternative solutions to problems people are facing then what is being requested. The notion of listen to the “problems” and then find the solution that may have little to do with what the person is suggesting as the solution.
    • In the context of this “Hey we would like Blueprints to perform better, and have more functionality”, “So you chose to just delete Blueprints, I See”
    • also Steve Jobs: “We have no intention of releasing a tablet version of the IPhone” - about 3 years later → “I present to you the IPad”, “Oh we actually worked on this first…”
  • “If I had asked people what they wanted, they would have said a faster horse”

    • Henry Ford was creating a “new” market, and supplanting a functional existing market, and still had to justify the purchase to business owners at the time with “speed”, and endurance
    • Epic is not creating a new market segment: Game-Engine, or Meta-Verse-Game-Engine, both of these have existing before Unreal got there by Id-tech/Unity, and Meta/Facebook respectively.

how about:

  • “the Customer is always right, when it comes to matters of taste”:
    • Unreal was marketed as an entry point for programming, because of Blueprint scripting, and the modularity of the Engine though the market place.
    • what programming language to use (C, C++, C#, Java, Rust, Blueprints, Verse) these are a matter of taste and preferences.

LLMs use the “patch-oriented programming” especially in Agent Mode because the LLM is presumed it will make a mistake, and so replace what is incorrect, which is just a shorter time scale of something called “Agile”, or “modular design” things that pre-date LLMs by decades.

1 Like

Nothing is being wiped away. You still have the option of staying in 5.8. Even 6.0 will support BP.


UE6 Main BP updates

https://github.com/EpicGames/UnrealEngine/commit/dae0d248901b07599ed9124c716418bb4e446f30

https://github.com/EpicGames/UnrealEngine/commit/e03cbcbd919031681250857c2cddf845954fe378

This feels like a refactor / clean up at the moment. Like circular dependencies and moving dependencies in to their respective logical boxes. At least it is how I read it.

This doesn’t feel like removal (for now), in fact is a “Face Lift Operation”, we can read it as future preparation to remove them (if) when the time is right. I am still skeptical about it , reading all comments in thread but maybe we love Verse somehow.

Most comments on this forum are attempts to guess the future and underestimate the developers’ intelligence.

I understand how frustrating it is to invest your time in something that ends up being discontinued. Companies like Google are constantly discontinuing their projects, and everyone always complains about it all the time. This is the most common scenario for people who build a house on rented land.

But, whether you like it or not, the companies are the ones who decide this—not the customers, nor majority of whom don’t even pay to use the product - and who in fact are more users than customers themselves, and want to demand the same rights they imagine they have.

I’m not going to repeat here all the reasons that motivated the development of the Verse Language about features which would be inferior in other languages. It seem like I’m defending this or that. It’s all on the internet. Just search and find out.

When a prototype of the new visual programming version appears—since it has already been decided that blueprint won’t be used in future—you can test it out and complain.

You have the right to criticize the company’s strategies. And the company has the right to ignore what you consider best and implement what the company considers best.

I have already pointed out here that there is no silver bullet. There is no single best option in every possible sense. There is no best language in the universe that solves every type of problem. There are choices—and everyone reaps the benefits and drawbacks of their choices.

The company could have taken several other paths. But it didn’t. And this happens every day, with all companies. If you’re interested, read Godot’s article explaining the reasoning behind their choice of OOP over ECS.

Have you learned nothing from the Unity boycott? You’re underestimating the users, especially users with a platform. No need to be a big fish anymore to make they listen.

Personally, I prefer functional languages, and I detest classes and OOP
But when I have to use it, I use it without any issues

Does your game make millions and pay royalties to help in for engine development?

If not, I regret to inform you that you are not the target audience for this new technology.
And you can continue using inferior solutions and boycott whatever you want.

Who told you only the “small fish” will be bothered by this? Who told you every big fish is going to roll with this with zero complaints?

I really don’t have a crystal ball

Same. If code is written neatly, I can read and write it. I have preferences and tastes like everybody else.

Core is C++ anyway, so no problem there. I think many people, depending on their level, will find a way through the engine and continue working. Even when we get used to Verse, maybe it will be okay, maybe even better.

The thing is, we can already see the backlash, right? YouTube, Reddit, this thread specifically, and honestly this thread has been nice because it has many different perspectives.

Even if we say “you can keep using UE5” or “you can stay on the last UE6 version that supports BP,” that will not be enough, right?

People will want the comfort of Blueprints plus the evolving features of UE6. Also, in terms of job opportunities, we cannot just tell many developers to stay with BP forever. That is a no-go for me and probably for many others too.

And in production reality, if there is no good visual workflow replacement, lack of speed and iteration time will become an issue in some organizations.

As I said before, objectively the way I look at this change is simple: will Verse unlock us to make better games, more efficiently, and maybe even challenge existing norms and designs?

My answer is literally “maybe.” I am not against it, but I am very skeptical.

And that skepticism itself takes something away from many creatives: trial and error, experimentation, speed, and confidence in the workflow.

Not every performance upgrade makes games more fun or better. Even if I agree that the new architecture may be technically better, the trade-off can still be a deal breaker for many fish in the sea, regardless of their size.

Opinion less charged with guesswork and emotion == Opinion more charged with logic and maturity

Sure, but workflow risk and adoption friction are practical concerns too, not just emotion.

Many people here are speaking from production experience. Calling skepticism “emotion” does not really address the practical concerns.

Skepticism with emotion and skepticism without emotion, in one way or another, regardless of the imagined labels, it’s not even practical to try to resolve anything emotionally charged

It’s dependency merging for easier removal.

Pack it all into a box

1 Like

Yeah, that’s what I meant. Isolating is the better word.

I’m excited to see what’s next. Limitations barrier lifted a bit more.

Well, at least someone is…