Merging a major engine update is basic software engineering, sure, but (depending on the scope of changes in the update) it’s often the “5 senior devs for 6 months” kind of basic software engineering. Otoh, I don’t see a need to update engine very frequently or at all during a non-live-service game — another benefit of open source is you can reasonably practically back port necessary bug fixes yourself.
Game Engine Convergence And The Problem With UE5
- Thread starter BitByte
- Start date
Yes, I’m quite aware of the time it adds to game development. However the notion that the technologies they include in their proprietary engines would be obsolete is an assertion I cannot accept. In fact I’d argue that it’s false. We already know this to be true by the simple fact that devs port their technologies to unreal via a plugin. The returnal devs already ported their whole vfx pipeline to unreal which means it was not obsolete. In fact it was way ahead of what the ootb version of unreal could do.
If you’re making a generic game that fits within the scope of Unreal, by all means use unreal. It’s very clear though that unreal cannot handle all types of games. That’s why devs pursed their own engines in the first place otherwise, everyone would have transitioned to ue3 in the ps360 days. We need multiple different big game engines on the market. Competition drives progress and convergence leads to stagnation. All I’m advocating for is for devs not to converge especially when they can afford not to.
If you don't plan on doing updates and don't make your changes align with the development of the engine, that might very well be the case. But then you are probably doing it wrong. Like Bioware who hadn't figured out version control when developing Anthem
Silent_Buddha
Legend
Square-Enix also has an indie dev focused publishing arm (Square-Enix collective) that also funds, promotes and supports the indie developers that make it into the program.
What is Square Enix Collective? A conversation with Square Enix's Indie game publisher
Square Enix Collective helps Indie developers publish their games - but how does it work exactly? The man in charge explains how the company works with Indies.
They've released some nice indie games with hits and misses. I've played a few that were REALLY quite good.
I believe UBIsoft used to have something similar, but I'm not sure if they still do.
Alternatively, they can start their own fork of UE similar to what The Coalition does or what NetherRealm Studios has done.
Regards,
SB
You are wildly underestimating the complexity of integrating an update when you’ve forked something core like a physics engine when the game is already in progress — all while a hundred + people are making “user code” and content that will also need to be tweaked to support changes — the wise thing, if your game allows it, is _not_ taking on diffs with hundreds of thousands of lines containing hundreds of breaking changes in order to get access to features you already replaced or never planned to use in your project. It’s not like updating a single dependency in a regular dev project.
Inuhanyou
Veteran
Square Enix, Capcom and countless other devs show the pitfalls of trying to make proprietary technology and how in the end it's a weigh of pros and cons which can turn out very badly if all the chips don't align.
On the other hand unreal engine with a set of features has allowed many devs who would have been left behind able to still compete over decades.
The romanticism of proprietary technology is annoying. Its good depending on the team and studio and management, but it's definitely not something everyone or even most devs can count on. Or else ue and unity wouldn't be so popular. It's just a reality of business. It doesn't limit devs as much as you might think. Especially when capable devs have managed so many things. There is no unreal engine look anymore and hasn't been for a long time. Guilty gear strive doesn't look like Tekken 8. And final fantasy 7 remake doesn't look like tales of arise.
In addition, I have to question if people had an issue with the wide adoption of things like psysX and havok for countless games as opposed to devs simply creating all their technology from scratch. What should be the limit for middleware when even today a majority of game code is run on middleware plugins?
On the other hand unreal engine with a set of features has allowed many devs who would have been left behind able to still compete over decades.
The romanticism of proprietary technology is annoying. Its good depending on the team and studio and management, but it's definitely not something everyone or even most devs can count on. Or else ue and unity wouldn't be so popular. It's just a reality of business. It doesn't limit devs as much as you might think. Especially when capable devs have managed so many things. There is no unreal engine look anymore and hasn't been for a long time. Guilty gear strive doesn't look like Tekken 8. And final fantasy 7 remake doesn't look like tales of arise.
In addition, I have to question if people had an issue with the wide adoption of things like psysX and havok for countless games as opposed to devs simply creating all their technology from scratch. What should be the limit for middleware when even today a majority of game code is run on middleware plugins?
D
Deleted member 2197
Guest
I was somewhat surprised the Brickadia developers said it took them several weeks (not months) of work for the physics engine. I'm not a game dev but have re-engineered code in programs and don't think this is an unreasonable amount of time. IMO for future UE5 updates I think even less time would be required for the physics integration.
As a side note their dev blog has a few other interesting UE4 vs UE5 comparisons.
Frenetic Pony
Veteran
Lol who cares, almost no VFX house builds their own renderers anymore, websites don't build their own web browser, the list goes on. What matters is the games, and due to the nature of software one thing that does a lot is much more efficient than copying the same work over and over and over again.
If there's a problem it's the UE5 is a for profit engine, at least there's Godot which has been shooting up in usage so fast it's already starting to eclipse Unity in a few areas like game jam titles. The days of needing an entire engine team just to get your game to work at all are over, and the world is better for it.
If there's a problem it's the UE5 is a for profit engine, at least there's Godot which has been shooting up in usage so fast it's already starting to eclipse Unity in a few areas like game jam titles. The days of needing an entire engine team just to get your game to work at all are over, and the world is better for it.
This type of argument is especially frustrating because the whole post is essentially a strawman. The days for needing an engine team just to get your game working have been over since the ps360 days and some would argue much earlier. I don't see anyone in here making an argument that all teams should build their own engines or that it's a bad thing for teams to use 3rd party engines. Very confusing.
I think I can better position the counter argument. Imagine if the engine was a professional kitchen. And when we compare professional kitchens, they more or less have the same things in that kitchen.
But one kitchen uses Natural Gas stoves, and the other for some reason say uses induction.
But the kitchens have their own staff and their own menus, and we rate one restaurant's dishes as better than the others.
But instead of aligning the reason to the staff for coming up and executing on a better dish, we point at the gas vs induction as the reason for better dishes.
I think ultimately, the tools are out there for all engines, custom or 3rd party. The middleware is all out there too, to make any game. The problem isn't the kitchen or the equipment. The problem is the menu and the ability of the staff to execute on delivering that menu.
And while I agree technology does play a factor here and there, at the extreme edge cases - the majority of the failure that any kitchen (even the best ones) will succumb to, is being asked to cook their dishes correctly under a time constraint. I've been to the best restaurant that missed a few orders, and then started sending rush orders and salmon kept coming back undercooked, and then everyone elses dishes started getting undercooked, etc etc.
And games aren't any different. Most games coming out that fail to deliver is because they failed to cook their dish correctly. Something needed more time, and the pipeline of content was just not generated well resulting in terrible backorders etc. I think Bioware came up in this thread, and ME:A and Dragon Age II and Anthem were all cooked under 18 months. I know they complained about the engine, but that was just 1 more complication, on the reality that they had 18 months to make a product, because they spent 18 months earlier that work was tossed away.
Silly metaphor — the engine is a large part of the body and substance of the game, not simply a tool used in production. I guess a better metaphor is “restaurants use different seasoning but they all serve them on chicken”, which naturally isn’t true but gets closer to the heart of the issue.
I don't know. I think the engine has become pretty transparent to the game, with the exception of maybe things like shader compilation stutter. This isn't UE3 anymore, where UE had a look where you could guess if a game was UE or not. The engine is so flexible now you wouldn't be able to spot a UE game without seeing the logo on a splash screen or digging into files etc. There's no look or feel that's consistent across UE games, and I believe that would be true for any modern engine. The only thing that would differentiate engines from a gamers perspective might be some exclusive technical features like nanite (even lumen has alternatives). From a developer perspective there are going to be a ton of differences between engines in features, tooling, productivity, stability etc.
If you properly engineer your changes and have good patch/branch hygiene I would say it is not impossible to do. You can also submit your changes to upstream and see if they want to integrate them in their branch.
Of course, if you just mash in code everywhere without any planning or engineering you will have problems later.
Really?
I can't see an engine nothing more than a suite of tools and stations for 'content' to be built on. Which to me, thinks of a kitchen with the right tools to create a dish.
Each engine is it's own kitchen so to speak.
I think at the highest of levels, most kitchens are functionally capable to other kitchens, but it's still the staff that creates the dishes.
You can blame the tools if the tools don't work. A skillet on a stove is a skillet on a stove. But the person wielding it, that's where the difference is quality is going to be.
But if the tools work, it's on the staff to make make a good dish and be able to execute on it.
There's certainly truth that a skilled team can plan, create, and deliver their vision regardless of the engine -- the thing that makes this analogy a little off to me, though, is that a significant portion (probably majority?) of the code at runtime is "engine" code. Modern engines certainly include the suite of tools that are used to create the game, but they also include memory allocation strategies, scene management, renderers, physics engines, etc. These things can influence or even dictate what the best path to a game is, so there's lots of potential value to creating a custom engine that's suited to the kind of game you want to make, in a way that's very unlike building a custom stove or oven.
Hey you can still spot an Unreal game if they use the shitty built-in lens flare
That aside I agree. Especially as most engines have moved to standardized PBR pipelines and BRDFs to make content compatible in a lot of cases you can effectively get the same or very similar pixels out of different renderers. Even being used to Unreal I personally have to go look up if a game is using it most of the time. Rasterized shadow techniques and filtering are sometimes still a give-away but as we move more to raytracing that gets harder to differentiate too.
And certainly outside of rendering I have no idea how you'd guess at which engine most games are using accurately. Maybe in networked physics stuff a little bit (but even that is very dependent on how a given game uses it)? Particularly when you ignore rendering it really is a set of tools that people can use to accomplish things how they want.
cheapchips
Veteran
John Fuller, CTO of Avalanche Studios Group, talks about The Economics of Developing and Maintaining Proprietary Tech.
Thought it was interesting that he felt that many of the disciplines they follow to prevent games branching their tech, apply to multi game studies using third party engines too.
Thought it was interesting that he felt that many of the disciplines they follow to prevent games branching their tech, apply to multi game studies using third party engines too.
Plus which Physics library they use. eg. Unity has 3 available, so you can't tell from the physics that a game is using Unity.
D
Deleted member 2197
Guest
EA Refreshes Frostbite Engine with new logo - KitGuru
Game engines are an important tool required for video game development. While many have resorted to
www.kitguru.net
Similar threads
