The entire original Mass Effect trilogy was created on Unreal Engine 3. So was the later Legendary edition. And there were no problems with it. Frostbite was used only in Andromeda and it caused gigantic problems in production. What's more, in the production of Mass Effect "5" devs returned to the source and the game will be built on Unreal.
Ah -- so they were. I had that backwards. I thought it was Frostbite first, then ME:A was in Unreal. I know I read a big dev article on how Dragon Age Inquisition was Frostbite, and the team was seemingly doing it's darnedest to talk positively. But you could basically hear: 'Nothing about this engine worked. Everything was a nightmare. We had to work around its limitations constantly.' I had read a lot of the same stuff when they interviewed Jake Solomon (I think...) about the experience of building XCOM:EW in Unreal, and it was the same story: 'Lots of unexpected challenges. The engine wasn't made for this. It was stapling a lot of mechanics to an engine that just wanted to make things look pretty.' Now, I wonder if the widespread success of games like XCOM and Mass Effect is what spurred Epic into really focusing on making the overall engine more robust.
Most of what I understand of Unreal comes from the horse's mouth. I live in Raleigh, NC. I used to teach literally down the road from Epic's national headquarters, and I chummed around with several of their devs over time. They, themselves, would say that Unreal was built to make graphical performance absolutely top-notch. They wanted studios to be able to just plug whatever 3D assets into it and have things work perfectly and look amazing with minimal effort. The offset for that was that coding in Unreal could be a lot more restrictive and difficult than other engines, as it didn't want to let anything take precedence over graphical performance by design. (Heh...anecdote...these were the guys that used the "sportscar" analogy to describe it, which is where I got that. They said, Unreal is like a Ferrari. It's got one of the fastest engines, it handles like a dream, but the inside is really down to basics, there's only two seats, and there's virtually no trunk space. That's why it's so fast.)
Now, all of the discussion we had was understandably limited. They were coders: they really didn't want to talk about work on their time off. I get that. But this was only back in 2014. If Unreal has truly expanded itself to the point that it's able to compete in the functionality department with engines like Unity, Larian's D:OS engine, or REDengine...that's gotta be a recent development.
Or -- it's
in development. Like, right now. With CDPR. This, I can sort of understand. Sort of.
This is a huge plus, because it removes one of the biggest drawbacks of the Red Engine, which caused problems due to the fact that it was created simultaneously with the game development process, resulting in numerous technical issues and forcing developers to work on unfinished, unstable tools, and all this in the context of too few employees dedicated to the development of such a powerful and complex tool.
Now the entire technical side is handled by Epic.
As for the advantages of the engine, one of the biggest yet unmentioned is the increase in ease of recruitment, because virtually everyone in the industry knows the UE, so there is no need to learn a new engine and tools, so the potential employee can almost immediately get into production, which incredibly simplifies the whole process for all interested parties.
Fair. I get that. I, personally, would never want anything to do with writing an engine. I also get that by basically out-sourcing the technical end of things to a completely different studio, it frees up CDPR itself to focus entirely on content. That's definitely awesomes.
But...
What about independence? What about being a self-reliant and self-sustaining studio? Granted, I have no issues with partnerships! Where my concern lies is in accomplishing something like REDengine...then just locking it away in a closet somewhere. I think my choice here would have been less sweeping. I would have considered a project to test out Unreal. Something smaller. See how it goes. In the meantime, I would have utilized REDengine for a more substantial project -- this time working within the confines of the engine as it exists. Work could still be done on it, but more focused on bug-fixing and polishing than building in new features. Perhaps use this as an opportunity to introduce an in-house IP. A completely new universe. I would certainly never set aside my own engine.
Unreal works, too. It works, minus all the technical development hurdles of RE.
And as above, the fact that you can create beautiful graphics on UE5 certainly does not hurt, but it's definitely not a very important selling point, because with the right artists (which CDPR does not lack) beautiful graphics can be created on virtually any modern engine including Red Engine.
But Unreal will hit those hurdles as well. I wish them all the best, but I think that Epic may be in for a ride when they see what CDPR actually wants to do (if their past titles are anything to go on.)
The title, "a new saga," was used to not give away details of the game. We don't know if it's a sequel, prequel, sidequel, etc.
On top of that, there is absolutely no evidence that the new game would be simplified from its predecessors. Knowing the Reds' approach and looking at their history, it is much more likely that the next Witcher will be studio's most complex and ambitious project. Reds are not used to stepping back in their ambitions in their flagship series.
And definitely Unreal is not a harbinger of such changes, because, as it has been proved many times above, there is no shortage of complicated games (even MMOs, which are probably the only genre that is more complicated than rpgs, while still presenting an attractive visual layer) created on this engine. And again, despite the fact that such games on this engine reguarally are created, there are practically no publicly known bts stories where AAA developers had to fight with technology. This ease of creation and technical support, these are the engine's greatest strengths.
Exactly. My point in identifying this is to clarify that people are
assuming it's "The Witcher 4". It could be something very different.
The page I posted the link to in my original post was in Polish, but it contained an English translation of the statement to shareholders.
Yeah -- someone linked to the English above. I looked at yours and figured it had to be something like that; I even looked for a "translate" button. If only I had scrolled down a little bit more...
I can think of examples were cp2077 fails at one or more of this items and also The Outer Worlds. But the point is, that most of this functionality is not even what i would consider "the core" of an engine but a side module running in parallel with what makes engines expensive:graphics,physics...in old days,adding that module (or npc AI algorithms) to an existing engine was probably as difficult as writing the whole engine, but now the commercial ones are build with modularity in mind:you don't like my audio module?buy a 3rd party one or write your own. REDengine is build that way also, is using middleware for some of the game functionality.
I'm pretty sure,that CDPR evaluated UE capabilities, checked what they had custom and asked Epic "dudes, we want to be able to use this,this and this is it possible?" and Epic said "sure". Then the deal was just: how much we save in not rewriting our graphics,physics etc modules each time?
An approach like this is becoming more and more viable as technology becomes more powerful, but more moving parts means more than can go wrong. Every connection I add to the hub is a line that can be tripped over or cut. This type of thing is more the way modding works -- where people are forced to duct-tape things to an existing engine using utilities like plugin files or script extenders. (Yes, this would be
somewhat different if working at the engine level itself, but it's still essentially the same idea.)
The trouble with this type of approach is -- it costs performance. I need to run a "master" function first -- have that function hooked, interrupted, and/or overridden -- then introduce the additional/overriding function on top of that. This adds up FAST when you're talking about millions of functions per second.
The best bet is always to write an engine to do exactly what you want it to do at the core level. Harder work, but a cleaner, more efficient final product.
