You can just go for it and make a production chain for a product, but if next one needs same intermediates you'd be re-doing it. i.e. doing a spaghetti code.
You can section off the each intermediate into separate factory and just chain them to eachother and have relatively nice order, but when you try to expand production of everything, there is no easy way to grow that complex, so the best you can do is just copy the same block around.
Lastly you can build a rail network and put each intermediate anywhere you want without much problems, but wiring everything up will take a lot more effort, you will have to go to various places to debug any problem, any problems are less visible at first glance and lastly if you don't plan for capacity you might have bandwidth and latency problems
I can't wait for the day we can ask a general-purpose gaming AI to optimize the production line for this game, learn from it, and then backport the theories to my codebase at work.
Humans... or at least me... are so bad at this sort of multivariate optimization. Even if you cheat and give yourself infinite resources and all the technologies and set out to plan the perfect economy from the get-go, eventually something you forgot will throw a wrench into some tiny part of the supply chain, and the whole thing comes crumbling down. Then you try to build some redundancies into the system, but the overlapping networks create routing problems of their own.
I wonder, in general, if games like these are "solvable" via some sort of theory, or if you just have to iterate through a billion configurations before you arrive at a better one...
I don't know what your definition of solvable is for Factorio, but for mine, there are already a few calculators out there that can solve the infinite resource/constant thruput scenario just using linear algebra. The base game has a limited number of products. Maybe in some of the overhauls like K2SE or Py's, you might need something more complex since those are 10x-100x the base game, and the system of equations may surpass numerical methods on a single computer.
The real serious solutions are actually you versus your system resources. There solutions look awfully like low level performance tricks like inserter clocking (think SIMD) or belt compression (think fitting data in cache lines/reducing pages). Both of these things would take not just and understanding of the game, but understanding how the game is programmed.
Constraint solvers have already been used to generate optimal belt balancers (and it's beautiful / incredible). The designs they come up with for 16-wide balancers are, I think, beyond anything a human could have realistically created in a single lifetime.
I wholeheartedly agree with this. The way I go about developing my base in Factorio reflects how I go about developing software. What's interesting is that in playing Factorio, the weaknesses in my approach are more readily apparent (because they are visual?) and consequently, I am learning to be a better developer from playing Factorio. This is coming from a hobby developer so ymmv, but this is how I justify sinking so many hours into playing this game.
I was really surprised at how similar it felt to doing real work (as a SWE). I actually stopped playing for that exact reason - it just felt like work to me. I can totally see how it’s fun, but I don’t need to be thinking about long-term architecture / design for that many hours of my life.
It was fun for me to finish the game for the first time, but then I thought to play again to make everything better and plan each move from the very beginning. Aaaand I stopped after 1 or 2 hours because it wasn't fun anymore. And never got back to the game.
That's why I stopped playing, and probably why it wasn't quite as much of a revelation for me to play it. I saw the throughput and dependency pitfalls and (roughly) planned for them early, where I imagine someone new to those kinds of problems would run into those issues head first, and be able to use factorio to learn about them first hand.
However Factorio lacks refactoring tools, tests and source control. If your code feels very similar to your bases maybe you're not using these things enough...
You can just go for it and make a production chain for a product, but if next one needs same intermediates you'd be re-doing it. i.e. doing a spaghetti code.
You can section off the each intermediate into separate factory and just chain them to eachother and have relatively nice order, but when you try to expand production of everything, there is no easy way to grow that complex, so the best you can do is just copy the same block around.
Lastly you can build a rail network and put each intermediate anywhere you want without much problems, but wiring everything up will take a lot more effort, you will have to go to various places to debug any problem, any problems are less visible at first glance and lastly if you don't plan for capacity you might have bandwidth and latency problems