Game Engine Convergence And The Problem With UE5

[Seanspeed]

While I'm not going to strongly argue frostbite was at fault for me:a (certainly the tech itself wasnt) the pains of challenging, frustrating, or off schedule dev work don't necessarily show up in bugs or performance issues or low scope -- This stuff all ripples through the whole team, it could mean more developers working with less poloished (or non existant) tools because the "engine" work took longer than expected, it could mean last minute animation integration, etc.

Certainly, but again, Bioware had already made the leap to Frostbite with Dragon Age Inquisition. It wasn't their first rodeo with it, and the complaints that existed would unlikely have been ironed out if they stayed with UE instead, and certainly building a whole new engine and learning how to use it would have been even more challenging and quite plausibly would have led to even worse issues.

That's kind of my point here. It's all well and good to point to using some different engine and saying that was their real problem, and it's a convenient excuse to use on the surface(much like every developer in existence blaming Covid for delays/issues when 70% of games were already getting delayed before Covid ever hit...), but the alternative of building your own engine has few guarantees that things turn out better, especially within a similar sort of timeframe. Building your own engine isn't some magic bullet to creating a perfect game and the complexities of modern AAA titles combined with their extra lengthy and thus extra expensive development means you're going to get games releasing with issues and constraints no matter what.

To be clear, in an ideal world of course I'd love to see more games being built with custom engines, I'm just saying that the argument for why it's sad this isn't happening should not be about it causing extra problems for developers. Cuz there isn't an engine in existence that makes making ambitious AAA titles 'easy' or anything remotely close. You're simply trading problems for other problems, and possibly even bigger problems. If you're time/budget limited and you've already eaten into a ton of that just building or upgrading your existing engine, then well, you very much might find the potential of the game limited by that itself, for example.

 

[Andrew Lauritzen]

Certainly, but again, Bioware had already made the leap to Frostbite with Dragon Age Inquisition. It wasn't their first rodeo with it, and the complaints that existed would unlikely have been ironed out if they stayed with UE instead, and certainly building a whole new engine and learning how to use it would have been even more challenging and quite plausibly would have led to even worse issues.

Minor point but worth noting that ME:A and DA:I were different studios within Bioware though. I'm sure there was communication but I'm not sure how much the teams overlapped. ME:A was Bioware Montreal (at the time) which at some point sorta merged/became EA Motive (who then worked on the SP portion of Battlefront 2 followed by Star Wars Squadrons).

Only indie devs can really afford to grow their own engines organically because they don't necessarily need to immediately implement the latest technology into their engine. They can start small and grow it modestly over multiple titles or a single passion project that takes that over a decade. But even in the indie scene, most developers are choosing to go with an established engine because building your own engine is hard and extremely time consuming.

Yeah this is definitely a point worth considering. Multi-platform is often what makes the task a lot more complicated, both in terms of development and also support. Even the recent indy titles that roll their own engines often take a year or more to bring their (often 2D) engines to a single additional platform once it becomes popular (Hades, RL2, Monster Train, etc. etc.).

 

[cheapchips]

I haven't tried myself, but people say replacing the physics engine in such game engines is too much work / too hard to maintain

Wish I could find the article, but a smaller developer announce that they did this recently. They swapped out Chaos in UE5 with something else.

 

[Seanspeed]

Wish I could find the article, but a smaller developer announce that they did this recently. They swapped out Chaos in UE5 with something else.

Many things are 'possible', it's just a matter of what you're giving up to do it. Opportunity cost and prioritization really need to be kept in mind.

 

[Deleted member 2197]

Wish I could find the article, but a smaller developer announce that they did this recently. They swapped out Chaos in UE5 with something else.

Devlog #1 - Upgrading Brickadia to Unreal Engine 5.1

For a huge performance uplift Brickadia has integrated PhysX 5.1 in the UE5.1 engine instead of using Chaos for physics. Good to see out-of-the-box thinking and decision making.

"In the Open Alpha, we had upgraded the physics engine in Unreal from PhysX 3.4 to PhysX 4.1 for significant performance improvements with brick collision. Our bricks are now also directly integrated with PhysX for collision detection rather than going through the slow abstraction layers in the engine. Did I mention that we like PhysX?

So what do we do about the fact that Epic deleted PhysX from the engine?

Yes, you read that right - a key component we've relied on simply disappeared from the engine. It was replaced by their custom "Chaos" physics engine, which at least in our tests, currently runs at significantly worse performance for the kind of simulations players will undoubtedly create in a physics based sandbox game.

Luckily, we're not bound by sanity as an indie developer, so the solution is obvious: We just have to put PhysX back in the engine! Oh, and they just released a new version, so let's upgrade it to PhysX 5.1 also while we're at it.

It was all worth it in the end, because we now have a branch of Unreal Engine 5.1 that can switch between Chaos and PhysX 5.1 with a single build setting. The PhysX version runs several times faster in large simulations, and our brick collision code can now work again. The engine also compiles faster without the Chaos code in it, improving iteration times. As far as we know, we're currently the only ones with such a branch."

 

[Scott_Arm]

A lot of romanticism over engines missing the business aspect of it. The main goal of the engine is to support running all aspects of the game in unison, and in todays world that also includes being able to deploy to multiplatform.

We are seeing convergence because the costs are steep to maintaining and updating an engine to support as many configurations as possible.

Most of the failure you see with games however is because they rolled a custom engine, but because they likely tried to make a game under 2 years.

No engine is going to solve that problem. But the reality is, it’s a lot of work to innovate new game design experiences and have them still be valid 4-5 years later.

I would say we're seeing a lot of in-house engines fail because realistically they can't keep up. The complexity of keeping game engines up to date with the cutting edge costs more time and money than the big game houses are willing to put up with. What you'd see is engines like Frostbite stay up-to-date enough that they could produce good visuals, but the actual content pipeline and other dev tools were awful. For example if you're at EA you might fight it really difficult and expensive to maintain separate engines for every sports game, racing game, shooter etc, so they start trying to get Frostbite to do it all, and then the Frostbite team would basically have to be large like the team that makes Unreal Engine if they want it to be cutting edge, have great tools and be general purpose. In reality that succeeded and failed to some degree. They've had a lot of terrible launches under that model, and I'd say the sports games are the success story though those games barely change year over year (they're not racing to stay at the bleeding edge of everything).

I think there should be more experimental game engines, and the way that should happen is the EAs of the world should stop caring about making every game "AAA." Gamers really don't care most of the time. I think for games chasing photo realism (especially in combination with open world design) it will get harder and harder to keep up with Unreal. In the case of small engines, it still really doesn't make sense to roll your own physics engine. It would be better to take one that's open source and add in features you need. The new Zelda isn't using and groundbreaking technology, as far as I know. It's just making physics part of the game design. Right now PhysX and maybe Havok are very accurate general purpose physics engines that allow you to do a lot of things without having to worry about unexpected behaviour as much as an engine like Jolt which I think is faster but can run into more odd behaviour because it optimizes things with cheaper approximations. And yah, a lot of content you're going to want to support things like Blender, or standard audio tools etc. You don't want to have to find experts in all of those fields to reinvent the wheel and solve problems that have been solved for a very long time.

There are other cool engines that are completely free and would be good starting points for game dev:

GitHub - turanszkij/WickedEngine: 3D engine with modern graphics

3D engine with modern graphics. Contribute to turanszkij/WickedEngine development by creating an account on GitHub.

github.com

GitHub - bevyengine/bevy: A refreshingly simple data-driven game engine built in Rust

A refreshingly simple data-driven game engine built in Rust - GitHub - bevyengine/bevy: A refreshingly simple data-driven game engine built in Rust

github.com

GitHub - godotengine/godot: Godot Engine – Multi-platform 2D and 3D game engine

Godot Engine – Multi-platform 2D and 3D game engine - GitHub - godotengine/godot: Godot Engine – Multi-platform 2D and 3D game engine

github.com

Another thing I think the big companies should do is allow their employees to spend time contributing to open source projects that they can integrate into their games. Rust in particular has a lot of open source game dev crates that people can use, some of which look really nice like egui. https://arewegameyet.rs/

You can see an example here of a professional game dev stepping into Blender and making huge improvements, though I think he'd already left Unity and basically had the time to do it. He made some huge productivity improvements and it would be nice to see open source tools getting optimized that would benefit the industry as a whole.

Speeding up Blender .obj export · Aras' website

aras-p.info

Speeding up Blender .obj import · Aras' website

aras-p.info

Swallowing the elephant into Blender · Aras' website

aras-p.info

 

[BitByte]

Apologies in advance to interrupt the really interesting discussion with a cheap shot, but you are really unlucky with your example


How? Well...they used Havok. No really. (This being BoTW, but according to people on Twitter datamining ToTK, it's the same for the latter, just a newer version)

Huh, it’s a fair call out. I didn’t know they used havok but, if they did use havok, what excuse do devs have for the whole ps4/xb1 gen. That’s actually crazy that they have such a performant version of havok running on the switch.

 

[Scott_Arm]

Huh, it’s a fair call out. I didn’t know they used havok but, if they did use havok, what excuse do devs have for the whole ps4/xb1 gen. That’s actually crazy that they have such a performant version of havok running on the switch.

Zelda is just game design. No one was stopping devs from doing similar things. They just weren’t doing it.

https://twitter.com/x/status/1664160530884337666

 

[BitByte]

You do realize that virtually noone is building a new engine for AAA games?

I know and it’s really sad. That being said, I was advocating that devs continue to develop their in house engine instead of switching to unreal.

Bethesda is using an engine from 2011. DICE is using an engine from 2008. Keep in mind that while those are considered "new" engines, they didn't start them out completely from scratch. The FarCry series is using an engine (Dunia) from 2004 which has as a starting point an engine from before 1999 (CryEngine was first shown in 1999 but development started on it before it's first showing, obviously. ). Naughty Dog has been using the same engine for well over a decade now. Yes, it got a large enough technology update to the base engine that called it a "new" engine but it still has its roots in their older engine because starting over from a blank slate makes no sense. They just rewrote large chunks of the rendering code and other stuff. You know, like how the better UE devs approach modifying UE.

This is true, it’s an iterative process however, some studios are abandoning all that work and running to unreal because it’s cheaper. Unfortunately, unreal isn’t really that performant from what I’ve seen.

 

[BitByte]

Zelda is just game design. No one was stopping devs from doing similar things. They just weren’t doing it.

https://twitter.com/x/status/1664160530884337666

Frankly I think it’s a bit rich for Sebastian to disregard the efforts by the Zelda team as standard rigid body physics. It is using standard rigid body physics buts it’s about how they use it. The last game from Ubisoft that could even begin to touch the physics in Zelda was far cry 2. He also references trials on Xbox 360, a game I play which had basic physics.

 

[arandomguy]

But aren't their two things being described here? It's a game design achievement (what's being done) as opposed to a technical achievement (how it's done).

Also I wouldn't be discounting the performance of the Switch's CPU too much. It's per thread perf actually compares favorably to that of that of the PS4, albeit having only half the threads. It's hard to get an apple to apples comparison here, but it may actually be slightly faster per thread.

 

[function]

Frankly I think it’s a bit rich for Sebastian to disregard the efforts by the Zelda team as standard rigid body physics.... He also references trials on Xbox 360, a game I play which had basic physics.

Zelda has "basic physics". Trials was pretty nuts for the time, and very cool. And funny.

 

[JoeJ]

Wish I could find the article, but a smaller developer announce that they did this recently. They swapped out Chaos in UE5 with something else.

Guess you mean this: https://brickadia.com/blog/devlog-1/
David Graham had posted it in UE5 trhead.

Luckily, we're not bound by sanity as an indie developer, so the solution is obvious: We just have to put PhysX back in the engine! Oh, and they just released a new version, so let's upgrade it to PhysX 5.1 also while we're at it.

This marks the start of a rather painstaking several weeks of doing nothing but scouring the history for tens of thousands of lines of PhysX integration code that Epic removed, putting it back, then rewriting half of it to make it function properly again, and also hiding all the Chaos integration code.

It was all worth it in the end, because we now have a branch of Unreal Engine 5.1 that can switch between Chaos and PhysX 5.1 with a single build setting. The PhysX version runs several times faster in large simulations, and our brick collision code can now work again. The engine also compiles faster without the Chaos code in it, improving iteration times. As far as we know, we're currently the only ones with such a branch.

It's surely doable, but after that every update of UE causes you to do the same changes again.
Or you stop updating and maintain the engine yourself, eventually trying to adopt future changes manually.
Neither of that is good, so very most likely you would end up using Chaos as is.
Which in my case would mean to stop work on self balancing ragdolls but keep using the traditional animation based techniques, while waiting for Epic to eventually do some robotics research or buying some startup who does.

So now we have an example of off the shelf engines hindering innovation. The problem would not exist if i would develop all tech on my own.
Assuming every dev would switch over to UE over time, we might never see robotics find its way into games. Or, more likely, we would get just one solution, without any option to explore potentially better alternatives.

That's why i think the example is pretty good. If we talk about graphics, i can see why many people think there is not much reason left on further research. Just leave it to the experts at Epic. Makes sense, because after decades of gfx progress we can assume state of the art is good.
But if we talk about robotics, that's an entire new field for game devs. State of the art and experience is zero. There is seemingly only one company (Boston Dynamics) knowing how it works (for them). And there is also a lot of recent progress on ML based approaches for computer graphics. Promising and seemingly ready to be used, but we neither know how practical this is nor how it compares to alternatives such as BDs methods.

Conclusion, as said in opening post: Centralization of engine development is a good idea if we look at the current state of the art, but a very bad one if we consider the unknown future as well.

 

[Dictator]

Zelda is just game design. No one was stopping devs from doing similar things. They just weren’t doing it.

https://twitter.com/x/status/1664160530884337666

That is such an important part to this thread which Seanspeed mentions too - engine is a thing and a big thing, but game design goals with it are signifcant.

 

[tuna]

Guess you mean this: https://brickadia.com/blog/devlog-1/
David Graham had posted it in UE5 trhead.



It's surely doable, but after that every update of UE causes you to do the same changes again.

You have to rebase/merge your changes every time there is a UE update. That is just basic SW engineering.

 

[JoeJ]

You have to rebase/merge your changes every time there is a UE update. That is just basic SW engineering.

Well, i have such problems with the physics engine too. Currently i do it all manually each time i do an update.

But i guess there are ways to automate the process? Eventually i could try to use github and a fork? (I'm too much amateur to know )

 

[tuna]

Rebases on public branches are troublesome in a lot of ways, but might be the easiest solution. Otherwise you might try to have patches (similar to how a lot of Linux distros handle their changes) that you rebase and apply to your "local" branch of UE (or whatever you are changing).

 

[see colon]

I think there should be more experimental game engines, and the way that should happen is the EAs of the world should stop caring about making every game "AAA."

I assume you are talking about EA and it's internal studios. EA has probably done more to help indie/AA games than any 3rd party publisher through EA Originals. Sometimes they get a hit like Unravel or It Takes Two, and sometimes they get Knockout City. But speaking of Knockout City, that was a game funded through EA Originals that EA put it's whole marketing weight behind, even though they retained 0 rights to the IP. Velan, the developer, later self published the game after the deal with EA was over, and moved the whole backend from EA servers to Epic. The game is about to be shut down because of lack of players, but I think it's an interesting tale about EA's involvement with smaller development studios, and it's a game that used a custom game engine that was performant and didn't seam to be behind the curve in terms of graphics. I'm not sure any reviews mentioned the engine and gave it a higher score. I'm not sure any player kept playing the game because the engine was custom. And I think that's part of the problem. They put all that work in to a custom engine, but was that time and money well spent? It's hard to tell. But if they used an off the shelf engine and used the extra time/funds to make more content, what effect would that have on the game?

 

[Scott_Arm]

I assume you are talking about EA and it's internal studios. EA has probably done more to help indie/AA games than any 3rd party publisher through EA Originals. Sometimes they get a hit like Unravel or It Takes Two, and sometimes they get Knockout City. But speaking of Knockout City, that was a game funded through EA Originals that EA put it's whole marketing weight behind, even though they retained 0 rights to the IP. Velan, the developer, later self published the game after the deal with EA was over, and moved the whole backend from EA servers to Epic. The game is about to be shut down because of lack of players, but I think it's an interesting tale about EA's involvement with smaller development studios, and it's a game that used a custom game engine that was performant and didn't seam to be behind the curve in terms of graphics. I'm not sure any reviews mentioned the engine and gave it a higher score. I'm not sure any player kept playing the game because the engine was custom. And I think that's part of the problem. They put all that work in to a custom engine, but was that time and money well spent? It's hard to tell. But if they used an off the shelf engine and used the extra time/funds to make more content, what effect would that have on the game?

Yah, I've probably underestimated EA in terms of their support of gaming in general versus their behemoth sports titles etc. I think experimentation is important for the industry to find new ways to solve problems. That's easier in some of these small engines. I'd guess modifying Wicked Engine is potentially easier than UE, because it's just a much smaller code base with fewer dependencies. It's not really that I think custom engines will make games better, or that users will notice. Just in terms of R&D it might be easier to do things on smaller games and smaller engines. Then with the open source stuff like contributing to open source engines or tools, it just kind of makes the industry better overall. I know a lot of companies don't want their programmers spending man hours contributing to open source tools, but if those tools get used internally, why not?

 

[digitalwanderer]

I know and it’s really sad. That being said, I was advocating that devs continue to develop their in house engine instead of switching to unreal.

Do you have any idea how much time that would add to a games development as well as time to market? Technologies they include in their proprietary engines will be obsolete by the time they get to release, it's one of the big reasons the UE engine was adopted so widely. Tremendously cuts down development time as well as keeping it up with the tech pretty well.