Dev Deep Dive: Under the Hood of Modulus

[h3]In our last Dev Deep Dive, we looked at how community feedback has directly influenced the design of Modulus, from simplifying the furnace to improving drones and operators based on player suggestions. This time, we’re going a bit deeper into the technical side of things.[/h3][h3]We sat down with the team to talk about how some of Modulus’ player-facing systems actually work behind the scenes, from Efficiency View to saving and loading massive factories, and even what it takes to bring a brand-new operator to life.[/h3][p]Jarvs (Head of Comms): Let’s start with something a bit technical:[/p][p][/p][h3]How does the Efficiency View actually work under the hood?[/h3][p]Thomas (Senior Tech Artist): It’s honestly much simpler than people might expect. We just look at the last ten operations and average whether they succeeded or not. That’s the whole system.[/p][p]One small tweak we added later is that it starts at 100% efficiency, because we assume players know what they’re doing when they first build something. From there, it gradually adjusts down if the system isn’t running efficiently. It’s a tiny touch, but it makes the feature feel smoother and more forgiving.[/p][p]Mick (Lead Developer): What about that flashing red when something isn’t working, is that intentionally painful?[/p][p]Thomas: \[laughs] Absolutely. Years of psychological research went into finding the perfect shade of migraine-inducing red.[/p][p][/p][p][/p][p]Jarvs: Okay, next question:[/p][h3]
How do you handle saving and loading big factories quickly?[/h3][p]Rimme (Senior Engineer): The short answer is: we prioritise stability first, speed second. Our main goal has been making sure saves always work correctly, even across versions. We’ve built systems that convert older save files to newer formats, which has been a big focus leading up to recent playtest updates.[/p][p]A few playtesters have already been helping us test extreme saves, the ones that really push the system. For now, a short loading screen hasn’t been a problem, so we’re focusing on reliability rather than optimisation.[/p][p]Thomas: There’s also a lot of work behind making sure that when you load a factory, everything runs exactly as it did before. Conveyors, operators; they all need to resume in sync. That’s harder than it sounds![/p][p]We did have a moment once where loading took over two minutes… and it turned out the grass system was the culprit. Every single blade of grass was checking every operator on load. That one got fixed fast.

[/p][p]Mick (Lead Developer): What’s cool is how lightweight the save files are now. Everything you place in the game, every operator, conveyor, or building, has its own little data entry. It’s all text-based, super compact, and surprisingly efficient for how large factories can get.[/p][p]We could optimise it further down the road, but right now, it’s performing well enough that we can focus elsewhere. If players ever build truly gigantic factories that push it to the limit, we still have options.[/p][p]Thomas: Exactly. It’s all about priorities. If nobody’s complaining, that’s usually a good sign that we can keep focusing on the features people are shouting about.[/p][p]Jarvs: Let’s finish this section by walking through:[/p][p][/p][h3]How a new operator actually gets made, from concept to in-game.[/h3][p]David (Game Director): The philosophy behind Modulus is that we don’t need dozens of operators doing wildly different things. Instead, we focus on a few powerful, versatile ones. Most operators fall into basic categories like cutting, stamping, or assembling; fundamental actions that can combine in endless ways.[/p][p]When we prototype a new one, I’ll usually start with a simple text description or a quick sketch. We build the logic first, just to see if it works with the rest of the system. If it does, it moves into internal testing. If it passes that, we add a proper model, optimise it, and make sure it meaningfully expands what players can do.[/p][p]If it doesn’t open up new possibilities or create new problem-solving options, it doesn’t make the cut. Everything needs to fit naturally with the existing toolset.[/p][p]Mick: That’s what makes it powerful. The system is flexible enough that we can prototype new operators really quickly, sometimes in a single day. Once you’ve built that foundation, adding new functionality becomes surprisingly straightforward.[/p][p]One of my favourites was the scrapper. Early on, it was literally just a black cube that made things disappear, no art, no effects, just delete-on-input. But it worked, and that made it easy to expand into the full system we have now.[/p][p]And of course, we have a long list of wild operator ideas we’d love to add someday. The fun part is knowing the system can handle them when the time comes.[/p][p]\[Editor Jarvs here, don’t worry guys I will get this list out of them at some point][/p][p]From efficiency systems to save logic, the tech under Modulus is full of clever solutions hidden beneath the surface. Every feature, no matter how simple it looks on screen, has been shaped by iteration, feedback, and the team’s obsessive drive to make things just work.[/p][p]In the next part of our Dev Deep Dive we’re going smaller. Literally. We asked the team: what’s one small detail in Modulus you’re most proud of? Hit that follow button on the game’s store page so you’re notified when we drop the answers to that question and more. Every follow the game gets, helps Steam recognise that people are excited for Modulus.[/p][p]Don’t forget to wishlist the game whilst you're there.[/p][p]
[/p][p]Catch you soon Module Makers.[/p]

• [p]Team Happy Volcano. [/p]