Incline Unreal Engine 5: final nail of Unity's coffin?

[Immortal]

The weirdest thing about Unity is how it makes my PC's temperature rise more than games in other engines.
Granted, my PC is a bit aged now (CPU from 2011, but the GPU is from 2019 so pretty new) but it can run most games on medium to high settings. I'm able to play Conan Exiles, Dishonored 2, Shadow of the Tomb Raider on high graphics settings and my PC stays on a reasonable temperature.
But when I play something made in Unity, even when the game's visuals are way less demanding than those AAA games mentioned before, my CPU fans go into overdrive and when I touch my case I can feel it getting warmer.
Why?
What the fuck is Unity doing?
Why does it tax my hardware more than visually more demanding games?
It makes no sense.

Noticed it the most when playing Valheim and Conan Exiles with friends. Conan Exiles runs on UE4 and has a high visual fidelity, and I can run around in that game for hours without my PC complaining. Meanwhile, when we're playing Valheim, my PC starts sounding like a jet engine and the case is getting hot to the touch after a mere 30 minutes of sailing through the ocean - for some reason the water in this game is particularly bad.

I also noticed it in Railway Empire, a tycoon game that shouldn't be very taxing at all... and yet it makes my fans go brrrrrrrrrrrrrrrrrrrr. Even though it doesn't have anything graphically demanding about it, nor are the CPU calculations any more complex than in the strategy games I like to play (Crusader Kings, Total War).

And I've heard from others too that Unity games are unusually taxing on their hardware compared to games in other engines. What gives?

It is a single-threaded piece of software that runs as fast as possible.

Mehhh.

Most Unity Games are just poorly made. the IL2CPP does a fairly okay job at writing out Optimized Binaries and Unreal's Blueprint is actually about 10x slower than native C++ (Last I heard) because of the overhead. The issue with Unity is like J1M sorta said, many developers just don't code well and with the low barrier to access anyone can write a game with just a very thin veneer understanding of programming.. causing Frame() to spend years chugging on stupid things and delegation rarely used at all.

If you start writing Unity games utilizing things like DOTS properly in the new SRP's with Adressables you can squeeze pretty great performance with cached assets and a-sync execution of frame chugging operations.

I would say Yes Unreal overall is the stronger engine especially when it comes to GI / Lumen. HDRP is close but not there yet..

That Auto-LODing stuff they are doing with Triangles looks pretty amazing too - although 100 gigs for a empty desert stuffed with 4gig Quixel textures seems a bit gluttonous to me. lol.


HOWEVER..

Conan Exiles...? Really? That game is so horribly optimized server side.. Open it up in their DevKit.. look at how they structured their blueprint code and spend time looking at their server infrastructure - it takes about an hour to find out why a 32 Core Server can't run this game for shit the minute someone plops down 20 foundations. Pure joke.

 

[The Avatar]

Splitting the graphics pipeline into two was such a bad move. Unity finally has decals! But wait, it's only in HDRP. Need some RTGI? Realt-time volumetric fog? Skin shading? Only in HDRP.

So why not just use HDRP? That would work great, except if you want to port your game to Nintendo Switch/Android/iOS where HDRP is not supported. You can't just change pipelines without everything breaking.

Unreal Engine does scalability correctly by allowing the developer to determine which features that want on or off for a given platform. Something like Obsidians Unreal Engine -powered Outer Worlds Switch port would not have been possible in Unity.

 

[RobotSquirrel]

So why not just use HDRP?

because its completely overkill for what the majority of Unity projects including mine require. But I agree that splitting the renders was a bad idea.
We should be using a unified renderer that can be scaled back when needed so that compatibility is better for everyone. The only reason I won't use HDRP is because I'm worried about getting backed into a wall with workflows because it has a pretty difficult workflow one that I struggle to see the advantages of outside of visual.

 

[Wunderbar]

Discuss!

Sawyer, back when Obsidian was independent: "wow skyrim has the same engine bugs that were present in fallout 3 gamebryo"
Sawyer, after Obsidian and Bethesda got bought by MS: "this new unreal feature is not actually new, it was already implemented in Creation engine by the way"

 

[rusty_shackleford]

Splitting the graphics pipeline into two was such a bad move. Unity finally has decals! But wait, it's only in HDRP. Need some RTGI? Realt-time volumetric fog? Skin shading? Only in HDRP.

So why not just use HDRP? That would work great, except if you want to port your game to Nintendo Switch/Android/iOS where HDRP is not supported. You can't just change pipelines without everything breaking.

Unreal Engine does scalability correctly by allowing the developer to determine which features that want on or off for a given platform. Something like Obsidians Unreal Engine -powered Outer Worlds Switch port would not have been possible in Unity.

SRP is a perfect example of a Unityism.
Replace something that works with something that is unfinished, doesn't offer the same features, and has frequent breaking changes.
Another good one was when they deprecated enlighten(in 2019) without a replacement at all stating they would develop a replacement at a later date. It has been over two years and there still hasn't been a replacement, with the most recent update stating that it won't be coming this year.

 

[J1M]

Discuss!

I don't know why he's making a big deal about this. Most engines have supported level streaming for ages. World Machine which supported Unreal always allowed you to do this on the art pipeline end.
The only engine I know that doesn't really support continuous streaming is Godot and even then you can still just do the older method of making a giant optimised low tricount mesh.

But I mean also its kinda silly that you'd market Open World to indie devs anyway. There's ways to do level streaming as an effect to make the game world look bigger but you'd never want to use it as content distribution like how Ubisoft or Bethesda uses it.

Also there's only one point where he's right on the Hex thing which is with Geodesic Streaming ie. Streaming on a globe. But you'll end up with problems at the poles still. Otherwise I see Hexes being more of an issue for designing levels because you now have to deal with 6 borders instead of the usual 4 which makes fixing seams a bigger problem.

You need to look at this advertisement as something aimed at developers, not gamers. The advantage here is that multiple people can work on an open world map at the same time, speeding up the dev process.

 

[RobotSquirrel]

You need to look at this advertisement as something aimed at developers, not gamers.

that's what I was doing with that world machine point. How many gamers you think know what World Machine is?

The advantage here is that multiple people can work on an open world map at the same time, speeding up the dev process.

So basically Scene Fusion. Except its free. I mean cool. But I think people are making a big deal over something that really isn't all that unique. The unique part was First Party and Free.
That's awesome but this isn't some miraculous way of working that Bethesda of all people invented lol. (the idea of streaming off a grid goes back to some of the earliest video games. Specifically flight sims popularised the method a lot).

 

[Bad Sector]

Nothing to discuss, UE was never intended to be used for large open worlds and any attempt at using it for such required custom solutions. Of course the "creation engine"(Bethesda in-house development of the Gamebryo, previously the NetImmerse engine) was able to handle this, it was a main feature of the games it was used to create.

Note that NetImmerse/Gamebryo didn't had any support for seamless open worlds, that was Bethesda's work. Gamebryo added in a later version some support though AFAIK it was after Oblivion was released and Bethesda never used that. In addition Gamebryo wasn't a full complete engine like Unreal or even id Tech, it was a modular framework that provided a foundation and some components that developers could pick and use parts of to build their own engines and was largely oriented towards graphics (in fact it was only about graphics in its earlier versions). A lot of the stuff people associate with "Gamebryo" are actually Bethesda's work.

Also Unreal Engine had support for large world streaming ever since UE3 (you can even find it in UDK from 2009) but it was all done using manually placed "world volumes". AFAIK this isn't an uncommon technique to do world streaming, though it does require additional work from the level designers and/or artists.

And FWIW, Bethesda's engine was also what i though of when i saw that part of the UE5 demo.

Any software engineers to confirm/disprove this? Efficient for what, culling, LODing, memory management, what? Is a bigger hexagon tile size a non-issue here?

Most likely he means more efficient for spatial partitioning so that you do not load/unload unnecessary bits of the world. Not sure if it'll make much of a difference in practice, perhaps if you have dense environment but at that point you'll probably have other issues.

 

[A horse of course]

This isn't particularly new (I remember the same functionality being added to Everquest 2) but it's nice to have all the character creation and animation tools in one place.

 

[Immortal]

Sawyer, back when Obsidian was independent: "wow skyrim has the same engine bugs that were present in fallout 3 gamebryo"
Sawyer, after Obsidian and Bethesda got bought by MS: "this new unreal feature is not actually new, it was already implemented in Creation engine by the way"

This is a bit of a reach.. he's not wrong..
Chunking open space worlds was being done by Minecraft and Bethesda going back literally a decade.

Lumen and Nanites look great.. and Nanites especially will save Artists so much time not caring about LOD's or Poly counts on static meshes anymore but when I saw that chunking tech.. Like even fucking Unity does that with Sub scenes.. lol

Also UE offering Quixel and MetaHuman basically free.. Like they are really bringing it.

Also Unreal Engine had support for large world streaming ever since UE3 (you can even find it in UDK from 2009) but it was all done using manually placed "world volumes". AFAIK this isn't an uncommon technique to do world streaming, though it does require additional work from the level designers and/or artists.

Can you elaborate? World Volumes do you mean streaming in split out world sections whereas now it's done for you?

I'm not really up and up on this tech stack for Unreal.

 

[Bad Sector]

Can you elaborate? World Volumes do you mean streaming in split out world sections whereas now it's done for you?

The way it works (or worked in UDK, i never got too much into UE4 but AFAIK it works in a similar way) is that you have a persistent level which is always loaded and then you have "streaming levels" which are loaded and unloaded on demand. The original way for doing that load/unload was using scripts (via Kismet or whatever) but at some point they also added level streaming volumes which can be used to "automatically" load/unload levels based on the camera position. The idea is roughly this:

• Make a persistent level which has the player start and some BSP geometry
  
• Make one or more streaming levels which are layered on top of the persistent one (you can have them all visible in the same viewport)
• Make streaming volumes and associate them with streaming levels so that whenever the camera is inside a volume to ensure that a streaming level is loaded (and unloaded when it isn't)

Note the catch here: the streaming depends on the camera position meaning that the volume has to extend enough to cover the distance from where the streaming level geometry would be visible.

There is also a slightly different approach where you specify a streaming distance from the level's own origin which is easier to set up but probably harder to get right and can easily stream in a level when it shouldn't be.

BTW note that as streaming levels can overlap and have their load/unload status be controlled via scripting instead of volumes this can also be used to do the "big world changes" part mentioned via data layers, e.g. have a village (or whatever) in two streaming levels - one in its normal state and one in its destroyed state - and use a script to decide which one to load based on some game condition.

 

[Immortal]

BTW note that as streaming levels can overlap and have their load/unload status be controlled via scripting instead of volumes this can also be used to do the "big world changes" part mentioned via data layers, e.g. have a village (or whatever) in two streaming levels - one in its normal state and one in its destroyed state - and use a script to decide which one to load based on some game condition.

This doesn't seem that far off from what they Demo'd though. So not sure what the big hoopdah is.

You need to look at this advertisement as something aimed at developers, not gamers. The advantage here is that multiple people can work on an open world map at the same time, speeding up the dev process.

At the cost of making every single instance of an asset in a world a unique file..
That's certainly one way to manage conflict resolution - just let git do it.

 

[RobotSquirrel]

At the cost of making every single instance of an asset in a world a unique file..

they wouldn't get very far. The Average PC can only muster up about 1,000-2,000 draws before you start seeing issues. That number would dry up quickly if every asset was unique.
Also remember that PBR multiplies the draws per Texture AND Material. So yeah recipe for disaster.

 

[Bad Sector]

This doesn't seem that far off from what they Demo'd though. So not sure what the big hoopdah is.

I think it is mainly better UX and automating some things. And of course chances are they improved some stuff behind the scenes, but overall as someone else said parts of the UE5 demo feel like Unreal finally got features that existed in other engines for quite some time now :-P.

Of course said other engines didn't have to cater to a ton of different types of games like Unreal. At the end of the day when you make an engine for everyone you are making an engine for nobody in particular.

At the cost of making every single instance of an asset in a world a unique file..
That's certainly one way to manage conflict resolution - just let git do it.

Or most likely, Perforce :-P. P4 integration is common in these engines and other engines already do something similar anyway. In the last engines i worked on there was full Perforce integration so that the editor could automatically check out any resources you tried to edit, add new resources in a changelist and you could commit your changes from inside the editor. If any resource was locked because it was checked out by someone else (...which is how conflict resolution is generally handled - by not allowing conflicts :-P) you could see who is from inside the editor (e.g. you'd get a message like "somefile.ext is already checked out by someguyname") so you can send them an IM to unlock it (or not).

 

[Nifft Batuff]

Unreal 5 is the last nail in coffin gaming, in general.

 

[gurugeorge]

A question from an interested observer: one notices tons of really interesting looking plugins for both Unity and Unreal (all sorts of things from animations to foliage generation, destructible buildings, etc., etc.).

Are those sorts of things traps for rubes, or are they the sort of thing you can integrate into games, that developers do often integrate into games (as opposed to building from scratch themselves)? Is it theoretically possible to make a game using a collection of those types of things, or can you only use like one or two before you start to build up intercommunication problems (I've just made that term up ) or overhead problems?

As someone whose knowledge level just about reaches to a bit of .inf or .xml tweaking to make mods work in moddable games, I'm guessing it's a bit like with modding: there are loads of mods that look tempting and cool, but you soon start to find that they don't always play nice together, and you can very quickly get into the weeds trying to make even a half dozen work together smoothly.

I mean I guess the answer is "it depends" (it always is), but I'd be interested to hear what experienced people have to say on the topic.

 

[The Avatar]

A question from an interested observer: one notices tons of really interesting looking plugins for both Unity and Unreal (all sorts of things from animations to foliage generation, destructible buildings, etc., etc.).

Unity has so few features that it's almost impossible not to use plugins for basic features like foliage, splines, decals, serialization, ect. That is their business model- sell the engine for cheap, have people buy stuff from the Asset Store. I don't think it would be a good idea to try and a build a game from just plugins though. Unless it is very simple, you will likely need some basic coding experience to make the core functionality of your game and be the glue that binds all of these different assets together.

 

[Perkel]

Unity has so few features that it's almost impossible not to use plugins for basic features like foliage, splines, decals, serialization, ect. That is their business model- sell the engine for cheap, have people buy stuff from the Asset Store. I don't think it would be a good idea to try and a build a game from just plugins though. Unless it is very simple, you will likely need some basic coding experience to make the core functionality of your game and be the glue that binds all of these different assets together.

True but it is at the same time reason why most of people gravitated toward Unity instead of Unreal leaving mostly AAA and few indies who focused on Unreal while rest was sitting on Unity. Bloat has its price and people were not willing to maintain something they might not even use in game.

And it is not like Unity had huge backing of previous Unity devs. It was Unreal had it to ridicolous point where almost every new game was Unreal at some point. Unity destroyed that advantage in like 5-7 years which also caused Unreal guys to answer with better offers just to compete.

 

[Tacgnol]

A question from an interested observer: one notices tons of really interesting looking plugins for both Unity and Unreal (all sorts of things from animations to foliage generation, destructible buildings, etc., etc.).

Unity has so few features that it's almost impossible not to use plugins for basic features like foliage, splines, decals, serialization, ect. That is their business model- sell the engine for cheap, have people buy stuff from the Asset Store. I don't think it would be a good idea to try and a build a game from just plugins though. Unless it is very simple, you will likely need some basic coding experience to make the core functionality of your game and be the glue that binds all of these different assets together.

One of the issues I find with Unity is a lot of the popular plugins and code snippets on the forums are kind of awful.

Probably explains why a lot of the Unity games have similar issues.

 

[The Avatar]

It was Unreal had it to ridicolous point where almost every new game was Unreal at some point. Unity destroyed that advantage in like 5-7 years which also caused Unreal guys to answer with better offers just to compete.

Unity didn't destroy any of Unreal's market. How many AAA games use Unity? None. To the extent that not as many Unreal games are made today compared to the UE2/UE3 era, that has more to do with a consolidation of big developers making more games in their own in-house engines than Unity doing anything remotely competitive in that space.

 

[Perkel]

Unity didn't destroy any of Unreal's market. How many AAA games use Unity? None. To the extent that not as many Unreal games are made today compared to the UE2/UE3 era, that has more to do with a consolidation of big developers making more games in their own in-house engines than Unity doing anything remotely competitive in that space.

1. Death by thousant cuts is still death. Just because AAA didn't jump on Unity bandwagon doesn't mean Epic didn't lost a lot of developers. Indie scene was complete bloodbath. They went essentially from 95% market to few indies making games. There was Cryengine but somehow Cryengine didn't get many games on it.

2. You are right that consolidation around in-house engines hit Unreal at AAA level but that doesn't explain what happened at indie level. Unity when it started had exactly 0% market share and they ended up with everyone and their mother making games in it from low to low/medium studios. And this was in time when Unreal engine ruled so clearly people fond it better to use.

Moreover it got to point where Epic couldn't just lie down and they had to change how they operate. They basically copied a lot of things from Unity to stay competitive.

 

[Bad Sector]

Unity didn't destroy any of Unreal's market. How many AAA games use Unity? None.

Unity didn't really destroy Unreal's market but it did became a very strong competitor to the point where for UE4 Unreal ditched the editor UI they had since UnrealEd 1 (it had some minor variations but until UE4 the tools had the same UI despite actually being written from scratch three times) to make something a bit more user friendly and... one of the most promoted UE4 demo games was a flappy bird clone :-P.

 

[CanadianCorndog]

Reasons to use Unity:
- better 2D stuff if you want to make 2D games
- faster shader iteration, especially if you can write them directly in a text file
- tons of platforms
- better occlusion culling, camera has far plane unlike Unreal which uses scene bounds
- uses scripts instead of visual editor/blueprints
- more noob friendly, easier learning curve
- can ship on mobile assuming you optimize correctly
- runs on cheaper computers than Unreal (Unreal is a bloated hog of a program, slow as molasses unless you have a top-end rig)

Reasons to use Unreal:
- more visual editors
- blueprints (designers absolutely love them, they feel empowered and don't think of them as programming)
- looks better out of the box, less fiddly
- works great for FPS style games but can still do other games
- some of the newer tools, like Niagara, are excellent

Pick an engine that people on the team won't constantly bitch about, keep them working.

I personally don't give a fuck what engine I use.

 

[CanadianCorndog]

Also, Unity is really screwing up the ECS part of DOTS. Just give people something like FLECS and stop trying to make ECS complicated.

 

[The Avatar]

Unity didn't really destroy Unreal's market but it did became a very strong competitor to the point where for UE4 Unreal ditched the editor UI they had since UnrealEd 1 (it had some minor variations but until UE4 the tools had the same UI despite actually being written from scratch three times) to make something a bit more user friendly and... one of the most promoted UE4 demo games was a flappy bird clone :-P.

I always took that as Unreal trying to capture the indie/smartphone market away from Unity. I actually prefer the old UnrealEd UI. It's so much cleaner with less wasted space. I do hear good things about the UE5 editor.