REDengine, Chrome Engine, Snowdrop: What Three Custom Engines Teach Us About Porting

When a studio tells me their game runs on a custom engine, the next sentence is usually an apology. "It's our own tech, so it's probably more complicated." Sometimes it is. But a custom engine isn't automatically a problem for a port - it's just a different set of questions.

The best way I know to explain those questions is to look at engines everyone has heard of. So in this article I'll compare three well-known in-house engines - CD PROJEKT RED's REDengine, Techland's Chrome Engine and Ubisoft Massive's Snowdrop - through one lens: what happened when the games built on them went to new platforms, especially Nintendo's.

None of these are our engines, and we didn't work on the ports described below. Everything here comes from what the studios and porting teams have said publicly. But each story maps almost perfectly onto a challenge we see in custom-engine projects of every size - from big AAA tech to a small team's homegrown framework.

The three engines at a glance

Before the details, here is the short version:

Now let's look at each one.

REDengine: when a game is bigger than the console

REDengine is CD PROJEKT RED's in-house technology, first used for The Witcher 2: Assassins of Kings in 2011. Later versions powered The Witcher 3: Wild Hunt and Cyberpunk 2077 - two of the most ambitious open-world games of their generations.

The port: The Witcher 3 on Nintendo Switch

In 2019, The Witcher 3 came to Nintendo Switch as the Complete Edition, with both expansions included. The port was developed by Saber Interactive in close cooperation with CD PROJEKT RED, which was busy with Cyberpunk 2077 at the time.

What makes this port such a good case study is how honest the porting team was about the starting point. According to Saber, the first pass of the game on Switch:

• ran at around 10 frames per second,
• used roughly 50% more memory than the console had,
• and the build was about 20 GB larger than the biggest Switch game card.

The team had to rethink shadow rendering, vegetation and levels of detail - and, interestingly, they also had to roll back some changes because they altered the character of the game too much. The final version ran at around 540p to 720p, mostly at 30 fps, and was widely praised as one of the most impressive ports on the system. According to Saber, it didn't require creating new assets.

What it teaches about custom-engine ports

Budget memory and storage before anything else. On PC, a game can usually assume plenty of RAM and disk space. On a console - and especially on a handheld - those are hard limits. In a custom engine, the code that decides how much memory a texture, a mesh or a streamed level uses is your own code. That's good news, because you can change it. It's also bad news, because nobody else has already optimized it for that platform.

Keep the game's identity while you cut. The detail about rolling back changes is the one I mention most to studios. Every optimization is a trade-off, and some trade-offs change how a game feels. A port has to protect that feel, not just the frame rate.

The epilogue: Cyberpunk 2077 and Unreal Engine 5

REDengine's story has two more chapters worth knowing.

Cyberpunk 2077 launched in 2020 with well-documented performance problems on PS4 and Xbox One. Years later, it arrived on Nintendo Switch 2 as a launch title in June 2025 - and CD PROJEKT RED said the port was "not a gigantic effort", partly because it could build on the optimization work it had already done for those older consoles. Targets were 1080p docked and 720p in handheld performance mode, with gyro aiming, mouse and touch controls on top.

And in March 2022, CD PROJEKT RED announced that its next Witcher game would be developed in Unreal Engine 5, in partnership with Epic Games. The studio's CTO said openly that they had spent a lot of resources and energy evolving and adapting REDengine with every release.

The lesson: optimization work is never wasted - the effort spent on weaker hardware made the Switch 2 port much easier. And owning an engine has a real long-term cost. Even one of the strongest technical studios in the world decided it was worth moving to a commercial engine for future projects.

Chrome Engine: a port is more than performance

Techland's Chrome Engine has a long history - it first appeared in the early 2000s and went through several generations. Chrome Engine 6 powered Dying Light (2015), a first-person open-world game built around parkour, physics and dense crowds of enemies. For Dying Light 2 Stay Human, Techland moved to a new generation of its technology, C-Engine - a transition the developers have described as difficult but necessary.

The port: Dying Light on Nintendo Switch

In 2021, Dying Light: Platinum Edition came to Nintendo Switch, bundling the base game with The Following expansion and a set of DLCs. A demanding first-person game on hybrid hardware is a technical challenge on its own. But what stands out about this port is the list of Switch-specific features it added:

• motion controls,
• touch screen controls,
• HD Rumble,
• local co-op.

The sequel took a different route: Dying Light 2 came to Switch as a cloud version, streamed rather than running natively on the console.

What it teaches about custom-engine ports

A port is a product decision, not just a technical one. Getting the game to run is step one. Making it feel like it belongs on the platform - with the controls, haptics and play modes that platform's players expect - is step two. In a custom engine, every one of those features has to be wired into your own input, UI and rendering code. There's no plugin to download.

Sometimes native isn't the only answer. The cloud version of the sequel is a reminder that a platform strategy can mix approaches. For most of the studios I talk to, a native port is the right call. But the decision should be made deliberately, with the trade-offs on the table - not by default.

Engines have generations, too. Moving from Chrome Engine 6 to C-Engine was a major step for Techland. If your own engine has been through a few generations, the version your game uses matters a lot for a port - it decides which platform support, tools and people are still available.

Snowdrop: one engine, very different games

Snowdrop is Ubisoft's in-house engine, developed by Massive Entertainment. It made its public debut with Tom Clancy's The Division (2016) and has since powered games as different as The Division 2, South Park: The Fractured but Whole, Mario + Rabbids Kingdom Battle, Avatar: Frontiers of Pandora and Star Wars Outlaws.

That range is the first interesting thing about it: the same engine runs a turn-based tactics game and a large, streamed open world.

The ports: Mario + Rabbids on Switch, Star Wars Outlaws on Switch 2

Mario + Rabbids Kingdom Battle launched on Nintendo Switch in 2017, built on Snowdrop - and its developers said publicly that they were surprised by how smoothly Switch development went with the engine.

Star Wars Outlaws is the opposite end of the scale: a technically demanding open-world game, released on PC and current-generation consoles in 2024. It came to Nintendo Switch 2 on September 4, 2025, developed by Massive. Technical reviewers called the port surprising for how much of the game it kept.

There is one detail that every studio with an open-world game should know. The physical Switch 2 release is a game-key card - the card is a key and the game is downloaded. According to a Snowdrop developer at Ubisoft, the engine relies heavily on streaming from storage for its open worlds, and game cards didn't give the performance needed for the quality target.

What it teaches about custom-engine ports

A flexible engine makes ports easier - when it's built for it. The fact that Snowdrop could ship a Switch game in 2017 and a Switch 2 open world in 2025 says a lot about a platform layer designed for many targets.

Streaming and I/O can decide what's possible. Most people think about a port in terms of GPU power and memory. Storage speed is the third limit, and in an open world it can be the deciding one. If your custom engine streams data aggressively, the target platform's storage and the format you ship on become part of the technical scope - and sometimes part of the business decision, too.

What these three stories have in common

Put the three side by side and the same themes appear - and they are exactly the themes we look at when a studio brings us a game on its own engine.

1. Memory and storage are hard limits. The Witcher 3 started 50% over the Switch's memory and 20 GB over the biggest game card. Every custom-engine port begins with an honest look at how far the game is from those budgets.

2. Streaming and I/O are part of the scope. Star Wars Outlaws on Switch 2 shows that how fast data can be read from storage can shape both the technical solution and the release format.

3. Platform features don't come for free. Dying Light added motion, touch, HD Rumble and local co-op. In a custom engine, each of those has to be built into your own systems.

4. Earlier optimization pays off later. Cyberpunk 2077's work on older consoles made its Switch 2 port much easier. Every platform you support teaches your engine something.

5. The engine itself has a cost. CD PROJEKT RED moved future projects to Unreal Engine 5, citing the resources needed to evolve REDengine; Techland's move to C-Engine was hard but necessary. Maintaining an engine is an ongoing investment, and a port is often the moment that cost becomes visible.

If your game runs on a custom engine

Most custom engines we see are not REDengine-sized. They are a small studio's own framework, an engine built for one game ten years ago, or a heavily modified version of an older commercial engine. The questions, though, are the same. Here is what I'd prepare before talking to any porting partner:

• Platform layer: where does your engine talk to the operating system, graphics API, input and file system? The cleaner that layer is, the easier a new platform becomes.
• Rendering backend: which graphics APIs does the engine support today, and how much of the renderer depends on one of them?
• Memory and asset pipeline: how are assets compressed, loaded and unloaded? Can the pipeline produce platform-specific versions of textures and meshes?
• Streaming: does the game stream levels or open-world data, and what does it expect from storage speed?
• Shaders: how are shaders written and compiled - and can that pipeline target new platforms?
• Middleware and plugins: audio, physics, video, networking. Each one needs console support or a replacement.
• Tools and people: who still knows how the engine works? Documentation and the original developers' availability matter as much as the code.
• The build: can the game be built from a clean checkout, on a machine other than the one it was last built on?

None of these is a deal-breaker. Together, they decide whether a port means adding a new platform layer to a healthy engine, or whether moving the game to a modern engine is the smarter long-term option. We wrote about that second path in detail in Remaking a Game on a Custom Engine, and our glossary entries on engine migration and custom engines cover the key terms.

How we approach custom-engine ports

At LYNXBYTE GAMES, custom and proprietary engines are handled by the same in-house team as Unity, Unreal and Godot projects - and several of our specialists have worked on projects with studios like CD PROJEKT RED and Techland, so the scale of tech behind games like these is familiar territory.

In practice, a custom-engine project starts the same way as any other port: with a free technical assessment. We look at the engine, the build, the platform layer and the dependencies, and we tell you honestly whether the fastest route is extending your engine for the new platforms or moving the game to a modern engine. Our project scan helps us get a full picture quickly, and an engineer reviews every finding.

If the answer is a port, it comes with a fixed price for an agreed scope, console certification handled by our team, and three months of post-launch support - backed by our delivery guarantee.

If your game runs on its own engine and you're thinking about Switch, Switch 2, PlayStation or Xbox, send us the details. You'll get a first estimate within 3 business days - and no apology for your engine needed.

REDengine, Chrome Engine, C-Engine and Snowdrop are trademarks of their respective owners. LYNXBYTE GAMES is not affiliated with CD PROJEKT RED, Techland or Ubisoft, and was not involved in the ports described in this article.

Frequently Asked Questions

Can a game on a custom engine be ported to consoles?

Yes. A custom engine needs a platform layer for each new console - graphics, input, file system, memory and platform services - plus work on performance and certification requirements. How much work that is depends on how the engine is structured, not on whether it's custom.

What is the hardest part of porting a custom engine?

Usually memory, storage and streaming. The Witcher 3's first Switch build used about 50% more memory than the console had and was 20 GB larger than the biggest game card - typical of how far a PC-first game can be from a console's limits at the start.

Should we port our custom engine or move the game to Unreal or Unity?

It depends on the engine's condition, the platforms you need now and in the future, and who still knows the code. A healthy engine with a clean platform layer is often worth extending. A legacy engine with no maintainers is often better replaced - CD PROJEKT RED itself moved future projects to Unreal Engine 5.

Which engine did The Witcher 3, Dying Light and Star Wars Outlaws use?

The Witcher 3 runs on CD PROJEKT RED's REDengine, Dying Light on Techland's Chrome Engine 6, and Star Wars Outlaws on Ubisoft Massive's Snowdrop.

Why is Star Wars Outlaws on Switch 2 a game-key card?

According to a Snowdrop developer at Ubisoft, the engine relies heavily on streaming data from storage for its open worlds, and game cards didn't give the performance needed for the quality target.

Does LYNXBYTE GAMES work with custom engines?

Yes. Custom and proprietary engines are handled in-house by the same team as Unity, Unreal and Godot projects, starting with a free technical assessment.