Another Factorio Post-Game Ramble

Factorio is such an enthralling game to play.

If you’ve somehow found this post but don’t know Factorio: It’s a 2D game which starts out similar to many ‘survival’ games (e.g. you chop wood, mine stone and iron, etc.), but progressively build up ways to automate these tasks away. The eventual goal is to build and launch a rocket; although many players find fun in seeing how big a factory they can build.
Ultimately, the whole ‘challenge’ of Factorio is finding a way to arrange the factory so that all the inputs can get to the right places.. so it’s encouraged to do a first playthrough ‘blind’.

I had been meaning to play some other games on my Nintendo Switch, but after starting a new Factorio playthrough, ended up spending a lot of time on that.

This time, I played on a “ribbon world”. I also set the resource patches to be more frequent and richer (although didn’t change them to be bigger than normal). I decided to play on non-peaceful; but, disabled enemy expansion.

“Ribbon world” limits the height of the map. – This adds some challenge to laying out the base. e.g. the limited vertical space constrains how ‘vertical’ any part of the factory can be; whereas horizontal space has to be cleared (especially on non-peaceful, where enemies have to be cleared), and inputs will end up really far from where they need to be.
On the flipside, the limited height makes defending from the enemies trivial: the enemies can only come from the left or the right, so you only need to worry about defending a tiny perimeter to the left and to the right.

Compared to Previous Playthroughs

On my previous Factorio runs: I mostly stuck to peaceful, and have tried out different strategies for organising the factory.
I did complete a game of non-peaceful.. I’d say that the enemy attacks add some pushback and constraints. e.g. you need to supply defenses, and in order to expand the factory, you somewhat need to clear enemy bases.
In terms of strategies I’ve tried: I’ve tried the game without trains or even bots(!), I tried the game where I used trains to augment a ‘main bus’. I tried a game where I had the whole factory covered with the same bot network, and used this to supplement a main bus (albeit, resource patches were frequent, rich, and big).

Recall.. the “main bus” idea is to put a bunch of common resources on belts in parallel. This makes the “gather inputs” part of the equation much simpler: to assemble an item with inputs “steel, copper, green circuits”, you just branch these resources off from the main bus.
One inevitable problem is that the input requirements for your inputs might be larger than the bandwidth of the bus. (e.g. you’d ideally consume 1000 resources from the bus, but the bus only supplies 500).

Having a factory covered with bots “solves” the problem of getting uncommon items around; and also makes it easy to build up parts of the factory without needing the player around.
I’d hoped for a ‘stacking’ design which automatically could build itself (since the roboports from one part would be able to then build more roboports and other buildings, expanding the factory).
In hindsight, it was excessive to build roboports that covered the whole of the map. It didn’t really help with moving resources around great distances.

For this ribbon world, for moving resources great distances, I opted to go for a train-based approach.

Overview of the Strategy

Generally the strategy I wanted to take for this factory was: use trains to move resources around.

I aimed to have four lanes of rails at the edge of the map: two on the top, two on the bottom. The idea being, train stations can branch-off from the inner pair of rails, whereas the outer pair of rails only ever has junctions to/from the inner pair of rails; trains need to slow down in order to stop, so hopefully this would reduce the need for trains to slow down before reaching their destination.

Using trains then means: have train stations which load resources from mines, and then have groups of train stations which consume those resources (and provide more complex resources in turn).

I hadn’t been against the idea of then using train stations to start off a “main bus”. However, I never ended up doing this. (I did build the same “mall” that I’d used in previous builds, which uses a bus of inputs). – It would take a lot of horizontal space to gather so many inputs, and would take a lot of horizontal space to extend the bus, and there’s not much vertical space to build off of the bus.

Militarily, the game was quite straightforward.
In the early game, the enemy bases are quite far away. The enemy AI is passive, and only attacks in reaction to pollution from your factory reaching their base. It was easy for pace of conquest to outspeed pace of pollution, since the height of the map is limited.
However, it doesn’t take too long until conquering enemy bases become too formidable for the player to take on by themselves. Enemy defenses get so strong that it takes a lot of effort to make incremental progress against them. (Although part of the problem is the tank doesn’t control so well on the Nintendo Switch, I reckon).
In the late game, artillery outreaches the enemy.. so expanding the factory involves building up a wall & some turrets, building out the railway to the wall, then using an artillery train to blast the enemy bases. – Notably, construction bots can be used to build out these, so it can be done without needing the player nearby.

What Went Well: Scale

One of the challenges of Factorio’s late game is that high-tier items are really expensive, requiring many inputs.
e.g. The simple green circuits require a few iron and copper pieces. The more advanced red circuits then require a few green circuits, a few copper pieces, and a few bits of plastic. The most advanced blue circuits require twenty green circuits, and some red circuits, and some sulfuric acid. – Many of the late game items require hundreds of blue circuits to build.
As noted above, even if it’s not difficult to get inputs connected to a system, one of the problems using belts is hitting bandwidth limits.

Using trains to move resources around allows for huge scale.
I suppose there must be a bandwidth limit on how many resources a rail allows, too. But, with trains only using rails when carrying a bulk of resources at great speed, it’s not really an easy limit to hit.

Trains then allow for ‘decoupling’ where an input is gathered from where it’s consumed.
– With belts, you need a belt that runs all the way from a particular input to where it’s consumed. More resources can be fed into the belt, but resources need to be fed into the belt before where they’re consumed from a belt.
With rail, there’s not this constraint. Resources loaded anywhere on a rail network will find their way to where they need to be unloaded in the rail network.

This ends up making “scaling” relatively straightforward: getting more resources essentially either involves building up how many resources are produced at a particular location (e.g. adding more miners to an ore patch) i.e. “scaling vertically”, or by adding more stations to the rail network which produce that resource i.e. “scaling horizontally”.

Practical Differences Between Belt-Based and Rail-Based

I did run into some practical problems trying a rail-based factory.

There is some edge case stuff.
In rare cases, maybe a train runs out of fuel.
When I tried to be fancy and programatically enable/disable a train station (e.g. “disable this stationn, because it has enough resources”), sometimes a train might stop in the middle of the rail because it suddenly gets disallowed from visiting its destination.
etc.

One downside to the rail-based approach is there is additional overhead to deal with.

One overhead cost is that there may be a longer lead time between when an input is added to a network, and when it can be consumed by the network.
e.g. A simple approach to take is to have a cargo train wait at a loading station until it is full, and then move to a deposit station until it is empty. (Anything more frequent than this would be an ‘inefficiency’). – This means opting to wait the full length of time for a cargo train’s worth of resources to be produced before it meaningfully enters the network. (This increases the delay in the feedback loop for how much some resource is demanded, for better and for worse).

Compared to belts, distribution of resources is more of a problem whenever inputs don’t fully saturate demand.
With belts, splitting resources off of a belt does so in a 50-50 manner. So for a factory with 1000 units of some resource needed by A, B, and C.. 500 will reach A, 250 will reach B, 125 will reach C, leaving 125 to continue to be available on the bus (splitting off into 64, 32, etc.). – Eventually, at least some of the resource will reach even the end of the bus, even before inputs at the start are saturated.
With rails, by default, you don’t get this behaviour. A train will go to the closest station that it can visit. – So while it’s still true that “producing more inputs than is consumed” eventually satiates demand, it takes more care to get expensive resources where they need to be before all inputs are satiated.

I’d say one mistake I made was using big buffers at resource unloading stations for expensive resources. – i.e. Each unloading station would have a buffer which could receive six or seven trains’ worth of cargo. For simple resources, this isn’t much of an issue, since it’s easy to build more stations which provide that resource. For more complex resources, since the time to produce the resource is greater than the time to load the resource onto the train, this meant that a significant amount of time was spent depositing the resource into filling up a buffer, when that resource was starved in other parts of the rail network.

Another overhead cost is space. This perhaps is “different” rather than “worse” than belts.
With belts, moving resources over a long distance is tedious but possible. Moving rare/expensive resources long distances (at worst) involves snaking the belt through the rest of your factory.
With trains, building a ‘block’ of stations for a resource which takes 5 inputs requires taking up a reasonable chunk of horizontal space on the map. (This is mostly more annoying with frequent resource patches, since you might want to avoid building on top of a resource patch).

One decision to make is “what resources to put on the rail network”.
If building up the rail network before electric smelting, then coal is required to turn the ore into plates that get used by most recipes. (Which is why it’s a bad idea to build up a rail network before getting electric smelting).
Yellow Science in particular has complex input requirements, and there are different trade-offs for putting its intermediate input requirements on the bus or assembling them in the same block.

New to Me: Circuit Network Combinators

The circuit network allows for programmability with Factorio’s machines.

I had used it before for simple things like “if ammo below certain amount, send an alarm signal” or “only take stuff out from this storage if there are at least 1000 items”.

The circuit network logic complements the rail network nicely.

I was able to use the circuit network to describe a couple of things:

• Dynamically set how many trains are allowed to visit a station, based on how much remaining capacity the storage buffer for the station had. (e.g. if it would only take two trains to fill the storage buffer, limit the number of trains that would visit the station to two).

• Dynamically enable or disable the station based on how full the buffer was. Once the buffer was less than 20% (or whatever) full, then enable the station so that resources would be unloaded there; but once it reached 90% or so, then disable the station until the buffer was back down to only 20% full.

The problem above of “starving stations not being filled, while buffers elsewhere were being filled” surely could have been mitigated using the circuit network. (The logic is a bit ‘come-from’: rather than saying where trains go to, you’d say which destinations should receive resources. I’m guessing something like: if any stations are ‘starved’, then limit or disable any stations which have at least some resources in their buffer).

What Went Less Than Well: Slow Progress to Reach Late Game

Kinda like how playing Sudoku can be fun even though Sudoku solvers exist, playing Factorio can be fun even if you’re not building the best factory ever.
Factorio is essentially just a toy.. and the game’s goal of ‘launch a rocket’ is a decent objective to aim for with Factorio’s systems.

It’d obviously be less fun if I just used console commands to provide infinite resources, or to instantly provide the rocket silo & launch the rocket effortlessly.

I imagine it’d be less fun if I only used blueprints other people created.

I find Factorio fun even without the enemies, or with non-aggressive enemies.

Unfortunately, in this ribbon world playthrough on the Nintendo Switch, I took a long time before getting to the late game.
What I ‘should’ have done was to aim to quickly build a factory which would (even at a trickle’s pace) research towards the late game technologies.
Instead, I meandered and did things I thought were more interesting. Which is fine, but it meant it took a long time before I reached the late game.

The friction is that the problems you face in the early game get solved by the late game:
Routing train rails is difficult when the map has cliffs and water. The cliffs can be blown up, and the water can be filled with later technology.
A busy factory will use a lot of electricity. Nuclear power provides an abundance of electricity.
Enemies block expansion.. and late game artillery ‘solves’ this, and laser turrets ‘solve’ the problem of supplying the defence.
Building the same pattern of buildings repeatedly is slow; bots trivialise this.
– But in order to use these technologies, you have to have researched them.
Aiming to use a train-based factory before the late game ultimately ends up being a bad idea. You don’t have the capacity to expand the factory fast enough to meet the input requirements for the kind of scale that a train-based factory needs.

A Follow-Up Playthrough

As I was writing the above up, I just had to try again to see if I could do better.

I took time to pre-plan the ‘blocks’ of train stations that I would use. I used the sandbox mode so that this could be done in a safe way.

On the PC, I played using the default ribbon-world settings. (So, compared to my Nintendo Switch playthrough, resources were less frequent, and not quite as rich; plus, enemy expansion was enabled).

Overall, from a second playthrough:

• The gameplay was significantly more difficult with enemy expansion enabled than disabled. With enemy expansion, I very quickly hit a point where clearing enemy bases was impractical without artillery.

• I used a much more compact approach when designing the blocks of train stations. This meant I was better able to utilise space.

• In my first playthrough, I had opted to have each station allow for ‘stacking’ trains. This wasn’t really necessary for the scale I was operating at. (It would be useful if the factory were so large that “time to consume all of trains input” was shorter than “time for another train to arrive”).

• I took the time to ensure my blueprints for “use roboports to expand the factory’s frontier” (place laser turrets, place rail so the artillery train can move further out) could more easily snap-to a course grid. This made it much easier to instruct the bots when expanding the frontier.

• I really felt the contrast between ‘mid game’ and ‘late game’. With ‘mid game’, I was essentially boxed in until I could research artillery. I wasn’t able to easily expand in order to acquire more resource inputs. (Hence.. using a rail-based factory has more disadvantages than advantages). – Probably, though, the lategame alone wouldn’t feel so satisfying without having faced the obstacles in the mid-game.

For now, that’s enough Factorio, though.

---

---