Fact Sheet

Company:  Aesir Interactive

Engine: Unreal Engine 4 (later ported to Unreal Engine 5)

Platforms: Steam, XBox One, XBox Series X|S, PS4, PS5, Nintendo Switch (Outsourced Port)

Release: Nov 10, 2023

Team Size: 20-40

Systems I owned: Editor tooling for Callouts and Traffic, Border Patrol, UE5 Port (solo)

My Work

I contributed to Police Simulator occasionally before launch on topics where I had more experience than the core team, like console support and loading screens, then joined the live team full-time for the Highway and Contraband DLCs.

In-editor traffic and road-network tooling. The original pipeline generated the city's roads, intersections, and traffic data in Houdini, where it was baked and effectively hardcoded, which meant level designers couldn't author or iterate on the road network themselves. For the DLCs I built tooling that let designers set up streets, intersections, and traffic rules directly in the Unreal editor, with live previews and validation as they worked. Rather than replace the existing static Houdini data, the system patched on top of it non-destructively at edit time, so all the pre-DLC city data stayed intact and compatible. Since we no longer had a Houdini license, I had to reverse-engineer the format of the baked output, then generate matching data and layer the new road networks onto it. I also wrote a commandlet that regenerated and validated the network on CI (TeamCity), so the data could be rebuilt and checked automatically. The impact was large: the legacy Houdini pipeline took up to 17 hours to generate the base city, whereas with the editor tooling designers iterated with instant previews, and only the final bake and patch step took roughly 10 to 15 minutes.

A solo Unreal Engine 5 port. Porting the game to UE5 had been requested and evaluated several times, and I took it on as an experiment. Most of it went smoothly: fixing compiler errors, updating plugins, migrating from the deprecated PhysX to Chaos, and getting it running across all consoles. The blocker was the move from World Composition to World Partition. Epic's conversion tooling handles the cells and level itself easily, but a game that had run on World Composition for around five years had an enormous amount built specifically around it: streaming, asset optimizations sized to World Composition cells, level proxies, pedestrian and traffic agent spawning and despawning, level loading, lighting streaming, and indoor streaming. Untangling all of it turned out not to be worth the cost, so we made the call to shelve the port. The experiment was valuable in its own right: it told us precisely what a real migration would require.

Post Mortem

Moving the road and traffic setup into editor tooling was the right call, even though it meant rebuilding capability that already existed in Houdini. The time it saved designers more than paid back the duplicated work. Running the two approaches side by side, static Houdini-baked data with the editor patching on top of it, was messier than ideal, and if we were starting the project fresh today we'd skip Houdini for this entirely and author it natively from the start. That's an easy thing to say with years of hindsight the original team didn't have, but it's where I'd land now.

On the UE5 port, I'd spend far more time up front mapping how the game's systems depended on the engine before diving in. We had flagged the Houdini plugin and console support as the biggest risks and didn't seriously weigh World Partition at all, since the existing conversion commandlet made it look trivial. The real cost wasn't the world conversion itself but everything built around World Composition over years of development, which the commandlet doesn't touch. The deeper lesson is to question the value of the upgrade in the first place: it would have been a purely technical migration with no benefit to gameplay, which is a lot of effort for something players would never feel.

Fact Sheet

Company:  Aesir Interactive

Engine: Unreal Engine 4

Platforms: Steam, Epic Games, PS4, PS5, Nintendo Switch 

Release: Nov 3, 2022

Team Size: 15-20

Systems I owned: Breeding, Missions, Dialogues, River & Terrain Tooling

My Work

This was my first project at Aesir, where I worked officially as a gameplay programmer, and it's the most gameplay-systems-heavy work I've done.

Mission and dialogue systems. I owned most of the mission system. It built on the system from Aesir's Ostwind games but added support for missions running in parallel, for mission-specific resources in the world that became available only while a given mission was active, and a dialogue system that the mission system could drive directly. I also supported the outsourced content creators who used the system to author missions, which meant designing it to be usable by people who weren't engineers.

Horse AI and movement. I built the horse AI and its autonomous movement. Epic's CharacterMovement and built-in pathfinding are designed for humanoid characters and looked unnatural on a horse, so I wrote custom implementations of both to get believable locomotion and pathing, with the AI itself running on behavior trees. One of the trickier features was letting the player call their horse from any distance: the horse might be in a region that was currently streamed out or otherwise inaccessible, so the system had to bring it to the player gracefully no matter where it was in the world.

Breeding and genetics. I took over the breeding system after its previous owner left the company, with little documentation behind it. It's a detailed genetics simulation built on phenotypes and gene patterns, so I spent time reading my way into it before extending it. I added new phenotypes, made the system DLC-able so new coats and breeds could be layered on later, and added validation and automated tests. The tests surfaced a real problem nobody had caught: a number of phenotypes were impossible to produce given the existing gene-pattern setup, meaning certain horse coats could never appear in game.

Nintendo Switch port and optimization. I maintained the game's Switch port, which meant a lot of optimization across foliage, streaming, and meshes, along with managing memory and save-game size, both of which were tight on the platform.

Post Mortem

Horse Tales had a fair amount of feature creep. We had no shortage of ideas and systems, but several of them ended up shallow, barely used, and not well connected to each other. With hindsight I'd push for fewer features built deeper and tied more tightly together, where each one clearly supports the core gameplay rather than standing on its own.

Some of that traces back to direction. The game began as a sandbox and grew a mission-driven layer partway through development, so the open-ended and structured sides ended up developed somewhat in parallel rather than as one coherent vision from day one. If we'd committed to a single clear direction earlier, we could have built more deliberately around it, supported content creation even further, and chased the fun down that path instead of splitting our attention.

That said, I'm very happy with how the game turned out. It came together well and seems to have become something of a fan favorite, which is a credit to the work the whole team put in.

Fact Sheet

Company:  Aesir Interactive

Engine: Unreal Engine 5

Platforms: Steam, XBox Series X|S, PS5 

Release: Feb 6, 2025

Team Size: 15-30

Systems I owned: City Generation (Houdini + Unreal Tooling), Traffic & Pedestrian Simulation, Callout Generation

My Work

Procedural city generation in Houdini. By far the hardest part was adding elevation. The City Sample is entirely flat, and once terrain has height it cascades through everything: streets have to follow the ground, sidewalks follow the streets, and buildings, foundations, entrances, parks, parking lots, and plazas all have to adapt to sit correctly on uneven ground. Holding that dependency chain together across the whole city was the core problem. On top of elevation I added a lot the sample doesn't have: one-way streets, proper turns (the sample only models intersections, with no turns off the highway), points of interest, suburban areas, bridges, and tunnels. I also split the city into four areas that could each be regenerated independently, so a change to one part didn't force a full rebuild, and generated both a landscape heightmap and a simplified mesh version of the world for the in-game map screen.

Editor tooling for city fine-tuning. The Houdini generation was powerful but destructive, so at a certain point we froze it and I moved the fine-tuning work into editor tooling that let the team adjust the city directly without regenerating. That covered lowering sidewalks, extending streets and traffic, and adding pedestrian paths through parks and plazas.

Gameplay-reactive traffic with MassTraffic. The game's callouts and events needed to block or alter traffic on demand, so I built a volume system on top of MassTraffic and ZoneGraph. Designers could pre-place these volumes in the editor or spawn them at runtime, and each one could block or affect traffic in its area in a few ways: changing the lane annotations on the ZoneGraph so agents treated those lanes differently, detecting and redirecting traffic agents already inside the volume, or recycling agents back into the pool, rather than destroying them, when they fell within it. That let an event cleanly close a street or clear a parking lot while the surrounding simulation kept running and routed around it.

Post Mortem

This one I'm still torn on. Houdini was an understandable choice under the constraints we had: a tight timeframe, and the City Sample gave us a lot of tooling out of the box. The downside only became clear over time. Because I was modifying a destructive Houdini pipeline so heavily, with elevation and everything that depended on it, art and level design were blocked from implementing content for a long stretch while they waited on those pipeline improvements.

If I started over, I'd weigh that bottleneck far more heavily. I might still reach for Houdini, but I'd resist modifying the generation itself and instead push changes to the content side: new kits, meshes, road and building styles to move it away from the stock City Sample look, since art had to produce that content for the new areas, POIs, and suburbs regardless. The better answer is probably to take the City Sample more or less as-is and do most of the modifications as editor-side extensions on top of it. That's exactly what we shifted to after the freeze, and the difference was immediate: the content teams could work in parallel with me on the tooling instead of waiting behind it.

I'd also evaluate breaking the Houdini pipeline into smaller, more granular stages, so a designer could regenerate a single building, street segment, or park without rerunning the whole city. It's a natural extension of the chunked, four-area generation I already built, just at a much finer grain. The catch is that decomposing each piece cleanly is a lot of work in itself, so it would have to be weighed against the iteration time it would save. Either way, the underlying lesson is the same: a non-destructive, extensible pipeline that lets people regenerate small pieces independently keeps the whole team unblocked, and I'd design for that from the start.

Fact Sheet

Company:  Aesir Interactive

Engine: Unreal Engine 5

Platforms: Steam, Epic Games, PS5

Release: Mar 3, 2026

Team Size: 10-20

Systems I owned: Breeding, Mission and Dialogue Systems, Open-World (Rivers, World Partition Streaming, Day/Night, PCG)

My Work

As Tech-Art Lead on Khiimori I managed a team of four tech artists while owning a set of open-world and gameplay systems myself.

On the gameplay side I built the mission and dialogue systems. This evolved work I'd first done on Horse Tales, rebuilt to be far more designer-friendly: a dedicated editor for authoring mission trees, plus validation to catch broken or incomplete missions early, so designers could create and iterate on content without needing engineering support.

For the open world I owned the toolset: landscape generation with Errant Worlds, World Partition streaming, and a day/night cycle (first on Ultra Dynamic Sky, later migrated to Unreal's Day Sequence plugin). I also built custom spline-based river tools directly in-engine using PCG and Geometry Script, letting designers carve rivers procedurally into the terrain instead of hand-modeling them.

To speed up world-building further, I created a pipeline that imported real-world Mongolian heightmaps into Unreal as landscape brushes for Errant Worlds, so designers could lay down authentic terrain and landmarks far faster than building them by hand.

Post-Mortem

Two things, both choices that made sense at the time but that I'd weigh differently today.

First, the landscape pipeline. Errant Worlds gave us a powerful procedural landscape workflow quickly, and it was a pragmatic choice for getting the world up fast. What I'd weigh more heavily now is the cost of depending on a license-based third-party plugin: keeping it aligned with Epic's and our own coding conventions, and the fact that an engine upgrade is effectively gated on the plugin author shipping their update first, whereas with first-party or in-house tooling we can drive those upgrades ourselves. Epic's native tooling has also moved quickly in this space since we shipped, between the Landmass and open-world workflows showcased in Project Titan, and the new Mesh Terrain system Epic introduced at State of Unreal 2026 as a system for authoring complex 3D landscapes without the limitations of heightfields. Today I'd lean toward building on first-party tech and reserve third-party plugins for cases where they clearly earn the dependency.

Second, sequencing. Khiimori's world is genuinely one of its strengths, and investing early in making the Mongolian landscape and the open world feel impressive was a reasonable bet. With hindsight, I'd push to validate the core loop and chase the fun earlier and in parallel, getting missions and moment-to-moment gameplay into players' hands sooner rather than letting the world lead. Finding what actually makes a game like Khiimori fun is the riskiest unknown, and I'd want to de-risk it as early as possible.