People vote with their feet. Unity had the same cocky attitude so did many others. I been in it a long time 37 years. They could have messaged it better everyone can admit that.
They could have provided a conversion tool to Verse in the presentation. Verse was created because programmers hate Blueprints (this is from my experience) they want to convert everything to C++ as soon as possible.
The excuse is merges and managing the code base. A lot of devs work dirty and nobody can tell what is going on in the BP so they just want to delete it and recode it in C++.
This is the reality I have seen for years now. I love the engine as it is, I donât need to make a choice right now. I can literately use this version of the engine for the next 30 years if I live that long.
They can just stop using this engine
Keep using the older versions of the engine
The AI thing seems to be a move to allow users to use AI which would prevent them from publishing on Steam, this might not be what motivated this move but Tim posting about Steamâs decision about AI was interesting.
Single-player games arenât going away.
Especially since creating a multiplayer game alone on your ownâeven with all the resources available todayâis rarely a good idea.
Robloxification niches isnât for everyone.
Creating content is what might perhaps becomeâŚ
game instance isnât an actor, canât be placed in a level, but can be made as a blueprint. It never has to interact with an actor either if you donât want it to. One could make their game instance class just do things to ai and player controllers, or player states. Or just make game instance a storage for global vars. Likewise for game mode, aside from defining default pawns itâs actor agnostic.
No, thatâs kind of my whole point. BP actors rely on actors because thatâs their native parent class. But blueprints donât have to be actors if they use another class. If the new generic entity class used by scene graph in the new framework were exposed to blueprint, one would likely be able to make a bp with it as a parent and drag it into a level. If 6 is shipping with BP support, I would imagine the new entity class will be able to be a parent of blueprint classes (with some limitations, like no traditional addable components). At least in early builds. If they make a few common children of entity to replace things like character, it may have enough standard features rolled in (like mover) so people donât panic if they canât add a movement component to their new pawn-ish entity.
Actor
ââ SceneComponent root
ââ ActorComponents
ââ Event Graph does whatever
Entity
ââ Transform / Scene node data
ââ components / fragments / traits / whatever Epic calls them
ââ systems operate on those
So basically, Entity + Transform + something like VisualVerse (hypothetical) can be done. It is similar in practical use, but not Blueprint as we know it. Basically it would do the same kind of things Verse/systems do on the entity. If you donât want graphs, you can just write Verse script directly.
They tried some graph attempts seems, they said on the presentations couple of times in Q&A but results were not successful enough (not sure what are details). It would preserve visual workflow, but not necessarily preserve Blueprintâs âdo whatever anywhereâ freedom which is the trade off they are making.
For average user I think that would solve a lot of problems. I think there would be something sometime anyway either Epic or Plugin. Which you can do things like
For bigger games need technical persons anyway who can mold code for middle users to do job, we will write systems and expose Verse molded classes and when they open with a graph will see special nodes designed for that specific classes.
as said I am ok with anything, I would like UE to be not damaged in the process but not also become do everything engine with the current direction of engine in multimedia.
I feel also like Unity was following Epic, now Epic following Unity a bit at least
I donât really understand this. As I understand, UE5 is already multi-threaded, just not on the game thread - and unless youâve done some really intense game logic, the main bottleneck for UE5 games has primarily been GPU performance and RHIT (which is CPU, but is already multi-threaded in the current version).
So you could technically squeeze some more performance out of the game thread for CPU-limited games, but for most games tearing up the BP workflow does absolutely nothing to alleviate the main bottleneck of most UE5 games.
With the current memory market being what it is GPU and VRAM are going to continue to be the main issue for a long time.
The benefits will also be a double-edged sword if the the Verse compilerâs error checking isnât bulletproof and people start finding the Verse entity they just made breaks because some sloppy code wasnât thread-safe. To be fair, AI tends to be good at finding the culprit for a nullptr or race-condition in a block of text after the fact, so the code would usually be salvageable. But if youâve got a bunch of artists writing verses who donât know the difference between a game thread and dental floss (nor how to explain the problem to teh LLM bot) thereâs bound to be tons of real life cycles wasted summoning annoyed programmers or engineers to fix it.
Granted, some this could be avoided to an extent if Verse entities and functions had to be explicitly flagged as thread-safe in the details panel (like how some anim bp stuff does). But that would just lead back to bottlenecking whatever thread the artist slop is dumped into.
Thread safety is fundamentally guaranteed in Verse through a transactional memory model. By running code inside automatic, atomic transactions, the runtime eliminates traditional multi-threading issues like race conditions and data corruption, allowing game logic to execute safely without needing manual locks or mutexes.
Automatic Mutual Exclusion: All synchronous (non-async) operations are treated as atomic. This means adjacent expressions execute uninterrupted within the same update loop without context-switching, acting as if they are wrapped in an automatic mutex.
Transactional Execution: Operations are tracked by the runtime. If a failure or out-of-bounds error occurs, the transaction aborts and cleanly rolls back any side effects without crashing or causing undefined behavior.
No Manual Locks Needed: Because the system is designed to handle concurrency transactionally, you do not need to use thread locks, avoiding the risk of deadlocks.
Thatâs excellent if it works as advertised. Though I canât help but wonder if the engineers at Epic may have underestimated artists and our preternatural talent to break all the things when code is involved.
Then again, they also figured out how to make a mesh with millions of polygons render as fast as a box with 12 triangles, which everyone thought was impossible before Nanite. So maybe I shouldnât be so cynical.
I really wonder what the downsides of this will be.
Its not like 99.999% indiegames ever would need this to begin with, even if only BP was used to make a game, and it seems to overcomplicate basic things quite a bit.
If it works like advertised though, and doesnt cause a mess, it will either cause unoptimized messy games (because people stop caring and putting effort into things) and/or allow those more skilled to go beyond what the previous limits were.
Guess we will have to wait and see where this will end up.
Ok - looks like this is something it would be best if I take the lead on then. UE is my hobby. But Iâve got relevant tech experience for the discussion. Will put some structured notes together and then post.
Absolutly understand. I have very severe dyslexia - so without a visual environment like Blueprint my error rate goes up significantly. Loosing blueprints would mean abandoning UE - which given Iâve been working on a hobby game for 5 years would be really upsetting.
People would be shocked by all the things the engine has already doneâstuff that others have to build completely from scratch just because they donât have the knowledge
