Unreal Engine 5, [UE5 Developer Availability 2022-04-05]

[Remij]

Obviously not something you should forgive but the drive-bys on Unreal are getting tiresome. You literally just used the opposite logic in the DF thread regarding DLSS and PSSR (it must be the game's fault, despite the fact that those techniques are way more black box and have way smaller API surfaces than something like a game engine).

There's obviously plenty of games at this point that run well without issues on UE5 that are way more complicated that DQ3. There's also plenty of games that run like shit that don't use Unreal. You're not considering the prior probability (i.e. that a large number of games use Unreal these days), and letting your emotional response just pick a target that can consistently blame rather than the reality of lots of games have lots of different issues.

... and of course so am I. As I like to remind myself and everyone, it's obviously fine to call out issues in games. Pattern matching can be useful although it's worth reminding ourselves that it's a better debugging tool than root cause tool. The place where people tend to overstep their bounds is when they confidently claim a root cause for issues they don't really understand.

Ultimately consumers are not the customers of Unreal Engine (outside some stuff like UEFN, which blurs the line a bit but also comes with significant guardrails). Game developers are the customers of UE, and consumers are customers of the game developers. At B3D we like to break things down into the tech which is fantastic, but when it starts to stray into misdirected internet rage it just distracts from that discussion. I realize this is what gets clicks for the tech reviewers, but we don't really need to bring it here as well.

IMO the more interesting discussion (if people even want to have it) is what sorts of pitfalls do folks potentially run into that causes these kinds of issues that other people (ex. The Finals, Satisfactory, Hellblade, ...) are able to avoid. In reality it's gonna be a ton of different things, but naively I'd guess that the ease of use of the engine from the gameplay side is potentially a bit too enticing and can lead people down some bad paths. A common one that has been discussed in quite a few UE talks is relying on blueprints too much, but I'd extend that to the entire actor/component infrastructure. The naive way to do things (treating actors as self-contained blueprints/prototypes and then creating large amounts of them to fill out a world) can lead to significant overhead. This of course has always been an issue even in UE3 and 4, but with people creating larger and more complex worlds it becomes even more important to address. This is of course what MASS and PCG and similar systems (demo'd in CitySample and ElectricDreams among others) tackle in various ways, but really the expectation is that if you are going to create a large scene with tons of objects you're going to need to make appropriate infrastructure in the game itself, based on these frameworks or otherwise. Satisfactory is a great example of handling tons of objects, but they certainly don't have a blueprint ticking for every item on a conveyor belt...

HLOD is another area of the engine where I suspect people get tripped up on because it is both very necessary once you have worlds of certain sizes, but also a bit of a bespoke workflow. Obviously engine improvements can help here and they do continually come, but I suspect some folks effectively get a bit over their heads with respect to their ambitions.

I don't feel like I'm applying different logic regarding PSSR in the other thread. If PSSR consistently had the same issues for the next 3 years game after game, you bet your butt I'd be making a similar post about it. PSSR is brand new, I can still give it the benefit of the doubt because one bad implementation doesn't mean the entire thing is bad. Look at FSR... everybody shits on FSR consistently. At this point we don't even need to see a game to make an educated guess of which issues FSR is going to have, because it's the same thing time after time. There's like a couple of decent FSR implementations you can count on one hand... and thus it's rightly built up a well deserved negative reputation. There's always exceptions to the rule. I didn't just wake up and decide to hate on Unreal Engine.. I think (or at least hope) you know that I appreciate how incredible aspects of it are.

I'm going to assume the studios of games like The Finals, Hellblade, Satisfactory and so on don't have these predicable issues because they have people that rewrote rather large parts of the engine to perform how they need it to perform? I know Embark Studios have some very highly regarded programmers and engineers from the Frostbite days.

PSSR and DLSS might be black boxes, but there's nothing stopping developers from doing their own reconstruction tech for what works best for their game, right? And yet they will do the typical thing and implement one of the existing ones almost guaranteed. I mean why not, it's right there. I'm not saying its easy or even feasible for them to do it better on their own.. and so the same thing happens when it comes to engines. My way of thinking is that as a baseline it shouldn't have these obvious repeatable issues, especially in games like DQ3 which looks like a PS3 gen game. I'm not asking for much here. It's extremely frustrating. If guy A sells a car to guy B and it's a lemon, and so then he slaps on a fresh coat a paint and sells it to me.. it doesn't make it ok for guy A to have sold the car to guy B in such a way in the first place. Obviously guy A isn't going to give a damn because he already made his sale.. but in the case of Unreal Engine and how it's monetized your customer's success is ultimately what decides how successful you are as an engine, and bad implementations reflects back on the engine as well, unfortunately.

I definitely agree that discussing why these things might be happening is far more interesting than just having someone complain that they are over and over again. I definitely appreciate any insight you or others can give.. I'm always trying to understand it better.

 

[Scott_Arm]

...

I'm going to assume the studios of games like The Finals, Hellblade, Satisfactory and so on don't have these predicable issues because they have people that rewrote rather large parts of the engine to perform how they need it to perform? I know Embark Studios have some very highly regarded programmers and engineers from the Frostbite days.

...

But isn't this every engine? You work within its limitations, or you alter the parts of the engine to support what you're trying to do? When Horizon Forbidden West comes out, that includes upgrades to Decima that are tailored to the game they're trying to make.

So if you're a developer working in UE5, you should probably make sure the engine can handle what you're trying to do. If it doesn't you can alter your game or alter the engine.

 

[Remij]

But isn't this every engine? You work within its limitations, or you alter the parts of the engine to support what you're trying to do? When Horizon Forbidden West comes out, that includes upgrades to Decima that are tailored to the game they're trying to make.

So if you're a developer working in UE5, you should probably make sure the engine can handle what you're trying to do. If it doesn't you can alter your game or alter the engine.

Sure, but how many times must I stress that the game I referenced is not ambitious in the slightest. This should not be a game that is taxing the engine so much that we're having issues like this. This is not a UE5 game with the latest tech..

 

[trinibwoy]

Sure, but how many times must I stress that the game I referenced is not ambitious in the slightest. This should not be a game that is taxing the engine so much that we're having issues like this. This is not a UE5 game with the latest tech..

It may not look ambitious on the surface but we don’t know if the developers are misusing the engine in non-obvious ways to the end user. I think there’s enough evidence of consistent issues to support criticism of UE5 but we can’t know for sure that it’s the engine’s fault every time. I think that’s what Andrew is getting at.

 

[Remij]

It may not look ambitious on the surface but we don’t know if the developers are misusing the engine in non-obvious ways to the end user. I think there’s enough evidence of consistent issues to support criticism of UE5 but we can’t know for sure that it’s the engine’s fault every time. I think that’s what Andrew is getting at.

Well really then what CAN consumers complain about? I simply said I'm starting to hate the engine.. whether that's because developers are failing to utilize it properly or whether it's an engine issue itself.. it's a common thread that is happening over and over again.

 

[Scott_Arm]

Well really then what CAN consumers complain about? I simply said I'm starting to hate the engine.. whether that's because developers are failing to utilize it properly or whether it's an engine issue itself.. it's a common thread that is happening over and over again.

Ultimately it's the developer that's selling you the game.

 

[Remij]

Ultimately it's the developer that's selling you the game.

Yes, typically the developers of Unreal Engine games. But I'll leave it at that. I get it.

 

[DavidGraham]

There's obviously plenty of games at this point that run well without issues on UE5

Not that plenty though, let's be real here. It's the exception to the rule, not the norm. The norm has been that since UE4, any UE4 or UE5 title is subject to suffer from major stuttering issues, Epic bears the responsibility of that reputation, they let UE4 in that sorry state for the entirety of it's lifetime, hell UE4 continues to be bad to this day despite many new titles still using it, Epic never cared to retroactively fix UE4. Just like they never cared to fix the traversal stutters of UE3, with the end result of UE4 getting released with both types of stutters (traversal and shader).

In UE5, the problems continued because Epic delayed dealing with them in a proper manner until 5.3 or so, and thus most games using UE5 still suffer from them because most are using versions that preceded 5.3. Sadly, UE5.3 and later versions still suffer from the old traversal stutters to this day. Thus, attention needs to be given to fix this one or mitigate it to the largest extent possible.

If we want to learn something from that is that Epic should have acted sooner, should have discovered that most of their titles are suffering these stutters and offered a fix or a way for non experienced developers (which is the majority of their customers) to mitigate them. If it wasn't for the efforts of normal people complaining loudly and organizing their complains in the famous "StutterStrugle" campaign, especially the one organized by DigitalFoundry, none of these stutter issues would have been properly identified, and we would be still blaming our drivers or our hardware for these stutters.

Thankfully, Shader compilation stutter appears to be a mostly solved issue in the latest versions of UE5, but traversal stutter is not, more effort is needed from the community to call them out more, and more effort is needed from Epic to fix or mitigate them sooner than later, so as not to repeat the mistakes of the past. Epic should also consider adding shader compilation mitigations and fixes retroactively to UE4 considering many new games are still using it. That would be a great and responsible move from Epic indeed, and would help turn the bad reputation of UE4 around.

It's as you said, we need to move forward from this, scars and all, learn from the past mistakes and move forward to a brighter future.

relying on blueprints too much .. entire actor/component infrastructure .. HLOD is another area of the engine

Are these issues directly responsible for traversal stutter? I am asking because we appear to not have discovered the specific cause of the issue just yet.

 

[RobertR1]

If blueprints or other tools have a side effect of adding stuttering, then it’s important for Epic to ring fence the feature and limit its usage.

Studios and staff are going to use the path of least resistance to reach an end goal and accept trade offs along the way especially if it leads to less development costs. That’s human nature.

And singling out a handful of games amongst a sea of others with repeated issues puts the onus more on the underlying engine than the studios.

 

[Pjotr]

From my experience with the engine a lot of traversal stutter comes from expensive actor initialization. This is mostly on the developers and not on Epic. There are good tools in unreal to limit how much time UE spends streaming in actors, this can even be done at component graduality. But what UE can not do for you is timeslice an expensive initialization in the constructor or BeginGame call of your actor (I have even seen example of expensive calls beging done on the first tick...). This is something developers need to do them selves. But I'm not surprised this is happening. There are a lot of inexperience programmers jumping onto UE and if you look online there is some very very bad advise being given. There were some games where modders were able to alleviate some of the stutter just by changing some lines in the config files. Just let that sink in because if a modder can do that by just changing some config parameters then the developers really did not understand how the engine is working under the hood.
What Epic can do is educate people better. Another thing is improving their profiling tools, something they are actually doing late in to UE4 and are continuing with UE5.

 

[Shifty Geezer]

That's where UE has become a victim of its own success. I'm seeing lots of pretty Indies getting attention where the engine is doing all the work. The more the engine does, the less the devs do and then the less they become capable of doing. It's like kids using calculators and losing the ability to do mental maths, and now using AI apps to answer questions for them and not knowing maths at all. Or getting ChatGPT to write their essays and becoming incapable of expressing themselves. The more we rely on tools, the more dependent we become and the less capable we are of handling their deficiencies. I think every man and his dog is waiting to AI to write UE code for them so they don't have to bother, at which point the issues of inefficient and unoptimised code will probably increase.

 

[Scott_Arm]

You guys have to realize there's definitely value in having an engine that can allow very inexperienced devs to make a game and publish it. So yes, people can abuse certain features of the engine. But do you really want to limit the engine itself so that a huge swath of people struggle to make games, all in the name of eliminating traversal stutter and some frame pacing issues?

Let me put it this way, I'd rather play Sifu, which is a UE game that launched with traversal/loading stutter and somewhat poor cpu performance, than some hand-holding ultra-generic open-world adventure game that runs perfectly smoothly.

 

[Scott_Arm]

That's where UE has become a victim of its own success. I'm seeing lots of pretty Indies getting attention where the engine is doing all the work. The more the engine does, the less the devs do and then the less they become capable of doing. It's like kids using calculators and losing the ability to do mental maths, and now using AI apps to answer questions for them and not knowing maths at all. Or getting ChatGPT to write their essays and becoming incapable of expressing themselves. The more we rely on tools, the more dependent we become and the less capable we are of handling their deficiencies. I think every man and his dog is waiting to AI to write UE code for them so they don't have to bother, at which point the issues of inefficient and unoptimised code will probably increase.

I think UE and Unity are a good gateway for people to get interested in making games, which could lead them down the path of making their own little game from scratch or their own little game engine from scratch. Honestly a lot of the people that use UE and Unity would just quit making games altogether if they lost access to them, because they never had an interest in making a game "engine." The subset of people that want to build that kind of technical knowledge is very small, and if there were no off-the-shelf engines the number of people making games would be much much much smaller.

It'd be like saying we need to put guardrails on the python programming language because there are too many bad programmers. It would be absolutely stupid to restrict or limit python in some way. The problem is just educating people on how to do it better. But there are always going to be people that shoot themselves in the foot with a nail gun.

 

[Shifty Geezer]

I don't think anyone's offering a 'solution'. It's just observations. As things become easier, they open up to more people which will inevitably reduce overall quality, particularly in a competitive space where people want to minimise costs if there's no clear benefit to working harder for better results. Given any game with stutters, how many sales have they lost because of that? What's the dollar value of training developers to approach development in a different, more expensive fashion to eliminate such glitches?

I'm guessing it's hard to justify as a business expense which is probably why developers don't bother.

There's no solution. It's just a direction humanity is headed. The take home really being it's the devs' fault, not UE's, for not using the tool optimally, but the devs are being swayed by commercial factors, which is the consumers' fault, but they haven't alternative options, so it's the market's fault, but that's only operating according to the economic principles its inherited, so its society's fault, but society is just following on from the trajectory set by history, so its our ancestors fault, but they couldn't know any better...blame evolution?

¯\_(ツ)_/¯

Just discussing points. As it is, it seems the only real solution is Epic finding a way to improve UE, or that AI taking over so everyone can make their own game with just a prompt and hope to get rich from it.

The technical discussion of UE just needs to identify what UE does, what it can do, what devs can do, and how issues can be addressed. Whether they ever are or not isn't really in the scope of this forum except where an issue can be categorically proven a fault with the engine. Simply, "this game sucks; get your act together Epic," ignores all the above complexities of how and why games get made and it's that sort of reductionist argument that keeps reappearing in this discussion without it really having anywhere to go.

I think it'd be nice to draw a line under that and get more specific and technical about UE results without a blame game.

 

[Andrew Lauritzen]

From my experience with the engine a lot of traversal stutter comes from expensive actor initialization. This is mostly on the developers and not on Epic. There are good tools in unreal to limit how much time UE spends streaming in actors, this can even be done at component graduality. But what UE can not do for you is timeslice an expensive initialization in the constructor or BeginGame call of your actor (I have even seen example of expensive calls beging done on the first tick...). This is something developers need to do them selves. But I'm not surprised this is happening. There are a lot of inexperience programmers jumping onto UE and if you look online there is some very very bad advise being given. There were some games where modders were able to alleviate some of the stutter just by changing some lines in the config files. Just let that sink in because if a modder can do that by just changing some config parameters then the developers really did not understand how the engine is working under the hood.
What Epic can do is educate people better. Another thing is improving their profiling tools, something they are actually doing late in to UE4 and are continuing with UE5.

Was going to post a longer direct reply but this and @Shifty Geezer 's replies summarize things better than I could have said it.

Yes gameplay code and actor/component stuff is a big part of what typically produces stutters (although of course it's never one thing). Yes education here is very important and definitely needs to be done better. Engine improvements can help too but only to a point. Folks have to realize that there's not some smooth division between "engine" and "game" code in Unreal... I can go make a single blueprint or - as noted - BeginGame or Tick constructor or similar and ruin the entire performance of the game. There's nothing sandboxed or virtualized about game code in Unreal because fundamentally it is still designed with the idea that it is a toolset for game developers. Even the notion that "games that work well have replaced parts of the engine" is kind of absurd... you are *meant* to write big chunks of code in your game and use the pieces of the engine that makes sense for your game. No one would claim that you can/should make - for instance - a complex game entirely in blueprints and have it perform well; in fact there are many presentations and documentation to the contrary.

When you look at UEFN and Verse and all that side you can get an idea of what differences to design (and power!) happen when you actually need to sandbox things a little bit for security, compatibility and performance.

And yes, I do think a big part of the "then why do I see so many bad Unreal games" is what I mentioned before - prior probability. Many games you play and a huge % of the ones made by amateurs are going to use Unreal. It's like saying "Steam is bad because most games on Steam are bad" or "most of the songs on Spotify are bad"... Steam/Spotify are just platforms that have some great stuff, and lots of absolute trash that someone made in a day in their bedrooms (often in Unreal...). Or to continue the music example, everything made in Reaper/Cakewalk/Bandlab/GarageBand is bad. Obviously that's a ridiculous notion and it's more because those are the cheap/free ones that amateurs use, but you can make top quality professional music in any of them.

As Shifty noted, due to the graphics side of things in Unreal, bedroom project games - often without a single programmer on the team - are getting a lot of media attention that they never would have in the past. I do think there's pros and cons to this. Unity has had this problem a lot since on top of the above factors they (used to?) force all of these cheaper license games to put the Unity logo on them, whereas full polished games with the professional license don't have to.

So yeah again I think the discussion of the pitfalls people run into when making games in Unreal is a great topic for the thread (although there's a lot more specific discussions of that nature on Unreal discord/reddit/etc if people are interested) if people are curious, but it's going to get fairly technical and speculative. I agree that better education and tooling is *always* going to be useful, but I will call out that Unreal Insights is actually getting quite good... to the point that we use it a fair bit internally when doing CPU work. Stutters of the nature discussed here are almost always CPU issues, and luckily there are a myriad of tools for profiling CPU code at this point, but having the one click live profiling (across any of the platforms) in Insights is really convenient.

 

[Andrew Lauritzen]

You guys have to realize there's definitely value in having an engine that can allow very inexperienced devs to make a game and publish it. So yes, people can abuse certain features of the engine. But do you really want to limit the engine itself so that a huge swath of people struggle to make games, all in the name of eliminating traversal stutter and some frame pacing issues?

Let me put it this way, I'd rather play Sifu, which is a UE game that launched with traversal/loading stutter and somewhat poor cpu performance, than some hand-holding ultra-generic open-world adventure game that runs perfectly smoothly.

Agreed. We've seen a long history of new game ideas or entire genres starting with janky versions in Flash or similar and then getting optimized or rewritten in a different language/engine later when it becomes popular. You could argue stuff like roblox and UEFN and the like is a place where people can do those kinds of prototypes, but they are perhaps too limited for certain genres currently. I would be highly opposed to any sort of gatekeeping of the full Unreal Engine to professionals even if the downside means that there's going to be lots of bad/unpolished stuff made in Unreal. If the game is bad, just and move on to one of the zillion other games.

 

[tuna]

I'm guessing it's hard to justify as a business expense which is probably why developers don't bother.

I think it is more that developers simple don't know and don't care enough to become more knowledgeable. Take the latest Monkey Ball where they used the default Unity camera update (50 fps) on a 60 fps game. Maybe they don't see it, and if they see it they get used to it after a while.

 

[cwjs]

Are these issues directly responsible for traversal stutter? I am asking because we appear to not have discovered the specific cause of the issue just yet.

Naieve gameplay code patterns are a likely culprit, sure, but ultimately almost any hollistic performance problem is going to be multicausal. Multicausal issues are hard or impossible to diagnose or find real patterns in by looking at a variety of games with "similar" hitching. This is where blaming an engine is misguided vs complaining about a specific, narrow technology like a reconstruction technique -- if reconstruction has artifacts, is blurry, is said by developers to have significant performance overhead, etc, then sure there are certainly multiple factors (what were the inputs, what resolutions were they, what kind of content was fed in) but ultimately there is something resembling a single point of failure across multiple games.

If a game is just hollistically performing bad, hitching, etc, there tend to be a lot of non-optimal things throughout the games and their content. It's just not as productive to speculate unless you have your hands on a profliler or a very narrow bug repro.

 

[Shifty Geezer]

I think it is more that developers simple don't know and don't care enough to become more knowledgeable.

It's one and the same thing I think. For the amateur, they just want to make their game and spend enough time learning the basic. For the pro...they just want to make their game an get it out the door! As I mentioned in the retro thread about the Sega Saturn, it seems it's better basic tools than PS2 gave developers a low barrier to entry so they used those tools and didn't maximise the hardware. On PS2, it was hard to do anything so you had to think about it, and that would naturally engage the thought processes into optimisation, because you were fully aware what the engine and hardware was doing.

If you have a game to make to earn a paycheque, and there's a tool that let's you create that and ship it in 6 months, why bother spending longing to learn the details? If that'll double your money, that makes perfect sense. If you can't correlate and gain to the cost, it's much harder. So I think developers not knowing and not caring is because firstly they don't have to in order to get the basics going, and then can't rationalise caring more.

I guess, what would it take to make devs know better and care enough? The smaller the developer, the less engagement. The bigger the studio, quite possibly the more pressure from the business side and the publisher and less opportunity; you simply can't afford to make a better game as the ROI is negative.

 

[QPlayer]

South of Midnight runs on UE4, I was surprised by that. I think it's among the best in terms of graphics and they targeted 60 FPS with it on Series X, so presumably in high resolution.

It will be a nice slap in the face to low-res console ports of UE5 games.