Performance in Stormworks can be a mixed bag. When you play with vehicles the game was designed for, it runs perfectly on the majority of hardware. The more detail, lights, and subgrids you add, the more the game struggles, because each addition is more load for a single-threaded physics solver to process, not a separate scaling problem.

Both Stormworks and Scrap Mechanic use heavily modified versions of the Bullet physics engine. Neither studio has published which branch they forked, but since both games’ physics are single-threaded and both began development before Bullet 3.x was stable, we can reasonably assume that both are built on Bullet 2.x.

The use of Bullet in Scrap Mechanic was almost entirely focused on ground vehicles, with primitive flight mechanics using thrusters, and buoyancy being a fairly recent addition (in terms of updates, not time spent waiting…). Flight has no real physics beyond thrusters providing directional force in component space; there are no advanced supporting systems like lift (Almost certainly a stylistic choice). The game does what it was built for fairly well. In my experience, wheel handling feels noticeably more responsive in Scrap Mechanic than in Stormworks, although more jittery. That is also a subjective impression rather than a benchmarked claim.

Further optimizations in Scrap Mechanic’s implementation of Bullet are seemingly nonexistent. Every single part is its own physics body glued to another, with no tricks done to simplify geometry or collision. There’s a good reason for that, however: destruction. If a vehicle in Scrap Mechanic were baked the same way as a vehicle in Stormworks, destruction would have been much harder to pull off, less satisfying, or simply impossible. The tradeoff is massive performance losses. The bigger you build, the more lag scales exponentially.

To compare performance scaling directly, I held the software environment fixed and varied only the hardware. For Stormworks, I used build v1.5.14 with 8 “Tribute Capricciosa Nuclear Power Plant” creations spawned in at the same position. For Scrap Mechanic, build 0.6.0 with 2 “tiny house concept NO MODS” spawned in.

Despite that fixed baseline, Scrap Mechanic on the first desktop (Intel Core i5-8400, RTX 3060, 8GB DDR4-2666) felt nearly identical on the second desktop (Intel Core i5-13600KF, RTX 3070, 64GB DDR4-3200), a hardware gap of around 5 years and several hardware generations. That’s quite a claim resting on a single comparison. Ideally, I’d like to have profiler numbers from both runs to back it up rather than just what I experienced, and I suggest you treat this point as anecdotal until someone runs the numbers properly.

Stormworks’ implementation of Bullet works differently. From the start, it’s been significantly faster and more scalable than Scrap Mechanic, and the most important reason is probably collision simplification. The game merges voxels into simpler, larger collision shapes (greedy meshing) so the CPU isn’t processing every block as its own physics body. That’s what makes massive creations possible without bringing the simulation to a stop, and it’s likely also why a detailed damage model isn’t. You can’t break apart a shape that was never simulated as separate pieces. The tradeoff is that Stormworks runs much better than Scrap Mechanic across the board, with much more detailed physics.

Stormworks scales better than Scrap Mechanic, but still not well, with an important caveat. For normal vehicles, the ones the game was actually designed for, moving from my i5-8400 rig to the i5-13600KF to the Ryzen 7 9800X3D/RTX 5080 build made almost no difference in physics performance. The improvements I did notice were mostly in rendering. Where the newer hardware pulled ahead was on creations so large they’re far beyond the game's scope (e.g., RMS Titanic by Icemonster360), stuff that the game was never designed to handle in the first place. This tracks: Both of the newer CPUs already have really strong single-core performance, and single-core throughput is Bullet’s hard ceiling, so going from “fast” to “faster” on a single core buys you much less than going multi-core would. For ordinary gameplay, you’re already at the ceiling.

A common misunderstanding is that Stormworks isn’t multithreaded at all; this is verifiably untrue. Stormworks Major Update 7 (31st of July, 2019) split Physics, Rendering, and Logic into 3 different chunks on 3 different threads, constrained by the slowest frame time to prevent desync. Regardless, their implementation of Bullet is not multithreaded; it just takes place on a different thread than Logic and Rendering.

Three things make multithreading Bullet in Stormworks harder than “just engineering time”: the math of the solver itself, the way Bullet’s existing parallelism works, and the physics-logic feedback loop. None of them is just about money.

The money-and-time argument is the one most people reach for, but it’s also the weakest because it’s trivially dismissible; someone will always say “just hire more developers” or “just spend more money”. So we’ll set that aside for now and talk about the interesting and more durable arguments.

Bullet 2.x’s constraint solver is mostly sequential. It works by iterating over every hinge, joint, and contact point between rigid bodies, resolving them one at a time, in order, until the error falls below an acceptable threshold. This is a Gauss-Seidel iterative solver. Each iteration depends on the result of the previous one. You can’t run step 2 until step 1 is complete, because step 2 uses step 1’s output as its input. This isn’t an implementation detail that can be “fixed”. It’s the mathematical structure of the algorithm itself.

Parallelizing a sequential algorithm isn’t just difficult. In many cases, it requires swapping in a fundamentally different algorithm that produces different results. Jacobi solvers, position-based dynamics, and XPBD all handle constraints differently and produce slightly different physical behavior under identical inputs. You wouldn’t be adding threads to Stormworks’ implementation of physics; you’d be replacing the physics math entirely with something that tries to replicate the old behavior under simple conditions but diverges greatly under complex ones.

Geometa has spent years building physics systems on top of Bullet. Fluid simulation, buoyancy, aerodynamics, temperature transfer, and more. A large number of Stormworks’ physics systems aren’t a part of Bullet; it’s custom code that sits on top of it, taking Bullet’s solver output as its input and building everything else from there. All of that custom work is calibrated against this specific solver running in this specific order. Those constants buried in the code likely weren’t derived from real physics. More plausibly, someone ran the simulation, watched it misbehave, and tweaked the values until it stopped. Either way, derived or tuned, those numbers aren’t calibrated to physics in general. They are calibrated to Bullet’s Gauss-Seidel solver and Stormworks’ specific constraint setup, producing a sequence of behavior that is unique to this codebase.

Swap the solver, and all those numbers become wrong. Not catastrophically, easy-to-spot wrong, but subtly wrong. A ship that used to float perfectly now lists under specific conditions; a crane behaves normally until its second segment hits exactly 27.5 degrees. Vehicles tuned to perfection over the years would suddenly feel slightly, inexplicably off. You'd have no way to know which of the thousands of buried tuning decisions to fix, or by how much, because the specific mathematical quirks they were calibrated against simply no longer exist. It’s like baking a cake using a recipe designed for an oven in a microwave.

Bullet's multithreading story makes this even bleaker. What parallel support Bullet does have was designed for scenes with many independent physics islands. Rigid bodies that don't interact with each other and can therefore be solved concurrently without ordering dependencies. Particles are a case where Bullet's parallel processing shines, because they're genuinely isolated from everything else.

Stormworks vehicles are literally the exact opposite of this. A large vehicle with cranes, doors, propellers, and other constraints is not a collection of independent islands, it is one giant graph where every node affects every other. There are no independent islands to give away to another thread. Splitting that constraint graph into individual problems that can be solved concurrently without corrupting each other’s state is not a solved problem in general, and it certainly isn’t solved in Bullet.

Even if you solved the solver problem and found a parallel algorithm that preserved Stormworks’ physics behavior perfectly, you would still face the problem of the simulation tick itself. Physics, logic, and fluid simulations in Stormworks aren’t cleanly separated systems. At each tick, physics outputs feed into logic (a propeller is in the water), logic feeds back into physics (the propeller in the water spins, propelling the vehicle), and so on. A propeller's output force at tick 5 depends on the logic state at tick 5, which depends on the physical state of the vehicle at tick 5. This feedback loop runs synchronously because it has to. If you spread these across threads, you introduce at a minimum one tick of latency at every process. On a vehicle with complex logic like autopilot or active stabilizers, one tick of latency in the physics-logic loop is enough to destabilize the controller enough that it just doesn’t work correctly.

So even in the best case, a successful multithreading effort leaves you with a Stormworks where the physics are subtly different, control systems on complex vehicles are quietly broken, and the entire workshop, built for a simulation that no longer exists, stops working as intended. It wouldn’t be a patch; it would be a new physics engine wearing the old game, and the community would spend years filing bug reports about what is, technically, intended behavior.

Money and time do matter here too, not as the reason this won’t happen, but as confirmation that a project already unworkable on technical grounds also fails on economic ones. At the latest, Stormworks development began in 2016. Dan Walters “confirmed” this himself in a 2022 interview, stating that over six years, they’d build Stormworks from an Early Access launch into one of Steam’s biggest vehicle-building games. That puts the codebase, including Geometa’s modifications to Bullet, at around a decade old. A codebase that old, in a domain as complex as physics simulation, accumulates technical debt. Hacks that became load-bearing, workarounds that became features, interactions nobody fully understands anymore because the person who wrote them moved on, or the reasoning behind a decision was never written down. Changing the mathematical foundation safely would require understanding the entire system well enough to predict every downstream effect, and that understanding might no longer exist, and certainly can’t be rebuilt quickly.

None of this is lazy development. Technical debt isn’t a symptom of careless engineers; it’s a guarantee of any complex, long-lived codebase, and it accumulates regardless of how good the developers are. NASA, operating with budgets and documentation standards that dwarf anything a small indie studio like Geometa could sustain, still carries decades-old legacy code in active systems that nobody fully understands, but still runs because it works, and changing it carries more risk than leaving it alone.

Meanwhile, the audience that would benefit from this is shrinking. Per SteamDB/SteamCharts, the game’s all-time peak sits just under 6,800 concurrent players, against a current 30-day average of around 1,400. That’s not a dead game; the workshop is active, there are still more updates than most games get, and the community keeps producing incredible builds, but it is a game in a slow decline, and a multi-year physics rewrite isn’t a maintenance investment; it’s a bet. Made five years ago, with a larger and more engaged player base, that bet might have been justifiable. Made now, with the player base already down roughly 80% from its peak, it’s much harder to justify. The market you’d be improving the game for shrinks every year, and the risk of breaking everything the community has built is concrete, not hypothetical.

For a studio the size of Geometa, which, from what we know, is a small team working on a project they do care about, a multi-year physics rewrite that cannot be proven to work until it is finished, cannot be shipped in pieces, will produce subtly wrong behavior on completion, and lands in a shrinking market, is not an engineering problem. It is a question of whether the studio can even survive the attempt. The technical challenge is enough of a problem, but the time and money just finish it off.