Dying Light 2 Developer Tools

A tools programmer is part of the team focused on making the game, and the results of their work isn't the end goal. But not always.

I hadn't been on the tools team long when we were tasked to create Developer Tools — a simplified version of the editor for modders. The decision to make Dev Tools wasn't surprising since the first Dying Light had them too.

The real challenge (since "problem" is an outdated word these days) came with one of the requirements: making it possible to run mods on consoles. This isn't common because consoles are closed systems, and game mods don't fit well with that. Still, it can be done. There are solutions, like mod.io, that make adding mod support on consoles easier, and we ended up using it. Thanks to gods of the source code, I didn't have to handle the integration, but my tasks weren't much easier.

We quickly realized the biggest challenge was with resource paths. Techland's technology used different types of paths depending on where each resource came from. It could be part of the project, the engine (shared between projects), or external. In theory, virtual paths should handle this, but if a developer specified the exact location of a resource, the file system would look in a concrete spot for it. In Dev Tools mode, there were no engine files, so we had to find all the paths pointing to unavailable locations and fix them.

I had plenty of other tasks, like fixing icons and the UI, but what I'll never forget is moving files to the right places and fixing hardcoded paths in the code. I felt like a total commander with a personality, but the effort was worth it. When the Developer Tools launched, I felt even prouder than I did at the end of Dying Light 2. I still see the release as a big achievement for our tools team, though we had help from colleagues in other departments. In the end, we, the tools team, were in charge of this small launch from start to finish. It was our moment of glory and our very own product for gamers.