Marvel's Guardians of the Galaxy - Encore Edition

Marvel's Guardians of the Galaxy - Encore Edition is the Nintendo Switch 2 port of Marvel's Guardians of the Galaxy, originally released in 2021.

With the launch of the Switch 2 on the horizon, the idea of a native port came up internally as a way to give the game a second chance after extremely positive reception overall of the game (even though it wasn't a commercial success), but also the lukewarm reception of its Switch 1 release. That version was a cloud edition: the game ran on remote servers and was streamed to the console, and even then, performance was far from ideal.
The Encore Edition was our opportunity to bring the game to Switch 2 as a fully native title, with no cloud dependency and solid performance.

The game runs on Dawn, Eidos-Montréal's in-house engine, which also powered Deus Ex: Mankind Divided. Dawn is derived from Glacier 2, the engine IO Interactive uses for the Hitman series and, more recently, 007 First Light.

This was my first time working with a proprietary engine. The first steps were a bit rough — sparse documentation, a large and sometimes messy codebase — but I came to see it as a genuinely impressive piece of technology. Until then, I had mostly worked with Unreal and Unity, both of which are monolithic engines: the tools and the runtime are tightly coupled, both in their internal architecture and in their interfaces.

Dawn takes the opposite approach. Each tool is a standalone program rather than a panel inside a single editor. Even the level editor runs as a separate process from the 3D engine, and the two communicate over sockets. This adds some complexity, but it results in a remarkably stable work environment: if the engine crashes, the level editor stays alive and keeps its state. The same goes for every other tool — a crash in the texture editor has no impact on the rest of the toolchain. I find this architecture fascinating.

My contribution

I worked on the project as a Tools Programmer, joining in August 2025, just a few months after it started. I was the sole tools programmer on the team, which was a first for me — and I won't pretend I wasn't nervous when I accepted the role.

It turned out to be a fantastic experience. I got to work on a wide variety of tasks, pick up new technologies, and have a lot of fun along the way.

FASTBuild

Before touching any of the engine's tools, my first task was on FASTBuild.

For those unfamiliar with it, FASTBuild is a C++ build system (similar to CMake, Premake or Meson) whose main strength is distributed compilation: instead of compiling everything on the local machine, it can spread compilation jobs across multiple machines on the network, significantly reducing build times.

FASTBuild's configuration language is quite limited, so over the years the Eidos teams had extended the open-source FASTBuild codebase with a number of custom features. However, when I arrived, it hadn't been updated in six years: Dawn's version was based on FASTBuild 0.99, while the latest release was 1.15. In the meantime, FASTBuild had received many performance improvements.

Staying on the old version was an option, but the parsing phase at the start of every build was slow — around 6 to 8 minutes just to process the .bff files. We decided to upgrade, which meant bringing all of Eidos' custom features onto the latest FASTBuild codebase.

I started by diffing the Eidos version against vanilla FASTBuild 0.99 to identify every modification. Then, starting from the latest FASTBuild release, I reimplemented each of those features.

Why reimplement instead of simply merging? Because FASTBuild's parser was completely rewritten in version 1.00. Most of Eidos' changes relied on the old parser, so they had to be rewritten — and in some cases redesigned — to fit the new one.

The effort paid off: once the migration was complete, the parsing phase dropped from 6–8 minutes to about 1 minute 30 seconds.

Nintendo Switch 2 support in the tools

Next, I added Switch 2 support to the engine's tools. Only a handful needed changes, mainly the texture editor and the shader editor, which required new Switch 2-specific options in both their interfaces and their data. The texture and shader packers had already been updated for Switch 2 before I joined, so I didn't need to work on those.

I also integrated Sentry, which we chose for crash reporting during development thanks to its straightforward Switch 2 integration. The bulk of the work was integrating the Sentry SDK into the game itself to enrich crash reports with additional debugging information such as attachments and tags.

Build pipeline

The third part of my work was producing the final game package. Dawn uses a tool called SushiBuilder for this, and the packages it generates are called "sushis" (I never found out why).

SushiBuilder works well for platforms that share similar packaging models, but the Switch 2's is quite different, particularly for Game-Key Cards — both the file layout and the package creation process differ significantly from other platforms, though I can't go into more detail as that information is confidential. Since much of SushiBuilder's logic was hardcoded, supporting Switch 2 required substantial changes to the tool. The patch pipeline needed similar adaptations to work with Nintendo's own tooling.

Technical requirements and platform guidelines compliance

The fourth part of my work went beyond the usual scope of a tools programmer: I was responsible for making sure the game complied with Nintendo's guidelines so it could be released on the platform.

These guidelines, more commonly known across the industry as TRCs (Technical Requirements Checklists), are the set of technical and quality rules that every game must meet before a platform holder such as Sony, Microsoft or Nintendo allows it to ship on their console.

My first job was to understand, organize and triage the guidelines, since many of them didn't apply to our project. I then tested the game against them, with the help of 3 QA testers. To make the best use of their time, I folded some of the larger guideline checks into their daily test sessions rather than dedicating entire sessions to compliance testing — although some checks unfortunately couldn't be handled that way.

It was a very rewarding experience. It was my first time working with TRCs, nobody at the studio had dealt with Nintendo's requirements before, and I was the one in charge. New responsibilities on unfamiliar ground, for me and for the rest of the team alike.

Certification and submission

The fifth and final part of my work, and probably the smallest, was submitting the first version of the game to Nintendo.

This is more than just uploading files. It involves gathering and entering all the information Nintendo requires, making sure it's accurate and consistent with what's embedded in the package, verifying that the package was built with the right settings, and confirming it's the correct build — not a debug one.

Once everything had been checked and double-checked, I uploaded the package and hit Submit.

Looking back

I had a lot of fun on this project. Working in a very small team of around 10 to 12 people made for a great atmosphere. It was also a demanding project: I had to take on many things I had never done before, often as the only person responsible for them.

I left with plenty of funny stories — from the lead's Christmas carols to endless Kaamelott references (those who know, know), not to mention a few problems we solved in completely absurd ways. It remains an unforgettable experience for me.