Hacker News new | ask | show | jobs
by danschuller 1325 days ago
Remakes make business sense. Every game is a risk. A portfolio of products that includes remakes reduces that risk. A game that was previously popular is easier to remaster than trying to make some new that's less tested. There are always brand new gamers to introduce to your IP as well as existing gamers who may have missed or want to replay earlier games. If you're a mature studio it's almost irresponsible to not do this.

The more interesting part of the story is Unreal is being used. For a while Unity and Unreal have been pushing out in-house engines. Again standard tools make it easier to hire expertise and use existing solutions and assets, they're also far cheaper than running a full engine team. Supporting a custom engine is a massive undertaking at the high end (ignore the tech, on-boarding people, docs, QA, surrounding tools for artists, sound designers, localisation etc. And then making it work on a wide variety of hardware and working around any graphics bugs etc).

8 comments

> The more interesting part of the story is Unreal is being used. For a while Unity and Unreal have been pushing out in-house engines.

This is exactly the case for CD Projekt Red. They built their own engine (RED Engine) for Witcher 1 and built on top of it for the two Witcher sequels and also pushed it to its very limits for Cyberpunk 2077. A lot of useful criticism of the technological pains (delays, marketplace reception issues) they experienced with Cyberpunk was that they were using an in-house game engine unprepared for that genre (jumping from a game series where the fastest vehicle was a horse to one with cars and flying cars and planes is maybe not the easiest straight line). CDPR responded to that criticism, especially from their shareholders, that they would be minimizing that risk in future games development and externalizing that dependency and moving to an out-of-the-box game engine moving forward (including in that announcement that it would be Unreal).

This announcement for the Witcher 1 remake seems like a proper and interesting "full circle" for this story: CDPR's last engine was built entirely for Witcher 1. Using off-the-shelf Unreal to remake Witcher 1 sounds like a smart way on paper to get their feet wet and move on from the old engine to the new one using a project they are already familiar with and can help them realign from old pipelines to new ones.

> This is exactly the case for CD Projekt Red. They built their own engine (RED Engine) for Witcher 1 and built on top of it for the two Witcher sequels and also pushed it to its very limits for Cyberpunk 2077.

Close. REDEngine was created for Witcher 2: Assassins of Kings. Witcher 1 was built on a modified copy of Bioware's Aurora Engine (the Neverwinter Nights engine).

REDEngine versions were:

REDEngine 1: The Witcher 2: Assassins of Kings

REDEngine 2: The Witcher 2: Assassins of Kings – Enhanced Edition

REDEngine 3: The Witcher 3

REDEngine 4: Cyberpunk 2077

To add to that (since I'm somewhat of an expert on this), the engine for Cyberpunk 2077 was completely rewritten from scratch, and only small bits were either ported from W3 or inspired by what was done in W3.
Huh that’s super interesting — full rewrites aren’t super common. Do you know why they elected to rewrite the engine completely?
I have to be careful here, but the simple reason is that the previous engine was not designed to handle the density nor the verticality of the CP77 world.

Not that Unreal Engine 5 can handle a world like CP77 either, despite what people may think with the Matrix demo.

Game dev isn't my field, I always find it fascinating though.

Why can't Unreal handle something like CP2077? Could be an "explain like I'm five" - details would be cool but I'm not sure I would even fully understand them, haha.

If Unreal Engine 5 can't handle a world like CP77, why are they making the sequel to CP77 in Unreal Engine? Are they betting on the engine being ready for CP77's sequel when they need it to be?
Interesting! I’m not at all familiar with game engine design or even game dev, but the only game series I can think of that reliably handles large, open-world scale well is GTA.

Here’s a dumb question: in theory, would Rockstar’s internal engine (RAGE) have worked for CP77, or are the technical challenges simply too different?

How is Unreal limited in a way that prevents it from doing something like CP77?
Do they license their engine? Building it just for CP77 would be a shame.
And if i remember correctly the aurora engine started life as MDK2.
I remember Neverwinter Nights 2. Decently fun game, but extremely buggy. It had some strange local lag where it wasn’t that unusual to command a character to move only to have them freeze in place then teleport back where they were 10 seconds before.
NWN2 was such an odd duck from an engine reuse perspective. When development on NWN2 began, Obsidian was handed a much older version of the Aurora engine source than what was currently available. While they did do amazing work with what they had, many weird bugs that were addressed by updated versions of mainline Aurora were now things Obsidian had to address in addition to the challenges they had to update the engine for the new game.
> Using off-the-shelf Unreal to remake Witcher 1 sounds like a smart way on paper to get their feet wet and move on from the old engine to the new one using a project they are already familiar with and can help them realign from old pipelines to new ones.

You're wrong in more than one way. As others already noted, Witcher 1 did not use REDengine - but also, it's not CD Projekt RED who is remaking Witcher 1; they outsourced the development to another studio.

As far as I remember, the first Witcher engine was a weird mash of the engine from neverwinter nights 2 and their own modifications, and they introduced their own engine with the Witcher 2.
> A lot of useful criticism of the technological pains (delays, marketplace reception issues) they experienced with Cyberpunk was that they were using an in-house game engine unprepared for that genre (jumping from a game series where the fastest vehicle was a horse to one with cars and flying cars and planes is maybe not the easiest straight line).

What made it unprepared? What special needs did CP2077 pose against a game like Witcher 3 when both are similarly open-world exploration RPGs heavy on dialogue and cinematics?

Specifically implied there is that one of the technical complaints was "draw distance" at speed and issues with "pop in" where things that should be visible aren't visible until "too late" after when they should be. If you build and tune a game engine for traveling at horse speeds and then add in vehicles that move three/four/five times as fast and some of them can fly, that puts a lot of strain on however you tuned the engine for drawing things at horse speeds and the expected results line up with many of the complaints about "draw distance" at speed and issues with "pop in".

Which is not to say that that was definitely the reason for some of those issues existed, but it does line up with what you would expect adding faster vehicles to an engine that hadn't been prepared for that.

There was a UE5 Engine demo that used Witcher-like environments in their tech demo.
Heck, something like Witcher 1 is relatively easy to pull off in UE5. XCom did it in UE3.5.

Witcher 3 being a third person game with no fast movement is also very doable. There's a plenty of adventure games made in UE using stteaming mechanics.

The moment you as cars or planes it gets much trickier. There's no example of UE5 flight sim I know of, for instance...

We had janky vehicles in UE way back when in the old Unreal Tournament 2003 - but that did not involve streaming levels.

I don’t remember seeing that. I know of a demo in an arid environment and the Matrix demo.

Do you have a link to the one you’re referring to?

Finally found it: That's from Jasom Slama directly : https://youtu.be/zO9hRBRmPi8?t=34
It's also a really good time to get into the remake business, tech-wise. We have a bunch of fresh new consoles optimized for the latest game engines, and tons of ML-based upscaling tech to play with. If you make a well-designed remake of your game optimized for solid-state storage, you should have a version that lasts a couple decades into the future.
I think remakes also work out well for consumers. Gaming isn't always about novel experiences. Sometimes you just find a satisfactory loop and want to stay in it. People have enjoyed chess for decades. For video games you can reuse the same gameplay elements and just apply the latest tech each time and people will enjoy it.

Personally I check the steam store regularly and buy new games often but I rarely end up playing them much because I prefer to just jump back in to Skyrim or some other game I have been playing for years.

I don't follow game development closely anymore, but my feeling is that UE5 with features like Nanite, Lumen, etc is so advanced that you can't expect an inhouse engine to come close. Or are there other engines that's at the same level? Frostbite used to be cutting edge years ago, but some of the developers left EA and I haven't seen any excitement about it since.

Add to that things like huge install base that should make it pretty well tested at this point, big asset library, plenty of educational material available, and I guess it's a pretty easy decision for game studios. But I'm not in the business, maybe there are big downsides as well.

You're pretty much on point, unless you're making something really specific/that needs every bit of performance that it can get, you're better served by an existing engine

A good example of something that was better served by inhouse engine is Factorio, but that' uncommon

Another case is doing something technologically simple enough that benefits from having a fully customized workflow outweigh having to write some stuff by yourself. This can happen with content-heavy genres like, say, 2D point'n'clicks - you don't get much by using an existing engine there, but you have to follow its idiosyncrasies which may or may not work well for you and your team.
Recruitment is part of it as . It’s not possible to find people that haven’t worked at your company to have experience with your custom engine - but you can hire people with years of experience with Unreal already and ramp them up for your specific game quickly.
Engines are complex beast nowadays, my graduation thesis was porting a particle engine based visualization engine from NeXTSTEP into Windows.

What was a graduation thesis 20 something years ago, is nowadays a basic feature in a bullet point feature list.

I think you are on point. The engine source code is also available which helps to limit the risks of vendoring a core tool for big teams. The unreal engine product team seems to understand the market very well and has very good execution and marketing.
Related, Jonathan Blow on custom vs 3rd party engines: https://www.youtube.com/watch?v=SOtxjOLst2k
You'd think using Unreal Engine makes it easier to hire but that's not the case, it just means there's more competition for the people knowledgable in it, and it drives the people that want to work on something different to other studios. It also doesn't cut down on development time or the needed number of engine programmers since studios pretty much have to modify and enhance the engine, often replacing several components in order to ship the game. In some cases you'll end up with an incompatible fork which requires its own team to extend and enhance it, meaning that to upgrade to a newer version from Epic you'll need to spend months merging the codebases.

Overall I see the adoption of Unreal Engine as a net negative for the industry, it's reducing the landscape to a monoculture. For all the talk that Epic does about being against monopolies, Unreal Engine is becoming one in a big way, and killing the ecosystem as it grows.

For employees of the game industry, aren't standardized engines a net positive?

I can't think of many things worse in software development than "I'm an expert on my employer's obscure, only-used-here system."

Your employer knows you can't work anywhere else, and assuming they don't shoot themselves in the foot by allowing one person to become mission critical, they've definitely got the power in negotiations.

This is a fairly nuanced question so I'll try to explain some of the reasoning.

Unreal Engine is standard in so far as studios use it as a base in developing their own game, where they end up creating a fork because they need to adapt or more often replace entire systems. So in the end each studio ends up with their own non-standard fork of the engine, branched from a specific revision, and merging the latest changes from upstream will be at least a month long endevour. This is what I know from personal experience and from interviewing at about a dozen studios last year.

With this you get a slightly different version of the engine and tools at each studio, and it affects disciplines differently. For some creatives it ends up being the same at every studio because the tools they interact with remain largely unchanged, for others they end up using custom built tools at each studio. Likewise some programmers are fine just using the engine and developing systems on top, but others are not and it drives a lot of skilled people away.

So as an employee it is a double edged sword, on the one hand there's at least some standardisation where you are at least familiar with the tools and engine used in the new studio you're joining, but on the other hand you're now one in tens-of-thousands and much more of a replacable cog.

That is one of the supposed selling points of Unreal Engine to studios - that they can hire staff more easily - but if every studio uses the same engine then it's not a benefit. It also means that some skilled people won't want to join the studio, as they don't want to rewrite systems or be a code-janitor, and I've heard many people leaving studios because they switched to Unreal.

Yeah. If a game isn't well suited to Unreal, that game may well just not get made. But then again Factorio is one of the best selling PC games of all time. Maybe gameplay finds a way.

On CDPR specifically, I hope didn't make the decision to drop Red Engine because they happened to be at their lowest/weakest point in the last couple years after Cyberpunk came out and before Cyberpunk had a comeback -- and that's why they didn't feel strong enough to maintain their own engine.

Before that moment they were on top, and very recently Cyberpunk has had a sort of public redemption and a surprisingly strong long-term player base, so it feels like a shame. I still haven't seen a game in Unreal that matches Cyberpunk on high end PC hardware overall. The only game other than Cyberpunk that justifies raytracing is Minecraft RTX IMO.

Thanks for the kind words, it means a bunch to me and other devs that worked on the game!

I cannot comment to why they decided to switch to Unreal, but it is one of the reasons I left. I hope it works out for them but I wouldn't hold my breath waiting for the next game release.

Remakes make business sense. Every game is a risk.

Frankly I wish there were more remakes rather than Call of Warzone 86. So many games are deserving. Imagine getting a full-fat remake of Banjo Kazooie and Tooie.

I agree with you. And it is still hard to get it wright in order to be sold.

If you want to stand up to competition, you need a cash cow. I don't blame any independent studio to do just that. They have to balance risks.