Rebuilding a PS2 Classic with Legacy of Kain: Defiance Remastered Devs

For remasters of classic games, the work is rarely as simple as increasing resolution, replacing textures, and shipping the result on modern platforms. In the case of Legacy of Kain: Defiance, PlayEveryWare and Crystal Dynamics had to revisit a fully custom early-2000s engine, bridge obsolete asset pipelines, modernize the game’s presentation, and preserve the original feel of one of the most beloved dark fantasy action-adventure titles of its era.

To learn more about the process behind Legacy of Kain: Defiance Remastered, we spoke with PlayEveryWare Development Lead Ryan Meyer, Senior Engineer Jina Hyun, and Crystal Dynamics Art Director Monika Erosova. The team discussed the challenges of moving the original engine from 32-bit to 64-bit, rebuilding the camera system, recovering and organizing archival materials, restoring unused content, updating character models and environments, and balancing modern technical expectations with the game’s original artistic identity.

When approaching the remaster of Legacy of Kain: Defiance, what were the biggest technical challenges in revisiting such an iconic early-2000s title? Were there specific systems or assets that proved especially difficult to modernize?

Ryan Meyer – Development Lead: The biggest challenge was that Defiance was built on a fully custom engine from over twenty years ago. It was made for the hardware of that era, so before we could even think about modern platforms, we had to go deep into the engine and rewrite significant portions of it. One of the first blockers was moving the engine from 32-bit to 64-bit. That was foundational work.

Without it, integrating modern console SDKs wasn't even an option. From there, the rendering pipeline needed attention. The original game was designed around a 4:3 presentation, so when you push that into 16:9, a lot of things break. UI anchoring, screen space effects, and camera assumptions were all built around a square frame. Fixing that meant tracking down and correcting those assumptions and making sure everything continued to render properly.

Audio was another friction point. The game relied on an extremely old version of FMOD, and getting that to function on modern platforms required a fair amount of effort. It wasn't just a drop in upgrade. We had to bridge a large gap between legacy FMOD and current FMOD and then make sure the game sounded the same as the original. There was a lot of crackling, cinematic desyncs, and buffer issues we had to resolve to get the game sound correct again.

The content pipeline was probably the most unusual challenge. There were custom internal tools used to build and edit assets, but there was little to no documentation. We had to first confirm those tools even existed, then reverse engineer how they worked. It felt a lot like code archaeology. Once we understood the pipeline, we ran into the next issue. The original assets were authored in a version of 3D Studio Max that's no longer available. For practical purposes, that toolchain no longer exists.

To get new or updated content into the game, we had to build a conversion path. That meant taking legacy data, translating it into formats that modern tools could understand, making any necessary edits, and then exporting it back into something the original engine could use. That bridging layer between old and new pipelines ended up being critical to the entire remaster effort.

What did the process of recovering and organizing the original development materials look like? Were you working from archived source code and asset libraries, or did some parts of the game require reconstruction from retail builds?

RM: Crystal Dynamics has done a very strong job preserving their archives, which made a big difference for this project. We were working from complete project materials as they existed around the original release, not trying to reconstruct the game from retail builds.

In fact, the archive went well beyond just the shipping source code and asset libraries. There was a substantial amount of pre-production material, cut content, and behind-the-scenes assets included. That gave us a much clearer view into how the game was originally built and how different systems and content evolved.

Because of that, the effort was less about recovery and more about organization and modernization. The data was all there. Having that level of archival completeness removed a lot of the risk you could potentially see on projects like this, where missing data forces you to rebuild systems or assets from scratch or try to decompile them from released content.

Remaster projects often reveal surprising artifacts from development, such as the unreleased content and "lost levels" in this remaster. Why were they not included, and how "finished" are they?

Monika Erosova – Art Director: Defiance source material surprised us with how much unused material was available. The original developers built much larger-scale levels, but these got scrapped and never completed when the story got altered. They started to redesign many forge levels from the previous game, Soul Reaver 2, but they decided to send both Raziel and Kain to explore the Citadel instead of having dedicated forge levels for Raziel.

For example, the overhead layouts and puzzle descriptions for the Water Forge specify that Raziel was required to drain the main temple room to access the Light font in the middle to open the door at the far end. However, none of these mechanics work as it was abandoned at some stage during development.

How did you decide whether to restore, document, or leave them untouched for the remaster?

ME: That is a good question, as not everything is worth including. Some level units were just single, untextured rooms with nothing in them, so we naturally skipped those. There were plenty of different test rooms, such as specific setups for breakable objects, doors, enemy spawns, etc. One room even had a giant teapot in it, don't ask me why! For the final release, we carefully curated a list that would include the most interesting levels for players to experience, such as the fabled Water Forge or the early, expanded Stronghold area, which reflected the original story layout with Raziel and Kain having the same starting point in the Chapter House as seen at the end of Soul Reaver 2. When the story was changed to take place years after that game, the Stronghold layout was reworked and completely retextured.

From a tooling perspective, what software or internal tools were used to bring the original assets up to modern standards? Did you rely on custom pipelines to convert legacy formats into contemporary engines or editing environments?

RM: From a tooling standpoint, most of what we used was custom-built to sit alongside, or directly inside, the original engine. The goal wasn't to replace the engine, but to extend it in a way that made it compatible with modern platforms. On the rendering side, we leaned on our familiarity with Gen 8 and Gen 9 hardware and implemented custom rendering backends that could work cleanly with Defiance.

That included adding both DirectX 11 and DirectX 12 so we could release on GDK while also keeping the min spec in parity with the previous Soul Reaver remasters. On the asset side, the key piece was building the conversion pipeline. Once we had that in place, we were able to carry forward most of the original rigs and animation data.

That was a major win. It meant we could upgrade character models to HD quality while still using the original animation sets, instead of having to recreate everything from scratch. Reauthoring animation at that scale would have been prohibitively time-consuming, so preserving that data was essential to the remaster.

Many early PlayStation 2 era games relied on heavily customized engines. What did the original technology stack for Defiance look like, and how compatible was it with modern workflows when starting the remaster?

RM: The original tech stack for Defiance was a fully custom engine, which was pretty standard for PS2-era games. Going back into something like that really makes you realize how much we take for granted now (or at least how much I take for granted). A lot of the systems you'd expect to just exist in something like Unreal Engine or Unity simply weren't there, so anything new had to be built from scratch.

A good example is the camera. The original game used a fixed cinematic camera, which looked nice but didn't give the player much control and could be a bit disorienting at times. We wanted to modernize that with a proper third-person camera. In a modern engine, that's a solved problem. Drop the camera object into the scene and bingo bango, you're done. Here.. not so much.. We had to implement the whole system ourselves from scratch.

I don't know if you remember, way back in school, in math class, thinking.. When am I ever going to use this in real life? Here. Here is where you use it. All of it… and more. This is one of those moments where all that you learned years ago matters again.

Once we had the new camera working, it highlighted another issue. The original game had a first-person mode, but it was disabled in a lot of areas. With our camera, that meant you'd suddenly get forced back into the original cinematic view when entering one of those areas. That felt pretty jarring. So we made the call to remove those restrictions so the player could stay in the third-person camera the entire time.

That opened up another problem. Now players could look into areas that were never meant to be seen. A lot of it looked like you were on the wrong side of a movie set backlot. There were one-sided walls, missing floors and ceilings, and half-finished rooms. To fix that, we had to go in and build a lot of new geometry and textures to fill in those gaps. And it wasn't just about
making it HD. It also had to match the original look, so it didn't feel out of place.

The player can toggle between original and HD graphics at any moment, so we had to make both. This was a hefty amount of work, but we felt it had to be done to make the game feel right. As far as modern workflows go, there really isn't much overlap. The engine wasn't built to plug into modern tools or pipelines, so instead of adapting the engine to modern workflows, we were mostly adapting our workflows to fit the engine.

Jina Hyun – Senior Engineer: The camera was something I spent a lot of time on. When I first started, the existing camera code was so large that it was hard to fully understand. I initially tried to modify it to build the new camera on top, but after about a week or two, it was clear that it was not going to work. So I scrapped it and rebuilt the remastered camera from scratch.

Even then, it was not straightforward. The engine's internal camera system used transformations that worked differently from the standard approaches I had studied, so I could not apply the same foundations I was familiar with. Because of that, when I first got the camera moving, the rotation was not behaving correctly with mouse input, and it took a while to figure out why. The first milestone was pretty rough as a result, to the point where the camera was barely playable.

But once I understood how the engine expected things to work, it finally started to work as intended. Building the camera from scratch also meant handling a lot more than just moving and rotating from player input. Collisions with the environment had to be implemented. The breakable wall and door collision was particularly tricky since there was no clean way to identify exactly which objects the camera should collide with.

The approaches ended up being more iterative, starting with a rough set of conditions and then refining them whenever a new case came up during playtesting. It was a lot of trial and error overall, but the camera ended up covering everything it needed to, and I am happy with where it landed.

When updating character models, environments, and textures, how did the team balance preserving the original artistic intent with taking advantage of modern rendering techniques?

ME: Defiance had quite a different artistic approach in comparison to Soul Reaver 2. They redesigned pretty much everything, from the environments and enemies to the main characters. For example, there are more vampire hunter classes in Defiance, but their faces are more like caricatures, so we tried to mitigate it by giving them improved facial features while still staying faithful to the original forms. We also diversified the looks of the female vampire hunters, which were mere recolours and head swaps between the two classes.

For the textures, we primarily focused on finding the source photos that the original team used, so when you click the button, it is a seamless transition between SD and HD modes. I am super proud of our team for being able to stay faithful to the original texture work, thanks to the amount of texture research we put into this project.

How did the team approach performance optimization for modern platforms while still preserving the feel of the original combat, camera systems, and traversal mechanics?

RM: When you go this far back for a remaster, you actually get a decent amount of headroom to work with, so performance isn't the primary constraint in the same way it would be on a new title. That said, it's not something you can ignore, especially once you start pushing higher fidelity assets. We were bringing in HD models and higher resolution textures across the board, which immediately increases memory pressure and streaming cost.

On more capable platforms, that's manageable, but on something like Switch 1, it becomes a real consideration. File I/O is relatively slow, and memory is tight, so you have to be more deliberate about how and when data is loaded.  A lot of the work there was around making sure we weren't introducing new bottlenecks. That meant being careful with asset sizes, making sure streaming behavior was predictable, and avoiding situations where we'd stall on loads.

We didn't need to fundamentally change systems like combat, camera, or traversal to hit performance targets, which was important since preserving the original feel was a priority. So the approach was less about aggressive optimization passes and more about staying within the constraints of each platform as we upgraded the content. As long as we respected those limits, we could improve visual quality without compromising how the game actually plays.

For developers interested in preservation and remaster work, what lessons did the team learn from revisiting Legacy of Kain: Defiance that might help others working with legacy codebases and aging asset pipelines?

RM: A big takeaway from working on Defiance is that you're working on a snapshot of how games were built at a very specific point in time. The tech, the assumptions, and the workflows all reflect that. You have to approach it with that mindset, or you'll end up fighting the project instead of making progress. One of the first lessons is to respect the original constraints. A lot of the code and data might look strange or inefficient by modern standards, but it was usually written that way for a reason.

If you try to aggressively "modernize" everything up front, you can break more than you fix. It's often better to get the original behavior working as is, then make targeted improvements where they actually matter. Another big one is tooling. You can't assume the original pipeline is usable, or even complete. In our case, a lot of the effort went into rebuilding or bridging the content pipeline so we could move data between legacy formats and modern tools. Investing in that early pays off because every asset or system you touch depends on it.

Documentation, or the lack of it, is also a real factor. You should expect to spend time just figuring out how things work. That means reading code, testing assumptions, and sometimes building small tools just to inspect data. Treat it like reverse engineering, because that's effectively what it is. There's also a practical lesson around scope. It's very easy to underestimate how changes cascade in a legacy project. Something that seems small, like adding chapter select, extra checkpoints, or a minimap, can end up requiring new content, new logic, and a lot of follow-on work. Be disciplined about what you change and keep in mind why it's important.

Finally, preserving the feel of the original game should guide decisions. Modern hardware gives you room to improve visuals and stability, but if you change timing, responsiveness, or player feedback, it stops feeling like the same game. The goal isn't to rebuild it as if it were made today. It's to bring it forward in a way that still feels like the original experience.

ME: While inspecting the original code and script, having comments in several places helped us so much in understanding how the event and other game systems worked. When editing the scripts myself, I also tried to keep the same scripting style as the original devs for easier reading and made sure to separate the newly added sections clearly.

PlayEveryWare and Crystal Dynamics

Interview conducted by David Jagneaux