If the engine is indeed a “miracle”, then why ditch it for UE5?
Not holding the person accountable, it’s probably a shortsighted “management” decision to ditch an engine that had been improved an order of magnitude since the launch.
All is see is more costs and money down the drain to get the developers up to speed and as productive.
I interpreted it as “a miracle it works as well as it does.”
Remember how busted 2077 was at launch, in spite of it basically being Nvidia’s crown jewel? Remember all the delays in spite of reports of crunch and dev hell?
Making a contemporary engine for a game like that is hard, and requires massive scale.
To make it short: UE5 has a ton of pre-existing talent and CDPR lost some people experienced with REDengine in the fallout from the initial cyberpunk 2077 crunch.
The result is that future titles will be much easier to develop for though UE5 has some serious performance issues, those issues CAN be fixed via a combination of in-engine settings and making a few manual changes but it remains to be seen wether CDPR will make the effort to customize the engine to suit their needs.
I remember an interview where one of the lead devs mentioned UE5 needs to be optimized as you go.
Apparently, you can’t just build first and hope to optimize everything later. It becomes far to complex to do it that way, and that’s the way most studios are used to working. They often even have two seperate teams and seperate development phases.
So it’s a little encouraging that they’ve changed their workflow to prioritize optimization and engine efficiency.
but it remains to be seen wether CDPR will make the effort to customize the engine to suit their needs.
From what I remember they’re doing so many changes to UE that one of their biggest changes is being merged into UE5 itself. Just because they’re moving to the other engine doesn’t mean they don’t also have engine developers working on it. It’ll likely be much more optimized than your typical unreal engine game.
All is see is more costs and money down the drain to get the the developers up to speed and as productive.
Maybe in the short term, but long term it will save costs and speed up developers. If they keep their own engine, they have to continuously spend money to keep developing it, and every developer has to be trained to use this engine.
So while switching does cost money, staying on their custom engine will cost far more in the long term.
It can be more of a mixed bag than that, though. If your employee retention and training is good enough that you have plenty of people who wrote the engine or at least understand it really well (which doesn’t seem to be the case at CDPR since Cyberpunk’s crunch), it can be much faster to alter it than to figure out the equivalent guts of Unreal Engine. That won’t end up making a difference if you stick to well-trodden paths that lots of games from lots of studios use, but if you want to do something that Unreal doesn’t support out of the box, it can be quite hard to wrangle.
That’s only if your employee retention and training are good enough, and you don’t plan on growing your team. When adding more developers you either have to invest incredible amounts of time and money to get everyone to that level (and we’re talking years per developer), or you’ll be left without the ability to really alter it while still having to educate every new developer on your engine.
This approach simply doesn’t scale or work out in the long run.
If you’re specifically working on a game that stock UE5 can’t do, e.g. you need to make the kind of far-reaching changes that Valve had to make to Source to make Portal possible, you end up with most of those problems even if you’re doing it by modifying UE5 rather than modifying your in-house engine. You’re still ending up with a custom engine at the end of the process and still need to make tooling for it and onboard everyone, even if it ends up fairly similar to stock UE5 due to being modified UE5. It doesn’t necessarily work out any more scalable or sustainable than modifying an in-house engine once you’re making this kind of change. The outcome ends up being that games that can’t be made in close-to-stock UE5 just don’t end up getting made.
I didn’t say that they did, just that switching to UE5 can be a mixed bag rather than always unambiguously better. My original comment was pretty explicit about it not being applicable to CDPR.
If the engine is indeed a “miracle”, then why ditch it for UE5?
Not holding the person accountable, it’s probably a shortsighted “management” decision to ditch an engine that had been improved an order of magnitude since the launch.
All is see is more costs and money down the drain to get the developers up to speed and as productive.
Can someone in game dev enlighten me, please?
I interpreted it as “a miracle it works as well as it does.”
Remember how busted 2077 was at launch, in spite of it basically being Nvidia’s crown jewel? Remember all the delays in spite of reports of crunch and dev hell?
Making a contemporary engine for a game like that is hard, and requires massive scale.
To make it short: UE5 has a ton of pre-existing talent and CDPR lost some people experienced with REDengine in the fallout from the initial cyberpunk 2077 crunch.
The result is that future titles will be much easier to develop for though UE5 has some serious performance issues, those issues CAN be fixed via a combination of in-engine settings and making a few manual changes but it remains to be seen wether CDPR will make the effort to customize the engine to suit their needs.
I remember an interview where one of the lead devs mentioned UE5 needs to be optimized as you go.
Apparently, you can’t just build first and hope to optimize everything later. It becomes far to complex to do it that way, and that’s the way most studios are used to working. They often even have two seperate teams and seperate development phases.
So it’s a little encouraging that they’ve changed their workflow to prioritize optimization and engine efficiency.
From what I remember they’re doing so many changes to UE that one of their biggest changes is being merged into UE5 itself. Just because they’re moving to the other engine doesn’t mean they don’t also have engine developers working on it. It’ll likely be much more optimized than your typical unreal engine game.
Maybe in the short term, but long term it will save costs and speed up developers. If they keep their own engine, they have to continuously spend money to keep developing it, and every developer has to be trained to use this engine.
So while switching does cost money, staying on their custom engine will cost far more in the long term.
It can be more of a mixed bag than that, though. If your employee retention and training is good enough that you have plenty of people who wrote the engine or at least understand it really well (which doesn’t seem to be the case at CDPR since Cyberpunk’s crunch), it can be much faster to alter it than to figure out the equivalent guts of Unreal Engine. That won’t end up making a difference if you stick to well-trodden paths that lots of games from lots of studios use, but if you want to do something that Unreal doesn’t support out of the box, it can be quite hard to wrangle.
That’s only if your employee retention and training are good enough, and you don’t plan on growing your team. When adding more developers you either have to invest incredible amounts of time and money to get everyone to that level (and we’re talking years per developer), or you’ll be left without the ability to really alter it while still having to educate every new developer on your engine.
This approach simply doesn’t scale or work out in the long run.
If you’re specifically working on a game that stock UE5 can’t do, e.g. you need to make the kind of far-reaching changes that Valve had to make to Source to make Portal possible, you end up with most of those problems even if you’re doing it by modifying UE5 rather than modifying your in-house engine. You’re still ending up with a custom engine at the end of the process and still need to make tooling for it and onboard everyone, even if it ends up fairly similar to stock UE5 due to being modified UE5. It doesn’t necessarily work out any more scalable or sustainable than modifying an in-house engine once you’re making this kind of change. The outcome ends up being that games that can’t be made in close-to-stock UE5 just don’t end up getting made.
If you continuously make games like that, sure! But CDPR doesn’t do that.
I didn’t say that they did, just that switching to UE5 can be a mixed bag rather than always unambiguously better. My original comment was pretty explicit about it not being applicable to CDPR.