Bug Tracking for Automation and Factory Games

Automation and factory games simulate thousands or millions of moving items across belts, inserters, and machines, and their bugs scale with the factory. An item backs up on a belt that should be balanced, a machine starves despite full inputs, a throughput calculation drifts, or the simulation rate quietly collapses as the factory grows past a certain size. These bugs are properties of scale and topology, so a ten machine test factory will never show them. This post covers what breaks in belt and machine simulation, why performance is a first class bug class here, and how to capture the factory state that lets you reproduce it.

Belt and machine simulation at scale

The heart of a factory game is a simulation that moves discrete items along belts and through machines every tick. The logic bugs hide in the edge cases of that movement: a junction that distributes unevenly under a specific load, items that compress wrong when a belt backs up, an inserter that grabs from the wrong lane, or a machine that reports full while its output is actually blocked downstream. Each is a small flaw in item flow that only surfaces when the surrounding topology pushes that exact case.

Because these are flow bugs, the symptom is far from the cause. A player reports that a factory stalled, but the stall is downstream of a junction misbehaving three screens away. The report cannot just say production stopped. It has to carry the state of the belts and machines in the affected region, the item contents and positions, and the connections between them. The bug lives in the topology, and you can only see it if the topology and its contents come with the report.

Throughput and the math that drifts

Factory games are ultimately about rates, and a whole class of bugs is throughput that does not match what the numbers promise. A production chain that should sustain a clean rate falls short, a machine runs at a fraction of its rated speed for no visible reason, or a balancer that is mathematically perfect delivers unevenly in practice. These are infuriating to players who have done the math, and they are subtle to debug because the simulation is technically running, just not at the rate the design implies.

Pinning these down means capturing the actual rates, not the theoretical ones. The real input and output rates of the affected machines, the belt saturation, the buffer levels, and the recipe and module configuration let you compare measured throughput against expected and find where the chain loses its rate. A report that says this build is too slow is an argument. A report that carries the measured rates and the configuration is a diff you can compute, turning a throughput complaint into a specific number that is lower than it should be.

Performance is a real bug class

In a factory game, performance is not separate from correctness, it is a core feature, because the late game is defined by how large a factory the simulation can sustain. A drop in update rate as the factory grows is a bug that ruins the exact endgame players are working toward. These degradations are deeply tied to factory size and composition, so they are invisible in a small test and only emerge in the kind of mega-base that takes a player a hundred hours to build.

That makes performance reports require performance context. Capture the current update rate, the entity counts by type, the active item count on belts, the time spent in each simulation phase if you profile it, and the hardware. A report that the game runs slowly is useless without knowing whether the player has fifty thousand inserters or five hundred, and whether the cost is in belt movement or pathfinding or rendering. With that context a vague slowdown becomes a specific phase consuming too much time at a specific scale, which you can profile and attack.

Grouping by simulation fault and scale

Players build wildly different factories, so the same junction bug or the same performance cliff arrives wrapped in completely different layouts. Triaging by the surface symptom scatters one bug across many tickets. Grouping by the underlying fault, the specific junction case or the specific simulation phase that is too slow, collapses the divergent factories into one issue with a shared cause, and the topology and rate data in the grouped reports reveals the common trigger.

Counts keep performance and logic bugs in proportion. A throughput bug that costs anyone using a common balancer pattern a few percent affects far more players than a rare stall that needs an exotic layout, and a performance cliff that hits every late game factory is a higher priority than a cosmetic belt animation glitch. Occurrence counts on grouped issues tell you how many factories each fault actually reaches, so you fix the flow and rate problems players keep building into rather than the rarest curiosity.

Setting it up with Bugnet

Bugnet lets a factory game capture the state that explains its bugs. The in-game report button snapshots the affected region when a player flags a stall or a slowdown: the belt and machine state, item contents and positions, the connections, the measured input and output rates, the entity counts, and the current update rate, all as custom fields and attributes. Instead of a complaint that production stopped, you receive the topology and rates needed to load the factory and watch the flow break exactly as it did.

When the simulation throws during a tick, crash reporting captures the stack trace with the same factory context attached, so you know which phase faulted and at what scale. Occurrence grouping folds reports that share a fault into one counted issue, so the performance cliff every mega-base hits rises above the rare exotic stall. You filter by factory size, update rate, or any custom field, prioritize by count, ship the fix, and confirm the throughput or performance fault stops recurring, all from one dashboard.

Test at scale and watch the rate trend

Studios that ship factory games successfully test at the scale players actually reach, because the bugs that matter only exist in factories far larger than a quick test build. Keep large reference saves and run them every release to catch performance regressions, and make sure your report capture includes the factory snapshot and update rate even in release builds. A simulation that performs fine in your test but collapses in a mega-base is a simulation you have not really tested.

Watch the update rate trend across builds the way other teams watch crash counts, because a quiet drop in simulation performance is a regression that no error log will ever surface on its own. A cluster of slowdown reports from large factories right after a patch is your earliest signal that an optimization regressed. A factory game that captures the topology, the measured rates, and the update rate, and groups by fault, turns its own staggering scale from an opaque performance mystery into a factory you can load, profile, and fix.

Factory bugs are properties of scale and topology. Capture the region state, the measured rates, and the update rate, and group by fault so you can load and profile the factory that broke.