Blueprints are fine. You can write most of your game in BP and get the performance you want. The issue is not what (BP) is used but how. It's very easy to pull too much into your BP, it's too easy to rely on tick and it's much easier to recalculate things than it is to cash them. It's not that BPs can't be used extensively it's that ergonomics are not there and the path of least resistance is often suboptimal. This is compounded by two banes of game development: waiting with performance monitoring for too long and lack of investment in automated testing. By the time you start looking at performance issues you're typically down to only one option: rewriting parts of your BPs in C++. Not because logic couldn't be in BPs but because untangling wacky dependencies in BP would be riskier than doing some massaging in C++. MASS and PCG aren't solving these issues as they either exist for different use cases than BP are used (MASS) or require designing entire parts of the game around them from ground up (PCG) and can't be used during development as a crutch.
In UE5 (BTW, HLOD can mean many different things in UE) when you're using world partition, HLOD is a massive, complex system that interacts with multiple pieces of engine in non-obvious ways. It's under-documented and really hard to use. Undocumented and non-obvious is Unreal's unifying thread.
It sounds simple in principle but like I said above: Unreal is massive, complex, and very few people understand how different things interact. And more often than not you don't need to modify the engine. What you need is understanding of a subsystem that's poorly documented or even hard to discover (there are tons of things UE can do but very few people know exist). Undocumented and non-obvious.
Your blind spot seems to be that the same issues pop up in non-UE games. It's just (like many pointed before) that there are fewer non-UE games on the market. You're ignoring your priors. It's tempting to claim that games wouldn't have similar issues if only developers used different tech. But that assumes that UE is used despite its clear problems for seemingly no gain. Surely you don't think that developers are blind to solution this obvious.
Yup. Streaming the content in and performing gameplay-related logic (which is typically single-threaded) is what chokes most games.
Before you profile anything you need to know what is there for you to use. There are so many things UE delivers out of the box that are hidden. A lot depends on tribal knowledge. If you work with sufficiently many UE experts you will absorb knowledge through osmosis over time. But boy, is Epic really bad at educating about their engine. Most videos and articles are extremely surface level and fall apart the moment you start working on a semi-complex project. It looks great when you deliver new feature and have a flashy hour long presentation. But it all falls apart when you start using it. Suddenly you're on your own and have to build a game while trying to catch up with development Epic did on a feature. So read that code like a champ because that's the only way to learn how things work. :|
"Just" is doing a lot of heavy lifting here. Epic is, in my view, pretty terrible with educational material. What they do
feels sufficient if you don't use their engine. But isn't as soon as you do.
I intended to quote this in disagreement but this really depends if we're talking about making game (then I disagree) or learning UE (in which case I agree). Diving into engine is often the only valid way to build expertise. Good luck finding the time for that while you're also building a game.
Yes, developers are lazy and don't care about anything.
If you can't back your claim with data, why would they? I mean, this is as helpful as "could you please write fewer bugs? kthxbye".
