Finally got around to hacking up my own mod for factorio a month or so ago (bigger cargo wagons). As with the rest of their work, the "how to make a mod" process and documentation is exemplary. There's accurate documentation for everything, pretty much, provided by the developers, and kept up to date.
Contrasted with other games where "the community" and developers request docs and examples be taken down if someone tries to publish such; it's all the more wonderful.
I hope there is more exploration around a “Factorio Cloud” that connects multiple Factorio servers so you can visit and exchange resources with other factories. I think there have been a few projects similar to this but nothing substantial yet.
In general I like this idea of connecting local sandbox games in a sort of multiverse. It would be cool if there were an open-world, multiplayer game where you could create portals to your game server(s) hosted elsewhere. So you could go to one portal to play a game of Civ, and another to play Factorio. And somehow each game could include a mod that implements a common interface so that your performance in that game can have some effect on your character in the “root” multiverse game.
I get the sense this is maybe roughly what Tim Sweeney wants to do with Epic. And maybe Roblox has similar ideas.
> Clusterio [1] is a clustered Factorio server manager that provides the tooling for implementing cross server interactions in Factorio. It was previously best known for implementing cross server transfer and cloud storage of items via teleporter chests. But this functionality has been pulled out of Clusterio into its own plugin for Clusterio named Subspace Storage.
A long time ago when Lego used to produce actual video games (or at least, had game companies do it) one of the games was Lego Loco - a game that I probably spent possibly thousands of hours playing as a child along with all their other games.
It had the concept of being able to send postcards and trains that you made in game to either people on your LAN or to a random player on the internet. Their trains could then move around on your railways - and you could send it to back to them or anyone. The trains would go in and out of train tunnels.
For people who do want to "play the game" so to speak (aka: make a 1kspm factory or rocket-per-minute factory), the methodologies for achieving that are pretty well known at this point in the community.
The "blueprints" you need are mostly rail-blueprints (quickly building rail-lines and miners that connect into your greater design).
The "logic" of Factorio factories are... unfortunately too simple. All resources eventually turn into science (even the "Rocket launch" is just a space-science generator), and then those science packs enter the labs, and you're done.
As such: all resources form a mostly simple tree beginning (miners) to furnaces, to assembly machines, to science packs.
The exceptions:
* If you use barrels / unbarrelings, your barrels need to loop back to the source of fluids. You can remove this loop by simply using pumps and/or fluid trains instead.
* Heavy Oil / Light Oil / Petroleum gas looks like it forms a loop at first. But it turns out its just a tree, and entirely solvable by simply "drawing enough Petroleum gas". If you ever feel like you aren't making enough Heavy Oil / Light Oil, you can make more science (and infinite science means you have a literal infinite sink), which causes any Petrol-gas backup to self-resolve eventually.
-------------
The "difficulty" of Factorio quickly becomes one of traffic engineering. Train intersections are one of the hardest sources of bottlenecks and take an extreme amount of effort to resolve (usually using 3-8 trains or bigger, as well as advanced intersection designs possibly using combinators to form "Traffic lights" if you need to go there). Attempts at 4-line rails usually fail in my experience, because a 4-line intersection is harder to design than a 2-line intersection.
Furthermore, 2-line with 3-8 trains is sufficient for 1-rocket-per-minute bases. So a "proper" 4-line intersection doesn't seem necessary unless... you really want to go there and solve that problem unnecessarily. (Its a fun problem :-) So do it if you have fun).
------
From there, you have Train -> belt and Belt-> train designs, to ensure you optimally unload / load the trains. Those belts that feed these stations need to operate at near 100% efficiency if you hope to achieve rocket-per-minute status.
Well... maybe not "necessarily" operate at 100%. But a RPM base needs something like 50+ blue-belts of raw materials. So if you're only operating at 50% capacity, you suddenly need 100+ blue belts (at 50%). So staying at 90% to 100% of what a blue-belt can handle (45 items/second) really cuts down on the size of your factory designs.
------------
I argue that the core assembly machines are probably the easiest part of the design. You calculate the ideal ratio (though this ratio changes based off of the number of productivity / speed modules you use), and then build that many machines... careful to not run into bottlenecks (blue-belts are 45-items/second maximum. Stack inserters are 13-items/second belt->machine, or 27-items/second for machine->machine or machine->chest).
If you're hyperoptimizing designs, its difficult to beat what some people in the community have made. But if you're just aiming to make something "decent", its not very hard to slap together some 8x speed beacon + PM3 based designs, even without any blueprints.
> Heavy Oil / Light Oil / Petroleum gas looks like it forms a loop at first. But it turns out its just a tree
Don't "worry", Angel's Petrochem fixes this, and IIRC all the products can be reduced to syngas & produced from syngas. If normal oil ever gets too easy, Angels will literally melt your mind. No flare stacks that's cheating ;-)
More seriously, this is why I enjoy some of the mod packs. The loops in things makes things harder, so now you have to really manage the by-products better. E.g., Bob's has a nasty challenge with sodium hydroxide, a by-product of chlorine production. In the early came, it can stack up, & become a real pain. In the late game, LDS production eats it alive, so much that you actually need to appropriately vent chlorine.
I also appreciate playing Bobs/Angels in a sort of "try to waste/vent as little as possible", which means I need some more complex designs, normally to say "if we have waste by-products, use those, else, generate the product directly".
I wouldn't want it in the base game, though, that's a bit much for new players. But the challenge exists.
There's also a bit of fun w/ sulfur dioxide/sulfur in Bobs. You get both as products, and you need both as inputs, and you have to balance the production. (Or, you can just turn sulfur into sulfur dioxide & vent it, but that's boring.)
The other bottleneck that bites me (and that has bitten me in my current game) is pipe throughput. We're going to have to re-layout some stuff, as we've hit the upper bandwidth of our current pipes, I think. Rocket fuel just eats hydrogen like crazy in ammonia/hydrazine production…
> The other bottleneck that bites me (and that has bitten me in my current game) is pipe throughput.
Pipe throughput is a pain the first time you come across it. But the solution is as simple as "Belt throughput" issues.
Run a 2nd pipe. And when that's not enough, run a 3rd, or 4th, or 5th, or 6th pipe. Don't overthink it, that's the solution.
--------
There's a "Trap" called pumps. Pumps can bring the effective throughput from 1,200 fluid/second to 12,000 fluid/second, making you think that you've gained 10x more throughput per pipe. But this costs power and causes pollution in game, it makes it difficult to "branch" pipes while keep the 12,000 fluid/sec your pumps support.
Furthermore, the "state" of pipes is factored into the equation. Momentum plays a role, and therefore the "order" that you place pipes, and where things flow can increase, or decrease throughput. So playing at the 12,000 fluid/sec throughput levels is only possible if you get everything perfectly correct (momentum and all).
In contrast, you can just run 10-pipes in parallel, each supporting 1200/sec fluids as long as you're under 17-length. This is slow enough that the momentum calculations don't really affect you.
This is only an issue on nuclear setups in vanilla (the only item that uses so much fluid / water). All other designs are petroleum / light oil / heavy oil, which is used at small fractions of what water-usage does.
----
With the new UPS optimizations from 0.17 and 0.18, independent pipe networks are calculated in separate threads. So "parallel pipes" with no pumps are the most UPS friendly design you can get.
But for the argument's sake, imagine being able to collaborate with other players on Git, with a PR based workflow, wouldn't it be cool? Even if it's totally useless and inefficient?
Verilog shows that a hardware description language is useful, and I bet that real-world computer designs are more complicated than anything that happens in Factorio.
Still though: it brings to mind what exactly a text-based language that describes Factorio factories would even look like? I feel like the creation of 8-beacon PM3 assembly machine arrays is simple enough to be automatically generated (ratios can be already calculated in calculators like https://kirkmcdonald.github.io/... the "routing" piece of the puzzle needs to be solved though).
An "autorouter" that determines how many belts / pipes / trains are needed would need to be automatically programmed.
Once such a magic program were created, the "program" written would almost certainly be:
"Create 1000-space science per minute and feed it into a science array".
The ratios of what make 1000-science are determined in stone (assuming PM3 is set in stone to make sure that ratios don't change).
--------
Its the implementation details that are all the fun in Factorio. How do you build the thousands of PM3 modules you need to make a 1000-space science per minute base? Oh, but to build those, you need to have 2GW of power. How do you build a nuclear reactor of that size?
Etc. etc.
All of those problems have solutions that the community already created. But the fun of Factorio is coming up with your own solution. Not relying upon some kind of shared-github based workflow.
----
Alternatively: there are other designs (ex: "Speedrunner designs") that optimize on number of clicks instead of the optimal number of resources. Click-and-dragging red-inserters all over the place uses far fewer clicks than using yellow/blue/green inserters as appropriate, but the red-inserter is grossly suboptimal.
Still though, by using one inserter type, you quickly standardize your designs and "speedrun" the game faster. The resource inefficiency is wiped out by the far fewer clicks needed to create the overall design.
So I guess that's the thing about Factorio. The fun in the game is in making your own goals and then solving the stuff in your own way.
Contrasted with other games where "the community" and developers request docs and examples be taken down if someone tries to publish such; it's all the more wonderful.