4 ms·

I think the problem with this idea is that it has to work extremely reliably, or it basically doesn't work at all. And that's inherently very difficult to achie

I think the problem with this idea is that it has to work extremely reliably, or it basically doesn't work at all. And that's inherently very difficult to achieve in a game that's based on simulating a complex system. I don't think you can retrofit an efficient closed-form model onto an existing simulation; it has to be designed in from the beginning. I suspect that's a big part of why KSP only simulates two-body conic section orbits. They knew they wanted to include time acceleration as a gameplay feature, and so they limited the simulation to closed-form orbits for which that could be implemented stably and reliably. In Factorio, a well-designed factory can be approximated by its steady-state behavior. But part of the reason it's an interesting and challenging game is that it's not always obvious how well a factory satisfies that criterion. You can have bottlenecks that only show up in unexpected conditions, or systems whose throughput depends on the details of inserter positioning, or feedback loops that switch from controlled negative feedback to runaway positive feedback when some parameter crosses a threshold. Given how easy it is for these kinds of simulations to accidentally end up being NP-complete or even Turing-complete, I'm very skeptical of the idea that an algorithm could make reliable decisions about when it's safe to "optimize" an entire factory without drastically changing its behavior. I think any game simple enough to make that tractable would effectively be an entirely different genre. (I would be pleased to be proven wrong, though!) That said, you could certainly optimize the simulation of individual components that are themselves simple enough to not have chaotic behavior. In fact, Factorio does some of this already. For example, long transport belts are simulated by tracking the position of items relative to the belt, rather than their actual coordinates. So an item's "movement" isn't simulated on every frame; only when it reaches the end of the belt, or gets picked up by something, or if you're actually looking at it. (https://www.factorio.com/blog/post/fff-176 https://www.factorio.com/blog/post/fff-176)

leetcrew 6y ago
I share your skepticism on the closed-form model. I do think there are other opportunities to optimize a sufficiently remote base though. right now (as I understand it), factorio needs to keep anything that can affect the global train state and systems connected to the same pipes, belts, or electricity grid consistent on a per-tick basis. in practice, this is basically everything. but if a remote base had its own train state and all the belt/pipe/wire connections were internal, the updates could be deferred to a more convenient time and/or offloaded to a background thread. that base would only need to be consistent when the player is looking at it or a bulk transport vehicle arrives to pickup/dropoff goods.

leetcrew 6y ago

I share your skepticism on the closed-form model. I do think there are other opportunities to optimize a sufficiently remote base though. right now (as I understand it), factorio needs to keep anything that can affect the global train state and systems connected to the same pipes, belts, or electricity grid consistent on a per-tick basis. in practice, this is basically everything. but if a remote base had its own train state and all the belt/pipe/wire connections were internal, the updates could be deferred to a more convenient time and/or offloaded to a background thread. that base would only need to be consistent when the player is looking at it or a bulk transport vehicle arrives to pickup/dropoff goods.