Benjamin Larsson

Hearts of Iron IV already had a game binary syncing setup when I joined the project. We ported its Python application to Go. I helped with the port, and my focus was the GUI: a cross-platform frontend that I spearheaded, built using an AI-native, agentic workflow.

The problem

The Python application was complex to maintain, and Python’s handling of dependencies and environments kept causing issues for developers. The shell scripts that came before it were hard to approach for many users.

The tool

The Go version has a shared library with the core functionality, which we built together and which both the CLI and the GUI use. The core tool interfaces with Azure Blob Storage to resolve builds: it syncs binaries and fetches builds by branch, commit or merge request.

My part

• Helped port the Python application to Go.
• Spearheaded the GUI for Windows, Linux and macOS, built with Go, Wails and SvelteKit.
• Built the pipeline tracking, which starts and tracks the GitLab CI pipelines that produce builds.
• Built the development launcher, with launch presets that users can customize.
• Built the self-update mechanism, so I could push updates and users could choose when to apply them.

Result

Users no longer had to manage Python environments, and the tool was more accessible than the earlier shell scripts. It needed less support, and the more complex UI made features possible that weren’t before. It is now used across all internal Grand Strategy Games studios.

For Hearts of Iron IV’s development I designed a GitLab CI pipeline that decides when the game needs to be built, so builds stop piling up behind every push.

The problem

Every push to our main branches that contained C++ or other code changes started its own build.

What I built

A pipeline design around a mutex lock:

• Each protected branch has at most one build running at a time.
• While a build is running, new pushes don’t start another one.
• When the running build finishes, a build starts for the latest commit pushed since. The builds for the commits in between are cancelled.

Result

All internal game studios at Paradox Interactive decided to implement the design in their own pipelines. It cut build costs substantially, and it produced builds faster, so developers could download them sooner.

Bramble: The Mountain King ran on a custom engine, and not everyone on the team wanted to deal with compiling it or the game. I built the tooling that got both to them without that.

The problem

Everyone needed the custom engine. Artists, designers and others also needed working game binaries without compiling anything themselves.

What I built

• A sync tool on S3 object storage that distributes the custom engine to everyone and the game binaries to the people who didn’t want to compile.
• Tools for automatic SDK installation and game compilation.
• CI/CD that built the game and uploaded the binaries.

Result

Developers could be set up in our development environment faster. Non-programmers saved the time they would otherwise have spent compiling a lot of code.

Some of our releases were problematic. After each one I wrote an analytical report on what had gone wrong, and those reports showed problem areas in how we communicate.

The problem

We did not gather the whole group of stakeholders and other important people until very close to release.

What I did

I introduced a Release Kickoff for every release: a shorter meeting with everyone involved in that release. It exists to:

• Hash out issues early.
• Make sure everything that still needs to be done is a known-known.
• Make sure nothing falls between the chairs.

What mattered

A kickoff meeting sounds trivial, and it is. The valuable part was identifying the problem: that our releases kept going wrong because of how we communicate.