Unreal Engine 5 = Game Changer

No, and im sorry if this comes across the wrong way. But I just dont like how some people may have barely touched a feature just to start trashing it and labeling it unnecessary. Epic is smart, surely they have their reason why they invested so much in bp and above is testimony for why. Because they give so much power to people that don’t necessarily come from coding backgrounds and allow them to create incredible projects on their own

 

Exactly, thank you. Im not trying to offend anyone here. But its also not fair to make judgements. Just because you maybe aren’t using it doesnt mean that thousands of others arent or find it awesome. Just a thought... Also a reason why unity bought bolt recently?

 

Imagine using a state of the art AAA engine with cutting edge features and having made 10 million bucks with it and the fact that you have to drop 500k out of 10 million being the biggest of your worries.... jeez

 

Then I'd advise to think of a better way to phrase your posts in future. Because this is the impression your post gave, whether this was intentional or not.

As I said, I actually worked with blueprints whiel writing scene transfer, and despite that it didn't help my opinion to them.
I view Epics insistence on using blueprints in the same way I view Unity's insistence on using C#. Meaning not entirely rational thing to do. They're inferior to code in most tasks.

Epic actually came full circle with them. Initially they nuked unreal script and replaced it with blueprints, because "this is the way of the future". Now, apparently, they acquired a scripting company in order to add a scripting language once more.

You can write GTA 5 in assembly or brainf*ck. Just because you can, doesn't mean you should.
https://en.wikipedia.org/wiki/Brainfuck

2 months to start making a first game is comparable with unity's timeframe to learn the engine, and is not impressive. Unity also allows very rapid prototyping (which is why it is often used in jams), but I can't quite say the same thing about unreal, despite blueprints.

Readability of blueprints is low, along with scalability, and that's why they're largely a crutch for people that can't program. Clean blueprint example can look like this:

Majority of this screen is wasted space and it does not give you at a glance understanding of what is going on.
Bad example can look like this, by the way:

This has lower information density than code.

I also worked with blueprints before while writing scene converter to unreal. I know what it is about. They're less efficient, take longer time, and require more discipline then it takes to program in C++.

It is a crutch. The main idea is to tell the user that "you're totally not programming, so you can do it". While it is still programming.

 

Code often doesn't need high information density. This is honestly the case for most games, even.

 

Well for me both of them is looking extremly crowded and hard to read

 

Yes they re never gonna be better than code but they cant be disregarded as something you should avoid either. Like mentioned, its how you work. In bp you can also create macros functions and what not to clean up the nodes. Its not about the tool but about the person. People can write bad code just as much. In bps you can just get lost quicker if you dont work cleanly. But again to say they have very little uses is ignorant. And to say write gta v in assembly is just an attempt to downplay my arguments. Blueprints is a great way for non coders or small teams to build fairly complex games. If you have a team, naturally you will have programmers but usually you will see in lots of ue4 projects that even artists are helping out with some of the gameplay scripting as they can do so with bps.

again like mentioned epic has bunch of tools to keep your bps nice and tidy, but not everyone uses them. At the end of the day both code or whatever, bp are just tools and in the end building game is what matters. bps have held their ground nicely. Not to mention the low skill ceiling it has...

 

It does. There's a difference between being able to understand at a glance what's going on based on something that fits a single screen, compared to zooming and panning for half a minute with a virtual magnifying glass.

They can and they should be. There's 1..5% of cases where visual tools are useful, in the rest of the scenarios they're a crutch.

I know what blueprint functions and macros are. However they don't help much.

Spoiler

You can learn cable management with blueprints, I can give them that. But, while you're maintaining "cables" and making connections look nice, you're not programming, and wasting your time on non-game-related task.

Another problem is that there are no diff tools for visual scripting. This is a massive disadvantage.

The main issue is that something that takes a line of code might require a full screen of nodes.

Spoiler

Code (csharp):

1.  
2. half3(n1.xy + n2.xy, n1.z*n2.z)
3.  

And THAT's why they're inferior. Because you can get lost quicker in them than in C++, and because you need more discipline than while working in C++.

Which is exactly what a "crutch for people that can't program" means.

 

I don't think the problem is with BP. I think the problem is with the arcane C++ syntax, poor C++ documentation, less useful C++ API (no CalculateObliqueMatrix for example, which is important for portal rendering), glitchy hot reload, having to restart the editor on header file changes, C++ being crash-prone, slow C++ iteration and compilation times, poor C++ tooling (you have to buy Visual Assist for usable IntelliSense?) and not enough tutorials for C++.

In other words, it's not BP that's the problem, it's Epic putting too much focus on BP and basically forcing developers to use BP to have a usable developer experience that's the problem. Granted I don't have much C++ experience in Unreal, but it's the major complaints I heard from C++ devs that turned me away.

 

There's a reason why even chip design is done in code these days rather than laying out schematics by hand.
https://en.wikipedia.org/wiki/Hardware_description_language

The way I see it, visual scripting tools would have much higher usefulness if writing text scripts within nodes was a standard feature. Because in this case they'd be a useful tool for highly parallel processes and signal processing.

For some reason something like this is a never part of visual scripting systems, though.

 

This is correct. Heavy focus on blueprints along with quality of C++ documentation is indeed a problem of unreal engine.

The moment you start trying to make anything in the engine, it will keep trying to shove blueprints down your throat, and the whole visual scripting is nigh impossible to avoid. For example, even if you drive animation from code, you'll still need to create a blueprint object.

Overall, you need higher C++ programming skill to work with unreal in C++ compared to skill level you need as a C# programmer in unity. The situation is improving, but very slowly.

The interesting thing is that C++ in Unreal is technically a dialect. They added features like garbage collector and reflection (you need to mark things you want garbage-collected and reflected, though), so the difficulty of C++ in the engine is lower. On other hand engine is compiled with C++ exceptions disabled and discourages their use. That's not necessarily a good thing either.

 

Amplify Shader Editor has both, If you open the source code of any AmplifyShader you will see a beautiful CG shader that includes all graph sources serialized into one line of comment.
Unity should've bought Amplify long time ago.

 

If you modify the "beautiful shader" yourself, is the change going to be reflected in shadergraph when you open it? I highly doubt it.
How about diff tool support for that single line comment?

Devs of visual tools should look into language that can be written by hand, and easily parsed onto a graph. Meaning whther you're dealing with source code or the graph, you're dealing with the very same file.

 

No but I can create my shader in ASE and have it work in HDRP, URP or Built in without all the faff. Or rather minimal faff.

 

That's exactly what I want. I imagine it would be amazing if Epic Games made a scripting language that essentially evolves blueprints forever. Because the core logic would be written in the scripting language, you could switch to graph mode and instantly see the visual representation of the code. Whatever changes you make in the graphs would serialize in the scripting language, and any extra data would only be needed for things like node positions and scene references.

I could imagine a scripting language like that would also work really well outside of game development.

I believe tools like Nottorus and UNode came pretty close to achieving this through their c# parsers and c# generation. Generated code never looked the same as hand written code and the process of parsing and generating c# code was never a seemless/natural experience.

 

Considering the mobile game industry, as claimed by epic games in the Android device compatibility section, only GPUs capable of OpenGL ES 3.1 and above are supported which means you can't have your game running on devices powered with GPUs blow Adreno 4xx series.
That means loosing a noticeably big chunk of your potential users.
As a mobile developer, I personally still see Unity as the best option especially with features like Adaptive performance brand new UI and DOTS.

 

Yeah, tbh Unity is still ahead of Unreal in that aspect. Not to forget notch support, that service where you can publish to third party app stores, Unity ads etc.

 

I wonder why nobody is investing into this.

On other hand a language where this kind of thing can be easily done already exists. It is common lisp.

Spoiler

https://xkcd.com/297/

The way I see it, there's no proper distinction between code and its representation right now. For example, the whole spaces vs tabs thing stems from desire to make the code look pretty. However, to me it seems obvious that this is something that should be done by the IDE and not manually by the programmer. Programmer could manually indicate "indent" and IDE should technically decide where this lands.

Likewise in blueprint/visual scripts one horrible feature is moving nodes around and rerouting. For example, in Unreal's blueprint system there's no way to define a "bus line" and have multiple nodes connect to it, that's why there's so much spagetthi. However, if layout was done automatically by the program, that time waster would disappear.

One interesting approach to semi-visual code I saw happened in autonauts:

Spoiler

This is clearly code, but at the same time it is visual. I heard that scratch offers something similar, but haven't properly tried that.

But this is something that can be pretty much stored in a text form and be easily parseable.

 

There's a 3rd party plug-in that allows you to work with blueprints entirely with the keyboard, auto layouting as it goes. They should hire the author and make it standard.

 

at the end of the day alot of people benefit from visual scripting and do awesome stuff with it and thats what matters. It has such a low skill ceiling where you can see people coming up with impressive games in relatively short amount of time. You can call any function that is in bp in C++. I write base classes in c++ and expose them into bp and do work there and this is where unreal shines. It supposed to be work interchangeably. Bp will help people new to game development get an idea on how to make games, granted in a visual form. It still makes use of basic programming knowledge. Just helps you get a better grasp. Obviously if you re from a hardcore coding background, BPs will feel unnatural for you. For me and many other people they feel great and let us do great things easily. But again, my issue is the the „I dont like it, its not good“ notion. Just linked bunch of examples (games) that ride the point that bps are not just some random gimmick

 

Whole thread is basically revolves around two things:
1 - Stabilize and extend current things
2 - More spaghetti

 

All I'm gonna say is, there's something at least a bit funny when there are people calling visual scripting a crutch, but they're using Unity instead of writing their games using C to write against the Vulkan API directly. There have been many successful games released using just Blueprints, Hollow Knight (made with Unity) used Playmaker for its enemy AI and other FSM-like stuff. Sounds to me like there are a lot of people out there making highly successful games instead of spending their time on forums arguing with gatekeepers. Guess what? In the enterprise world, we don't call using tools and libraries "crutches." We call them working smarter. "But there's a difference between the thing that I'm using, and the thing that I'm making fun of other people for using!" It's all levels of crutch, my dudes. Do what it takes to ship your game.

EDIT: Also funny to me the number of screenshots of "look at how gross Blueprints is hurdur" and there isn't a single comment box on the page, as if we're just assuming there's no way to put comments in visual scripts. I've seen some pretty gnarly actual code in my day. Commenting visual scripts is how you make them readable.

 

Q: In theory could you match or exceed the PS5's SSD drives speed on a PC using a RAID 0 array of SSDs?

 

The requirement to use C++ is a major, fundamental obstacle to Unreal 4/5.

Basic gameplay programming for relatively simple software (games) should not require expert, precision coding to the level that a bank would need for its enterprise systems (and you are competing for the same talent pool).

If UE4/5 is free, it doesn't matter, my programming labour expenses will double because Unreal Developers simply do not exist as freelancers, and if they do their rates are at least double that of Unity programmers.

On top of that Unreal 4 still has problems with games from reliable developers crashing, whereas Unity is basically rock solid.

The other problem is that the basis of the games industry (like it or not) is mobile/casual games and Nintendo Switch games. In many cities around the world, developers cut their teeth on these games and build their careers on Unity. PC/Console development typically requires bigger teams and so is often restricted to major cities. Search for 'Unreal Developer' on LinkedIn, Upwork etc. and in many big cities around Europe you will literally get no results, but many for 'Unity Developer.

Even in cities with Ubisoft branches etc., many of these teams are basically asset farms who create background assets, with the core design and programming still done in big, Western capital cities.

Blueprints are useful for shader and game balance logic (which need to be accessed and modified by non-programmers) but not for core functionality.

 

It does not require expert, precision coding, because C++ used in unreal 4 is a dialect. You have properrties, reflection and garbage collector. Complexity is a reduced. Nobody is asking you to write your code via template metaprogramming. Actually, quite a lot of community tutorials for C++ were written by a single user who was not a C++ expert.

On other hand, requirements to use C# is a major, fundamental obstacle to unity. Due to C# failing to provide appropriate tools for dealing with memory allocations, singe memory allocations produce non-deterministic performance hiccups, and writing GC-less code in C# is not exactly easy.

 

There's incremental GC coming soon though which is honestly really cool, kinda gives you GC for free. Also, I'm curious, does Unreal C++'s GC also have performance hiccups? If not, why not?

 

Pretty much this. Creating performant games on Unity means not using C# as it was fundamentally designed to be used in the first place.

People have an exaggerated idea of the complexity of C++. It is more verbose and there are more concepts to be aware of, but it's not like you're writing code in assembly.

Also, the source-accessible nature of UE4 allow people to write their own alternatives. If you dislike blueprints and would like to "script", there's the open source Haxe plugin (https://github.com/proletariatgames/unreal.hx), which gives you both fast iteration times and native-like performance.

 

I'm getting hungry

 

It can have a hiccup. However, there are a few differences:

- In C# a lot of mundane operations generate garbage, like string manipulation, yield returns, and async task scheduling. Only recently dynamic stack allocation without unsafe contexts was introduced (and it's still not supported by Unity). These will contribute to garbage collection time as much dynamically created UnityEngine.Objects.

- In Unreal, only classes derived from UObject participate in the garbage collection process. Everything else uses RAII as usual in C/C++ software, where objects are destroyed the moment they go out of scope. You also have control over when the garbage collection happen, so you can time it to moments where a hitch would not be noticed.

 

I've heard a lot of good things about Haxe.

 

Isn't that exactly one of the major reasons why DOTS especially ECS technology is presented?

 

In unity we are having GC problems due to the Ancient Boehm GC.

If instead unity would move to the modern .net core, with generational GC, all of this would not be an issue, at all, allocations are simply not a problem.

In terms of productivity and ease of development, C# provides higher productivity compared to C++ FOR SURE. BEYOND COMPARE. The tooling, the ease of use, the standards and libraries, are so much better... nobody that worked with both languages can deny that.

Writing performant code with C# in the latest .net runtime is also on par with C++. And SIMD is build into the runtime. You are hard-pressed to find real world cases where you actually need C++.

Honestly The path unity took with DOTS/ECS/Burst is the wrong path, because they take away all the features of C# that made it a good language. But it's not too late for unity to switch gears and solve the problems that developers have, which is not moving 500.000 fish in a pond simulator, no they make complex games, that are not really well suited for a DOD approach. unless you perhaps have 2 times more programmers to spare (most unity developers don't have that).. Where did the Democratizing game development went to?

Unreal on the other hand have the knowledge and will to make their own scripting language from scratch, it is what they are working on right now, I expect it to fall anywhere between some kind of LUA and C#.
It makes sense for them because they will be in full control of the language, runtime and stack.

But the reason Unity became big is C# support, and it could be done right, Instead Unity wasted 3 years on Burst which is not necessary faster than .net core. sad truths. Whilst .net core allows for the full C# libraries and language spec.

 

Now you need to decide whether Dots or C++ is more user-friendly.

I worked with both languages and I disagree with you.
C# lacks certain C++ features which you'd want for large codebases. We've discussed them 10 pages prior to this point.

I do agree with your sentiment regarding dots possibly being the wrong path, however.
-------

Feels like the thread ran its course. Lots of insightful comments at first pages, not sure about insights now.

 

Getting stuff done is always right anyway, no matter the method used

 

refering to something 10 pages ago without link ugh.
You meant const correctness?? It's not that kind of killer feature... especially not comparing the vast library and tooling C# provides I mean there is simply no tool in C++ like Resharper.... you really should want C# over some kind of C++ template hell. if you care at all about productivity.

One post on this forum comes to mind about this topic:
https://forum.unity.com/threads/do-...ll-a-viable-career.835483/page-2#post-5548558

 

Guess storage came back to be a real thing on game requirements. Zbrush models? No maps? Yeah. Full ps5 storage (825gb) for 3min gameplay. Still very beautiful. Hope unity still offers good option for indies like me.

 

You could store 256 million verticles in a 8 K texture, and because of their GI you don't need any other texture maps than Albedo, no normal no AO, so in the end storage might be less. I think they talked about importing those big models into the engine, not resulting game.

 

You are saying like that's some sort of issue. Blueprints aren't replacement of a programming. It is a simple tool for a simple scripting that can be done by anyone and your pictures are just proving that.

90% of what is done in blueprints in professional projects doesn't look even close to what you are posting. Most of the time they are simple nodes for level streaming, animations, cutscenes, dialogues, UI and simple puzzles.

 

Also calls to a delegates and lambdas. If you have a delegate and assign a class method that matches signature, last time I checked it spawns an anonymous calss instance via newobj.

This is correct, although Unreal disabling C++ exceptions by default sorta throws wrench into RAII. It still works, but half of the point was that RAII also handles stack unwind.

It is a killer feature, though. The point of const correctness is eliminating side effects, which is approach popular in functional languages, actually. C# does not have an equialvent, and that's why it made immutability popular, however, immutability in C# means spawning of garbage, and that's a problem in unity due to garbage collector issue.

Basically, there's a difference between productivity at low scale, and productivity at high scale.
The most productive language for small scale (when you need to automate things very quickly)... is Python. If you want to scrape some json, butcher it and spew it back out in transformed form, nothing beats Python. Not C++, Not C#, Not Common Lisp. Nothing. It is a great duck tape language.

However. When the size of your project grows, Python becomes more and more horrible, because the ease of use that helps you at small scale turns into bug-introducing landmines at large scale. For example, Python has no access control in classes, allows programmer to add new fields to the class at runtime (!), has no static type checking, relies on duck typing..

Spoiler

And in the end at a large project you'll end in a situation where any piece of code can potentially wreck any other piece of code, library apis address classes and variables by their name passed as a string, and some function can accept a class, but also can accept a dictionary with methods.

It is a complete insanity and barely manageable.

On other hand of the spectrum we have functional languages, which were made by people who realized problems of unlimited access to everything, bugs it can introduce, and therefore decided to kill all side effects in existence. This results in hardocre approaches, like, for example, declaring that reassignment of variable values is for the weak. No "x = 1; x += 1;" for you, because that creates state, and state is evil as it encourages side effects which introduce bugs. This, theoretically, makes functional languages incredibly suitable for multithreaded programming, because lack of state makes multithreaded bugs impossible. However, this is very hardcore, sometimes to degree of being impractical, because state is a natural representation of many objects and situations.

Now, getting back to C++ and C#. C++ lies closer to Functional languages when it comes to bug prevention. You can have a program that is nearly on FP level bulletproof, by methodically enforcing thigns like const correctness, RAII, Rule of THree/Five/Zero and so on. However, this is opt-in, and not forced onto you. C++ idea is to borrow every language construct in existence, you see, so if you need something, it is suppoed to be there. So if you need to shut down every way of introducing a bug, you can do it.

C#, however, lies closer to Python. While it has compile time static type checking, and does not allow programmer do bizzare things like adding fields to classes on the fly, it lacks FP level bug prevention features of C++. You can't tell a method that it is not allowed to change class state, for example. Because C# is used by clever folks, they decided to use Immutability to achieve effect comparable to const correctness, but...

Because we're using C# in unity, because unity has old GC, because it will probably take few more milleniums to make unity migrate to a better GC, you don't want to use this kind of approach in your game, all the while Unreal engine has all the power of const correctness avilable, despite developers trying to make things more fun by compiling the engine with exceptions disabled.

That's the rough idea of it.

I have sufficient understanding of templates, and C++ has access to more libraries than C# does. Every C or C++ library in existence is yours. C# can talk to C through interop, but not C++ (because name mangling). Additionally C++ seems to be picking up evolution speed.as time goes. You'll be getting modules in C++2020, concepts and so on. Basically, C++ provides great deal of stability and I prefer that to having access to resharper.

 

Actually Jetbrains has recently released their Rider for Unreal Engine Preview.

https://www.reddit.com/r/unrealengine/comments/g633hk/rider_for_unreal_engine_public_preview/

I've been testing this IDE out myself, and it really makes C++ almost feel like a scripting language. Although the intellisense does take a little while to load when you first open the solution.

You can sign up for the preview and get a evaluation license that'll last until February 2021.

 

Yes. Where are the city building simulators? Where are the 4X turn-based and real-time strategy games?

 

Discussing this with you is like beating a dead horse, but I will say one last thing..

Do you know about the stack memory? About value/reference types?
And if you allocate things once, and if your code has no boxing. It's a non-issue at all.
Actor models are heavily tied on immutability across different languages including C#.
And it never was an issue there....

Yes, and this is where C++ falls apart with all the backward compatibility and legacy burden.

 

People can't agree you can shoot arrow on the right of the bow with evidence, what makes you think people will agree on highly contextual ambiguous matter?

 

C# (as well as many other programming languages) can talk with C++ directly through pointers passing, bypassing symbol table entirely, but a binary representation of parameter types should be equivalent between the two as with regular interop.

 

They are positioned by Blueprint proponents as replacement to programming. "You can make a game without coding!", and the like. And the examples I posted were written by someone for practical purpose, including spaghetti from hell one.

I'm perfectly aware that they're a simple tool, which is why I called them a crutch. Additionally, the engine forces their use in a rather heavy handed fashion.

You'll need to write glue. That can be very annoying. On top of that the C++ side of API has to be designed to be addressable from external languages from the start.

For example, interoperating with Boost will be very fun, as more than one library is header-only.

 

Not ASE but many other visual editors attempted this in the past and where quite successful. One of those where a visual editor that pumped cs code that can be edited in the graph or through code (or both). Can't remember his name though (something with N). It's now sadly deprecated but that tool was quite powerful. I remember having my designer who have no idea how write a single line of code gluing Unity APIs and calls visually and me optimizing all that through code later on (on the same file).
The one made by Holmer also did this but got quickly abandoned.
Tools are never perfect and will never be perfect unless you write the tools yourself (and even so), you chose the one that help you obtain your desired results the quicker.

 

For what's worth.

1. There's Resharper C++ available for some time. It comes with UE4-specific features, super awesome.
https://www.jetbrains.com/resharper-cpp/

2. It's not like the first plug-in like that for C++. Visual Assist is a golden standard for C++ programmers at least for a decade. Used with in-house engines commonly. It also comes with UE4-specific features. Although R++ beats it

3. You rarely use pure C++ while programming for UE4. Most of the time you actually write "Unreal C++" which is closer to C# than pure C++ if speaking about ease of programming. All basic things are provided: reflection, garbage collection, easy exposing stuff to scripts (blueprints or Python for editor scripting). Basic types come from Unreal's core not some C++ libs. Strings operations, math, FVector, FRotator (quaternion), FTransform and... plenty of stuff. This is the entire C++ framework tailored for games.

4. Compilation times are demonized. I got bigger beef with Unity where I had to wait half of a minute to start a game in the editor. Or much longer if someone messed up code or asset dependencies. It's quite difficult to mess it in UE4, launching game is usually instant.
LiveCoding works like magic often recompile in a few seconds. Super-stable, even when the game in the editor is running. Yes, this doesn't work with changing anything in the header - no such magic is available. Well, in practice I don't restart editor so often it bothers me. If someone you'd need to do it every 5 minutes - well, it's quite unorganized coding. If using blueprints and editor tools, obviously. No project just uses C++, blueprints are awesome for rapid/dirty prototyping. Better than C# since you have your objects/components and code operating on it in a single asset.

5. Custom scripting language would be very nice, but it's more workflow improvement, so programmers and non-programmers could finally meet.
It would be most useful for non-programmer minds who don't even want to learn what is const correctness or CPU cache. It would be best for scripting small features/systems, probably would be most used by technical designers (and loved by them). The gap between visual scripting for everybody and regular programming language scares a lot of people. Especially that starting with C++ is quite slow and requires to think about code architecture. To be honest, I couldn't ever understand if someone doesn't want to learn the language because it's difficult to start. After all, you gonna use a given engine for years

One of the most annoying things that remain in Unreal C++ are compiler/linker error messages which aren't very clear, but you can easily solve it by dropping questions on Unreal Slackers discord. Although with support of extension like R++ you not gonna often miss include or another common mistake.
General tooling, build toolchain - it's handled by Epic nicely.

It's more like a psychological problem with C++ than the real one. Official docs are poor and not designed for non-programmers, true. But the internet doesn't end on unrealengine.com

You can make RTS game or 4X with blueprints. There are some disadvantages to it, to much time spent on cable management. Complex algorithms and math would be terrible to do with visual scripting. And not everything can be exposed to the blueprint.
The bigger problem is that blueprints are blackbox. You can read tooltip for function, but you won't understand the engine code behind it. Even if you can jump to the source code with double click...
Also, you won't write a custom editor with blueprints. And this is what provides a huge workflow boost for teams, custom tooling. Which is relatively easy to write since you have full source code access, you can even copy-paste entire modules or group of classes from the engine and quickly set up your own tool. Obviously, you should clean that up.

And access to the engine's source code is one thing you're forgetting to discuss here. You don't need to be C++ guru, but still, you would able to read the entire engine code, understand every single method! You can fully debug your game.
It's easy to build your own engine from scratch, apply fixes from dev branches months prior to the next engine release. Obviously, you can change small things in the engine that you need badly. After all, it's all written in the same Unreal C++ as your game code. It saves an insane amount of time and frustration.
And you can ask questions about the engine's source online since everyone has access to it.

I hope this adds some valuable information for you. I don't care which engine you use/love, but it's always better to understand other technologies

 

I have over three decades of programming experience, so I am coming at this entirely as a lifelong programmer. I looked at Blueprint when UE4.0 was first released. I could see how Blueprint would be very empowering for an artist. As a lifelong programmer, Blueprint felt extremely constraining to me. I messed around with it some in a few prototypes, but I generally hated it.

If I have to use Blueprint to "code", then you have to use MS Paint to generate art. If you'd rather use Adobe Photoshop, then you can easily understand why I prefer a real solution like C# instead of Blueprint.

 

This about sums up the discussion thus far

 

Supposedly, there are some hardware tweaks that Sony had done to the AMD APU specifically for the PS5 to give it enough storage IO performance to directly stream assets from its NVMe storage. So more than simply installing the NVMe drive.

And a single NVMe style SSD will offer better performance than a RAID 0 array of SATA SSD, if that is what you were asking about. SATA is a bottleneck.