Channel 3 Entertainment on Creating the Robot Factory Builder Game Foundry

Foundry blends voxel-based sandbox building with deep factory automation systems. What were the core design pillars that shaped the game from the beginning?

Mark Laprairie: One of the big ideas from the beginning was that we didn't want to over-prescribe the "right" way to play. We wanted to give players tools, give them problems, and then trust them to find their own solutions. In a game like Foundry, that gap between the problem and the solution is basically the game.

The voxel world supports that directly. The terrain isn't just scenery. It's something players can reshape, work around, or build into their factory. You can flatten land, dig through mountains, build underground, build upward, or route production around natural obstacles, and those choices give each factory its own character.

From there, the core progression is the classic automation shift: moving from doing work yourself to building systems that do it for you. The challenge was making that feel satisfying while keeping everything readable in first person, even when factories become huge.

The game's first-person perspective sets it apart from more traditional top-down factory builders. How did that influence both gameplay design and your technical pipeline?

Mark Laprairie: First-person changes the way players understand a factory. In a top-down game, a production line can be read almost like a diagram. In Foundry, you are standing inside the thing you built, which gives the game a much stronger sense of scale and presence, but also creates a lot of usability challenges.

One of our solutions was to make the building naturally grid-based and axis-aligned through the voxel world. Freeform first-person building can become difficult to reason about very quickly, especially in a factory game where precision matters. The grid gives players a predictable structure to build from, which helps reduce that mental friction.

The perspective also gives us moments that are hard to replicate from above: walking through your factory, debugging machines through in-world interfaces, building vertically through terrain, or riding your first train across a world you reshaped. Technically, that means the game has to support both close-up detail and huge factories visible at scale, which affects everything from asset creation to rendering, streaming, and simulation performance.

The upcoming update introduces trains, which are a major milestone for automation games. What were the biggest design and technical challenges in implementing a scalable rail system?

Mark Laprairie: Trains are a big deal in a factory game because they change the player's relationship with distance. Belts are great when you're building locally, but eventually you want to reach farther: remote resource patches, outposts, larger production chains, and routes that make the world feel connected. Trains are our answer to that stage of the game.

The challenge was making them approachable without making them shallow. A player should be able to build a basic line, connect two stations, and understand what is happening pretty quickly. But the same system also needs enough depth for players who want shared tracks, larger networks, and more optimized logistics.

On the technical side, trains touch a lot of systems at once. They have to deal with voxel terrain, long-distance simulation, pathing, save/load, multiplayer, and whatever ambitious rail networks players decide to build. That last part is always the wildcard in a factory game: players will build bigger and stranger things than you planned for, so the system has to be simple on the surface but solid underneath.

Foundry takes place in a procedurally generated voxel world. How does that impact your world-building pipeline and the way you approach level design compared to handcrafted environments?

Jason Buchwitz: With every new game start, we randomly generate every voxel world using a very purposeful set of rules and parameters that apply to both gameplay and aesthetics. The algorithms used for generating the open world follow a set of guidelines that ensure players have the right balance of opportunities and challenges for building their ever-expanding factories as they progress.

Terrain, resource frequency, bodies of water, biomes, caves, and buildable spaces are all tuned to create readable, interesting problems for the player instead of just random scenery. For example, your start location is a mostly flat area surrounding your landing pod with the two main starting resources nearby to help get the player started quickly with their first small automated factory.

As players progress further into the game, they need to explore farther out into the world to find resources that present more of a challenge to obtain. They might be buried underground, blocked by mountains, or need other natural obstacles to be cleared in order to make room for more factory machines (and don't worry, you can always replant trees if you like). By now, your factory will be producing better tools that help to overcome those challenges to manipulate the world as you see fit and allow the factory to expand.  

From an aesthetic point of view, we have developed tuning parameters that allow for the generated biomes to be art-directed. Using procedural noise maps and a layering system, we can design rules for where vegetation can grow based on terrain type, caves, or underwater, as well as create natural groupings or clumps of specific kinds of vegetation to look more pleasing to the eye. It all loops back to serving gameplay by generating each unique biome with its own set of foliage parameters.

The jungles are incredibly dense with foliage, while deserts are very sparse. This offers different sets of benefits and challenges for gathering biological fuel resources (biomass) in the early game. In our game, strong level design comes from giving players enough freedom to solve problems their own way while making the world itself provide meaningful obstacles and rewards for exploration.

With team members coming from projects like Don't Starve and Oxygen Not Included, what lessons or philosophies carried over into Foundry's design and production approach?

Mark Laprairie: A major lesson from Oxygen Not Included is that players are very good at finding their own solutions. You can design the rules, but you cannot fully predict how people will combine them once the game is in their hands. That is something we try to lean into with Foundry. We want the systems to be consistent enough that players can reason about them, but open enough that different players end up with very different factories.

Another important philosophy that came from our work on Don't Starve is that depth does not always need to come from complicated individual parts. Often, the best depth comes from simple rules interacting. Making one system more complex can add something to the experience, but adding a new system that interacts with the others can multiply the possibilities.

From a production standpoint, that means we have to prototype and test systems early. A design can sound good on paper, but factory games only really reveal themselves once players start building at scale. Watching where they struggle, where they optimize, and where they do something unexpected is a huge part of the process.

From a technical standpoint, what engine and core technologies are powering Foundry, and what made them the right fit for a large-scale simulation sandbox?

Mark Laprairie: Foundry is built in a similar way to Oxygen Not Included: we have a C++ simulation library running the core game logic, with Unity acting as the presentation layer. That gives us the benefits of an established engine for rendering, tools, iteration, and content creation, while still letting us optimize the simulation layer around the specific needs of a large factory game.

The upside is a clean separation between model and view. The simulation can focus on a deterministic game state, while Unity handles how that state is represented to the player. The downside is that we are effectively maintaining two codebases that need to communicate constantly and reliably. It is a painful tradeoff at times, but it gives us the level of control we need over performance and simulation correctness.

Automation games rely heavily on systemic depth. How do you structure and maintain complex interdependent systems while keeping them understandable and performant?

Mark Laprairie: In automation games, players need to understand cause and effect. A system can be deep, but if the player can't tell why something works, or why it stopped working, the depth turns into friction.

We've learned to be careful about complexity that looks interesting on paper but doesn't actually make the game better. For example, we experimented with a more complicated modular version of the Blast Furnace, but found that the artificial complexity started to clash with what makes Foundry fun. It added more steps, but not necessarily better decisions.

That pushed us toward simplifying new mega-structures into clearer, more understandable pieces. The goal is still systemic depth, but the depth should come from how players combine systems at scale, not from every individual part being hard to parse. Performance follows the same philosophy: players will always build bigger than expected, so systems need to stay legible and efficient even when pushed hard.

Foundry supports both solo and multiplayer experiences. What were the biggest challenges in synchronizing large-scale factory simulations across multiple players?

Mark Laprairie: Because of the scale of a factory simulation, we can't send the full set of world and factory changes across the network every tick. Instead, we rely on a lock-step deterministic simulation. When players join, they synchronize the current state of the world, then each client simulates the full game locally while only sending and receiving player-driven inputs and changes.

When it works, it is very efficient. The challenge is that determinism has to be maintained extremely carefully. A single simulation bug that produces a different result on one client can cause players to desync, and then the whole experience falls apart. So a lot of the multiplayer work is not just networking code, but testing, discipline, and making sure every part of the simulation behaves the same for every player.

Early Access has been a key part of development. How has community feedback influenced major systems like trains, power, and overall progression?

Mark Laprairie: Before Early Access, we actually started on Itch.io, getting our first paying players into the game as early as possible. Community feedback is built into the game's DNA. We have a feedback system that lets players communicate directly with us, sharing contextual bug reports and comments directly in their worlds. Those reports come with a screenshot, save file, and system log that let us quickly dig into what went wrong (or sometimes right!).

Because of the size of the train update, we knew we couldn't just work behind closed doors and release it as a finished system. So we made an experimental branch and released it to some of our most dedicated players. They found hundreds of bugs, and their experiences also informed major design changes. This is a process we intend to repeat for future major updates. Maybe some designers can solve these systems perfectly on paper, but for us, iteration is where the real answers usually appear.

The roadmap mentions adding more structure and light narrative elements. How do you approach layering direction into a sandbox without limiting player freedom?

Mark Laprairie: This is one of the trickier balances for us. Foundry appeals to a wide audience, and for many, this is their first factory experience. We have tried to create a lightweight tutorial and mission system to help guide players into the experience and provide a clear direction, while ensuring it's fully optional for those who want the freedom of a true sandbox.

Many of those players have asked for stronger motivation and clearer goals, which is completely fair, but it also pushes against some of the other design pillars of the game. Who really wants to be told how to build their factory? So that's the line we keep trying to walk. We want to give players enough structure that they don't feel lost, without taking away the freedom that makes their factory feel like their own. It's an area we'll continue to iterate on.

From an art direction perspective, how do you balance the simplicity of voxel visuals with the need for readability in complex, large-scale factories?

Jason Buchwitz: The key to finding this balance was to lean into a stylized art direction. Our art style can be described as 'soft, vibrant, and cleanly illustrated'. The weathered, chipped edges of metals on our factory machines are 'clean' rather than 'dirty' with grunge and high-frequency noise. Biomes provide a soft and welcoming backdrop that contrasts nicely with the heavy, bulky, industrial look of the factory machines. The 'clean' and 'illustrated' look is what unifies everything together to create a cohesive and consistent art style across the game. 

Designing machines and buildings with unique shapes and colour palettes also helps to distinguish categories of buildings when looking over large-scale factories from a distance. Something we also consider when designing machines is how they will look and read on their own, while at the same time, potentially placed in multiple rows of hundreds. To further aid readability, we developed decorative blocks that players can use to highlight factory areas, organize production floors, or build entire enclosures around specific parts of their factory, with colours of their choosing.

Looking ahead, how do you see Foundry evolving as you move toward full release, particularly in terms of systems complexity and player-driven creativity?

Mark Laprairie: Looking toward 1.0, we keep coming back to a simple rule: respect the player's time. There are so many great games competing for people's attention now, so if someone chooses to spend an evening in Foundry, we want that time to feel worthwhile.

Foundry already has a lot in it. We've explored the design space, learned what works for our game, and learned what doesn't. So 1.0 isn't just about cramming in more features, even though we do have a few exciting things in the works. It's about making the experience we already started stronger: clearer progression, better pacing, smoother usability, stronger performance, and more satisfying late-game goals.

More depth is still important, but only when it makes the factory more interesting, expressive, or satisfying to build. Ideally, players walk away feeling like the factory they built could only have come from them.

Channel 3 Entertainment

Interview conducted by David Jagneaux