Alan Wake Remastered: A technical vantage point

Author: by Andy Booth, dt3

This week, Remedy Entertainment and co-developer d3t launched Alan Wake Remastered, an updated version of Remedy's psychological thriller that originally released on Xbox 360 back in 2010.

Following the story starring the titular author, the original Alan Wake is a game that--although generally well-received--is often considered under-appreciated in its time. With Remastered, Remedy and UK-based d3t are hoping to find new audiences on new-gen consoles.

In an email interview with Game Developer, d3t studio technical director Andy Booth, with the help of his team, provided in-depth answers to explain how his studio addressed various tech challenges when developing Alan Wake Remastered.

Game Developer: What were some unexpected technical challenges and how did you overcome them?

There were certainly a lot of challenges, but thankfully the vast majority were not unexpected. It turns out that the original codebase was incredibly well put together -- it was written very cleanly and for the most part it was very easy to modernize, modify and extend. That being said, a few interesting technical challenges do come to mind...

The 64-bit port had some difficulties -- most of them were typical 64-bit issues, but one of the trickier parts was porting the scripting language and accompanying virtual machine. The internals of the system made a lot of assumptions about word-size, and it took a lot of debugging to flush out all the issues. Thankfully we could run the 32-bit version of the original game, so the easiest way to debug these issues was to dump trace all the commands that the virtual-CPU was executing and then spotting where they diverge.

The game has pseudo-random generation of tree positions and sizes to generate the rolling forests. After moving to a modern version of Visual Studio and going 64-bit, we noticed that tree sizes no longer matched the original positions. This is important as it impacts player sightlines and shot framing.

Jon Arden, principal programmer at d3t spent some time investigating and found that the size was randomly generated based on the least-significant bits of the floating-point position. It turns out that these positions had very subtly changed as a result of various floating-point calculations (the positions themselves were "randomly" generated based on geometry tessellation and various texture maps), and so the resulting tree sizes were completely wrong. The most robust solution was to simply bake out the original tree positions and sizes using the 32-bit version of the game editor, and then load those. This way, any tweaks to terrain tessellation would not force the trees to regenerate position and size.

The original game on PC shipped with a single "main" thread, which was responsible for simulating the game logic, and building and issuing all the rendering commands. When moving to DX12, we knew that multithreading the rendering was going to be essential to minimize CPU bottlenecks. Simon Brown, technical director at d3t spent a lot of time refactoring the engine to support multithreaded command buffer generation. This was a significant piece of work, because the original renderer had quite a lot of static state, particularly in the way that shader constants were managed, which was really problematic when going wide.

Skinning in the original game was done in the vertex shader -- an approach very typical of games of that era. This presented a few challenges for us -- we were increasing the number of bone influences, and each skinned object ran through a surprisingly large number of passes, which meant calculating skinning data several times for each object, per frame. We moved all of the skinning to compute, so that it only happened once per frame which helped a lot. After doing this, we got a tip-off from one of our external partners that it's quicker on some hardware to issue this skinning in a vertex shader, rather than compute! So, depending upon what hardware you're playing on, the skinning might be happening in a vertex shader or compute.

When remastering this game, what were your primary goals and guidelines?

In terms of primary goals, the main thing was staying true to the original intent. The original game was incredibly well put together and it was important that we built upon those foundations, rather than fundamentally changing them and ending up with something that wasn't Alan Wake.

In terms of gameplay changes, we decided early on that they'd be very light on the ground. Some people bemoaned the fact that Alan doesn't have much stamina for example -- and it would have been very easy for us to change that, but doing so would have changed the pacing, significantly impact combat amongst many things and moved away quite significantly from the feeling of the original game. It is important to remember that Alan is not a superhero -- he's an ordinary guy, so the lack of stamina is essentially a conscious design decision. We did however make some very small tweaks to some very minor gameplay niggles, including tweaking the vehicle cameras and adding some new control schemes. These should be seen as purely additive and shouldn't take anything away from the original experience.

Source: AlanWake.com

Source: AlanWake.com

From a technical point of view, the same pillars remain. An important part of the development process is understanding the original technical intent, and making sure that any changes you make don't break any of the existing systems. Picking our battles was massively important, and we only touched systems we needed to.

We had a total of eight optimization targets--Xbox One, Xbox One X, PlayStation 4, PS4 Pro, Xbox Series S, Xbox Series X, PS5 and PC. From the outset we knew that we wanted to provide 60fps support for everything other than the Xbox One and PS4, so a lot of time on the project was spent making sure we could achieve that target and provide a consistent and stable experience for players.

More than a decade ago, a Remedy animation programmer wrote an excellent article about the cloth simulation of Alan Wake. Did adapting this for new gen cause any issues or were the main problems solved in the original?

We decided to maintain the original cloth simulation because it still holds up well, and the movement of Alan's jacket is quite recognizable. Adapting it didn't cause us any specific problems, we just had to be careful to maintain the very specific structure of the original jacket. 

We encountered issues with the jacket behaving unrealistically, and ultimately these were down to export problems, primarily complicated by coordinate space differences between 3ds Max/Maya. There were also some specific issues in cinematics, which were more apparent when rendered at higher resolution, however, we dealt with these on a case-by-case basis

The jacket rig from the original Alan Wake

I read in a couple places that the lighting, fog, and foliage in particular were some areas that needed a good amount of work. What exactly did you encounter here and how did you solve it?

Although the lighting model hasn't fundamentally changed, the way materials react to lighting has changed quite significantly. From the outset we discussed Physically Based Rendering (PBR) but it was off the table--it was just going to be a huge change, and it would have been very difficult to stay true to the original look. So instead of using PBR, we decided to improve the materials for every object within game--primarily by adding specular to everything and normal maps to those objects which did not have them. We also added completely new shaders too, including a sub-surface scattering skin shader and an anisotropic hair shader.

Fog was again left largely unchanged, but we added a new volumetric lighting system which is layered over the top to add some additional depth to the scene.

The foliage within the original game was not properly lit -- it was using something called Precomputed Radiance Transfer (PRT). For the remaster, foliage is now properly lit which means that it now sits in the environment and reacts more appropriately to light. Additionally, the movement of the foliage has also been tweaked. The wind in the original game was essentially just noise, which was modulated depending on how stormy it was. We decided to enhance this by adding some directionality and gusts which helped add a level of realism and broke up the noise.

Source: d3t

What role did the original game assets play in the remaster? And did you run into problems in retrieving old assets?

The original archive from Remedy Entertainment was extremely organized which helped massively. We did experiment with some “automatic" upressing tools using AI, but the results just were not to the high standards that we wanted, and it didn't help us when we knew we needed to generate brand new normal or specular maps. Assets were therefore categorized by importance and improved on a case-by-case basis. This ranged from generating a new texture set, all the way to a geometry rebuild.

The cinematics pipeline was trickier. The cinematics were rendered in-engine but then composited in Adobe AfterEffects. The main issue here was that when the videos were originally rendered it was very much a manual process. Certain shots had been rendered with very specific engine settings for things like near clip planes, and draw distances, but also more dramatic things like geometry temporarily being removed or moved. These were done ad-hoc at the time of the original renders, so most of this history is lost. However, in some cases the original videos were rendered before the game was finished, and final polishing of the game subtly changed things -- meaning that when we came to render our cutscenes, the camera shots were no longer looking quite right!

Our approach was to automate the rendering of cutscenes, so we built a new cinematic control system which had the ability to apply these ad-hoc settings for individual camera shots. Then it was just the difficult process of spot-the-difference between our renders and the original videos so we could work out what things we needed to change. There is over an hour of cutscenes, made up of nearly 900 individual camera shots and these all needed analyzing for discrepancies.

What kind of work and consideration went into remaking the UI?

The UI was treated with a very light touch -- the main focus was really on making it work well at 4k and giving it a very light modernization. In the original game, the UI did not scale properly at resolutions greater than 1080p. This was the first thing that we solved. Art Director at d3t, Anthony O'Donnell then spent a lot of time working with Janne Pulkkinen, one of the art directors at Remedy, enhancing the look-and-feel of the UI to freshen it up, whilst maintaining the original style.

I see that Alan's character was completely updated. What was the process there? Were there guidelines to follow? Was there a lot of back and forth between Remedy and d3t when reimagining him? 

Alan, like the rest of the characters was remade with current techniques to update him visually. This meant generating higher fidelity sculpted elements such as his hoodie and jacket to capture finer details. Textures such as normal maps for the clothing and transmission textures for the skin shader were derived from the higher resolution models and applied in-game via updated shaders.

Hair was recreated to be of a higher quality too for characters. Hair is now comprised of a larger number of hair cards, which are rendered in game with a new hair shader.

Source: AlanWake.com

A large part of the character updating process was to assess the original artistic direction and execution, against the original photo reference of the cast back in 2010 in costume provided by Remedy Entertainment. This process involved back and forth communication with the team at Remedy Entertainment who advised us throughout the Remastering process at different stages providing valuable insight. Where appropriate elements were refined to better represent the original photographic reference, for example the material definition of Alan's clothing.

For Alan specifically, a larger decision was to go with the likeness of the actor Ilkka Villi who portrays Alan Wake. Remedy wanted to bring consistency to the game as Alan shows up in live action segments and the original games character model didn't match very well with how the actor looks. So that was updated.

In terms of constraints as it is a remaster the original animation rig is still used. This meant elements such as the location of weapon attachment points needed to be preserved. Alan's interaction with items such as panels, buttons and vehicles all had to remain the same as it was in the original. This meant the geometry of his body had to keep to the original dimensions and volume of the original Alan Wake character model to not break any of these dependencies.