Factorio Part 2: Optimize!

By Shamus Posted Thursday Apr 29, 2021

Filed under: Retrospectives 73 comments

So let’s talk about some Factorio theory. I should note that I’m not an expert. This post isn’t a super-definitive analysis on how to optimize your base. I’ve logged over 2,000 hours with this game, but frankly that’s chump change compared to what the seriously high-level players can claim. And despite all my time with the game, I still need to look things up on the wiki from time to time.

But I’ve never let a lack of expertise stop me from playing the game, so I’m not going to let it stop me from talking about it.

Broadly, there are three approaches to building your base.

The Hodgepodge

Above is a screenshot I took back in 2016. I cringe when I look at it today. There’s tons of wasted space. There are no walkways. Almost everything is sitting on the dirt rather than having a stone or concrete base. I’m severely under-utilizing the resource patches. Low-level production is positioned right next to the rocket.

Worst of all, I only see TWO refineries??? In my current games, I always have multiple outposts harvesting oil, every outpost has an array of a dozen or so speed-boosted refineries, and it still feels like it runs too slowly. You can see in the screenshot that I’ve just launched the rocket. I can’t imagine how I pulled that off with just two refineries. It must have taken ages.

Here is how you wind up with a hodgepodge base:

Due to lack of experience, I’m not sure how many machines I need to build or how much room they will need. So I figure I’ll just leave some random gaps around things. 

Later I unlock Arbitrary Gizmo #37, Not the real name. The game has coherent names for all the products, but you don’t need to worry about remembering them all for this example. but I don’t know ahead of time where all of these gizmos would be needed later on. I don’t know how many I’ll need, or what the resource bottlenecks will be down the line. 

So then later in the progression I realize I need some Gizmo37 on the exact opposite side of my base. As a result, I have to snake a long conveyor between the other blocks of machines, criss-crossing with all the other conveyors from all of the other misplaced product factories. 

Later I realize I need about twice as many Gizmo37’s as I’ve been making. The original machines are fully surrounded by now, so I can’t just add more beside the earlier ones. So I have to build another block of assembly machines somewhere on the edge of my base to make more Gizmo37. 

Later on, I realize that I’m still short on Gizmo37s. I check my machines to see what the problem is, and discover they’re not getting enough (say) copper. So what do I do? Run additional conveyors to these two groups of machines? Mooch some additional copper from nearby production blocks and hope that I don’t starve some other product? 

In the end, I wind up with everything being produced in random places. I’ve got spaghetti conveyor belts running all over the place in ways that make it impossible to get a sense of the flow of materials. There’s a lot of dead space between groups of machines that are big enough to waste space but too small to be used to build anything useful. Some conveyors are backed up, and in other places machines are starved for resources. 

This is how I won the first couple of games of Factorio. It was basically an unintentional comedy where I didn’t realize just how terrible I was. 

Eventually I realized I needed a better system. So I decided to get on…

The Bus

Here my conveyor bus runs right-to-left. Sometimes the positioning of resources on the map will force me to go against my preference of building horizontally, left-to-right.
Here my conveyor bus runs right-to-left. Sometimes the positioning of resources on the map will force me to go against my preference of building horizontally, left-to-right.

I came up with this system on my own, and then later discovered that everyone else came to the exact same conclusion. I didn’t know this system was called “The Bus” until a few years into my Factorio career / addiction.

The Bus is where you basically apply cable management theory to your conveyor belts. You have a central spine of parallel conveyor belts that (hopefully) run in a straight line through your base. This is the bus. 

You might need to make the bus turn if you’ve got natural obstructions in your way, like lakes, cliffs, or nests of alien bugs. You eventually unlock ways to clear all of these things, but you don’t want to run into an obstruction before you have the tools to deal with it. I usually scout around the area during the burner phase of the game and find a nice long stretch of land where I can put my bus without running into these sorts of problems.

You build clusters of machines on either side of the bus. You use a splitter to draw some resources from the bus. When those machines spit out their products, they get added to the bus. 

So at the start of the bus you’ll have very basic products like copper and iron plates. As you traverse the bus, those conveyors will start to run out of resources as a result of all the machines skimming off what they need. At the start of the bus your iron plates will be packed tightly, and on the far side they’ll be a trickle. Meanwhile, the bus will accumulate new conveyor lanes with new products.

When you’re done, the base should be very easy to follow. Just walk along the bus and you can tell where things are going by looking at the conveyors. 

The bus is great for keeping things organized, but the problem is that  you’ll eventually run into throughput problems. This brings you to the most ambitious form of base-building…

The Outpost System

“Outpost” is my name for this approach. I think the community calls it a “megabase”. I played almost 1,000 hours of this game before I engaged with the community, so I ended up coming up with a lot of my own names for things.

Above you can see a map of my so-called “megabase”, although I think mine barely qualifies. Sure, a lot of production has been moved away from my central base and into these various outposts, but this whole setup is absolutely puny compared to the gargantuan planet-smothering bases that the experts have built.

If you’re really looking to scale up and build ultra-fast research and rocket-launching systems, then you have to give up your bus. At least, you have to give up on the idea of having a single bus for your entire base. 

One of the components of the rocket is the Rocket Control Unit. You need 1,000 of these RCUs (plus other parts) to complete one rocket.

An RCU is like a computer of some sort. So it’s made from complex circuit boards, that are made of more basic circuit boards, which come from the simple circuit boards. If you run the numbers for the entire production chain, you’ll discover that it takes 39 iron plates, 72 copper plates, and 14 plastic bars to make a single RCU. That’s a total of 125 items of raw materials to make one RCU.

So we can think of products as a kind of compression. If you want to make 1,000 RCUs, then you need 125,000 raw items. If you try to send that much crap down your main bus, then you’re going to run into massive throughput problems. A few weeks ago I posted the following image, showing the throughput of the various belts in the game:

Only the top three belts are part of the main game. The rest come from a mod. You can see that the best non-mod belt can only deliver 45 items a second. That works out to 2,700 items a minute. That means it would take 46 minutes to feed all the raw materials through a single belt. (Nobody would actually use ONE belt for this, but I’m just trying to illustrate where the throughput problems come from.)

And remember that RCUs aren’t the only parts you need. You also need 1,000 units of Low Density Structure and 1,000 units of Rocket Fuel. Those items are also made of items that are made of items that are made of items.

You can try the Downtown LA solution and add more lanes, but eventually you run into horrendous load-balancing problems where some lanes are saturated and others are almost empty. That’s not hard if you’ve only got one or two, but balancing a load across (say) 7 lanes is going to be a nightmare. Worse, having that many lanes of all your major resources will make your bus incredibly wide. This will make it a lot harder to tell what’s going on by glancing at your bus, because it’ll be so wide it won’t all fit on-screen at normal zoom. This also creates routing headaches in trying to move different resources around on the belt so they can reach the machines that need them.

Again, this is fine if you’re happy to sit around for twenty or thirty minutes waiting for the next rocket, but if you want launch times under that then you need a different approach.

Instead of using a single bus of raw materials, the idea is to have remote outposts all over the map, positioned near resource patches. These outposts construct intermediate products, which are then shipped to your main base by train. So instead of trying to shove 125,000 raw products through your main bus, maybe you only need to push through a few thousand circuit boards. This means fewer lanes and less chaos. Although now you need to worry about managing a complex train network.

I’ve done a couple of outpost / megabase builds by now. It’s a better, more efficient system, but it takes forever to build. 

Next time I’ll give you a tour of my base and you can laugh at my design.

 

Footnotes:

[1] Not the real name. The game has coherent names for all the products, but you don’t need to worry about remembering them all for this example.



From The Archives:
 

73 thoughts on “Factorio Part 2: Optimize!

  1. tmtvl says:

    I’ve never played Factorio, but in modded Minecraft I always tend up doing more of an outpost-style set-up, maybe taken even further: I set up a regular, almost vanilla base for the early start, and when I proceed through the tech/magic/whatever tree I make an entirely new base to set the next level up, so I can rearrange things easily if and when they need rearranging.

    That does slow down my progression, but it means I never have a spaghetti base that makes things impossible to find.

    1. Mike says:

      Kinda same in factorio here.

      I tend to set a goal like “ok, now I want yellow science cards, same 0.5/s (as other colors) will do”.
      And the next step is “which production units do I need from the base smelted materials to make these?”.
      Then find a clean patch of land, rummage around in the blueprints drawer, build e.g. “1/s red electronics production line” X 2, “efficiency chip line” X 4, “some new weird requirement line” X 1, build train station to supply plates and plastics for all these, build an assembly line at the end to convert all these pasted components into final product, copy new lines into a blueprint for later.

      I think of this as a kind of abstraction pattern (custom “assembler” units/blocks) on top of “resource bus”, where you don’t need many lanes of different things – only base resources from the ground (though still smelted on-site for efficiency).
      (and of course tend to find trains to make moving stuff around much more aesthetically pleasing and seamless than long belts, with latter only being used to connect lines working on the same site/goal)

      1. Echo Tango says:

        I’ve never built big enough, to need the extra x2 space from shipping only plates around on trains, compared to shipping ore on trains. One or two trains running ore constantly from mining outposts is more than enough to get most of the recipes built in the game for me, and the shared smelter means I have less to build or tear down, when I’m building a new mine or decommissioning an old one. I get enough train-saving by having the smelter-zone build all the common, time- and space-saving recipes on-site, like engines, steel, red science, and green science. :)

    2. Chris says:

      That’s the way I aspire to build my Oxygen Not Included bases, but somehow I always end up with spaghetti.

  2. Content Consumer says:

    Reading this, I was a little reminded of Bob talking about his own production and throughput problems.
    https://bobiverse.fandom.com/wiki/We_Are_Legion_(We_Are_Bob)_Wiki

    1. Shamus says:

      Wow. Are those books any good? The summaries sound really interesting.

      1. Content Consumer says:

        They are EXCELLENT! I absolutely love them. Well, the first three – I wasn’t as happy with the fourth. But the first three are great!

      2. Mike says:

        If you have read hardcore stuff like Martian, Suarez’ Delta-V, Stephenson’s Seveneves etc, they might be quite underwhelming, unfortunately, as they are very basic star trek sci-fi in comparison, probably aimed to be somewhat more introductory and kid-friendly material.

        They also suffer a lot from Ready-Player-One-like self-congratulatory reference/mary-sue plague, so if you find these themes hard to appreciate, maybe also approach with caution.

        1. Boston says:

          I’ve not read the Bobiverse stories, but I did slog through RP1 and found it almost unbearable. If they’re anything similar I’ll probably want to avoid it.

          1. Ester says:

            I’ve read both and found RP1 much worse on the mary sue account. Comparison of Bobiverse with Star Trek seconded – it’s rather fluffy Scifi that makes for an amusing evening, but doesn’t make you think.

      3. Functional Theory says:

        +1 for recommendation of this series. I really enjoyed them as audio books. As Mike says they are a little too heavy on the reference humour. But for an easy reading space adventure with some philosophy and grand idea exploration thrown in they’re great. I’ve listened to them two or three times now.

      4. Taellosse says:

        They’re light-hard-sci-fi, if that makes sense. The amount of handwavium is pretty small, and most of the real science surrounding it is solid, but they don’t delve into too much deeply weird or unpredictable conceptual spaces. There is a fair bit of pop-culture references, particularly towards traditional “geek” interests (Trek, Star Wars, D&D, etc.), but they’re not too forced or excessive, particularly if you share similar interests.

        Based on my estimation of your tastes, I’d guess you’d find them a reasonably fun read, but they won’t blow your mind or snything.

      5. Smosh says:

        I read them, and I’m pretty sure you’d enjoy them too. The writer got the realism of space travel at near light speed and the idea of self replication pretty right.

  3. Droid says:

    I’ve played Factorio, but started to lose interest in the mega-base part mostly because I was somewhat aware of how you have to transition from bus to train/outpost base designs if you want to stick with belts. The thing is, in contrast, bot-based megabases are just SO MUCH better in terms of build area, saturation and throughput. Yes, you’ll need tons and tons of roboports to supply the little worker drones with juice, but you can use the rockets you shoot into space to continue upgrading their speed forever. Meaning you’ll pretty quickly reach a point where your system just never runs out of robots and you can spend the rest of your playtime eternally running through your base (that always looks like an anthill you just broke open) and eternally upping the production of resources because you never have to particularly worry about throughput. It eats ridiculous amounts of energy, but you don’t need to care about that since end-game energy is a joke to maintain. Particularly because you’ll run out of any other resource quicker than you run out of uranium for your nuclear reactors even if you go full bot base.

    So, to come back to my original point: I’m not interested in belt-based megabases because while it requires a lot of problem-solving and logistical puzzles, they’re fundamentally always the same kind of puzzle, and there will always be this part in the back of my mind that says “you could just solve this whole problem by tearing up everything and completely replacing it with bots which are better in every way”. Going full bot base, on the other hand, just makes everything too easy, and looks a lot uglier with the endless swarming of tens of thousands of logistics bots endlessly moving resources that I couldn’t be bothered to design a direct-insertion blueprint for. And there’s no middle ground in there that I could find which would be enjoyable.

    I’m sure there is more complexity to be had in all this, particularly in the optimal use of modules and beacons, but I just slap a few prod modules on anything that accepts them, speed modules into any remaining slots and lines of speed beacons on everything in existence (and screw efficiency modules because ‘nuclear energy goes brrrrrr’). It’s just fundamentally not what I play these games for.

    In conclusion, ‘You have infinite everything if you just bother enough to collect it’ really puts a damper on my willingness to optimize, and expanding more just for the sake of expansion loses its appeal pretty quickly, especially with biters enabled.

    1. Retsam says:

      Yeah, RE: bots being superior in basically every way to belts, I pretty much just don’t play with logistics bots for this reason. It just kind of makes the game less interesting.

      I assume that’s part of what Shamuses “more, faster belts” mod is for – because in the base game bots are not only easier and simpler to use than belts, but also can get much higher throughput. At least a faster belt mod might balance throughput back into the favor of belts.

    2. Echo Tango says:

      Don’t you start running out of charging throughput if you try to make an entire megabase with bots? With the large distances they’d be traveling, they’d be running out of juice constantly. I’ve used bots in intermediate-ingredient-production outposts, but they’ve always been hooked up to trains for their inputs, and bringing their outputs to my other production zones. Is there some pattern that you can follow, to keep using bots at the distances where trains make sense, to avoid charging issues?

      1. Decius says:

        I assume it just involves spamming more roboports.

        I think a better overall system is to use bots to do local transport and trains to do distant transport.

        1. Echo Tango says:

          The devs never gave bots any fancy pathfinding to save on CPU, so they should all be taking the shortest path to a charger, which should bunch them. I’m pretty sure that’s what happens if you try to use them without some special spacing of the ports and/or assemblers for the different recipes.

          1. Droid says:

            assembler A, beacon, assembler A, beacon, roboport, beacon, assembler B, beacon, …
            stack vertically

            works well enough (where assembler A ideally produces something assembler B needs). The robots either charge when they come back from a finished job or recharge while travelling in more or less a straight line orthogonal to the line of roboports, meaning they’ll be spread out according to which assembler they come from and move to. In theory, it is possible for these to clump up but I’ve never observed any recharge problems or areas of long-lasting bot clumps even in longer assembly lines.

            1. Echo Tango says:

              Dang, that’s a painfully simple pattern to spam all over the place. That definitely breaks the logistics. ^^;

            2. Decius says:

              They should form a binomial distribution or so, if they pick a random assembler-assembler pair to supply from and to.

      2. Droid says:

        You don’t replace trains with bots in this scenario – just belts.

    3. Tom says:

      The trick to the belt-based megabase is to come up with tesselating blueprints, with standardised input and output “ports” that line up with each other, then you can quickly mark out a giant area full of a standard production facility, and leave the construction robots to it whilst you get on with something less boring. The best layout I came up with was a standard square with one vertical belt and one horizontal belt crossing each other at its centre, and one factory with attendant grabbers in each quadrant of the square, then laying out a big grid of these squares with all inputs travelling through it in one direction, fed from a staging area at one side, and all outputs travelling at right angles to this to a staging area at another side.

      1. Decius says:

        Did you loop the outputs back around to where they need to be inputs?

        1. Tom says:

          Not within the tesselated blocks, although that’s a fascinating idea – the central “carousel” loops ran along the sides to act as the staging areas.

          With the input and output sides of the whole aggregate block forming a corner, careful placement allowed indefinite room to expand outwards from the other two sides meeting at the opposite corner. One or both staging areas could also be railway stations instead of the edge (or tributary) of a carousel.

          1. Decius says:

            That would require that the corner have several times the throughput of the entire factory. But I could see the edge being done as a series of trains, moving from stop to stop on a pure time schedule using one track and a lot of short non-specialized trains.

  4. Bubble181 says:

    Minor typo: there’s a missing parenthesis right below the belt gif

    I’ve never played Factorio, but the difference between the systems (and potential other types which may not be possible or useful in Factorio), comes through in many other games and types of games. Heck, and in real life, of course.
    Thing is, if you know ahead of time howeverything fitstogether (I need 3 oil wells to keep one refinery running, I need two and a half refineries to keep one plastic factory running, I need one and three quarters of a plastics factory to keep one Rubber Ducky Factory going and I need 1.000 rubber duckies to….errr…..Enjoy my bath), you can plan ahead of time. And it’s nice and easy to keep everything organized. If you haven’t got a clue (yet), obviously you end up with spaghetti.
    In, say, Cities: Skylines, knowing ahead of time how many police stations and morgues you want or need is pretty much the same thing.
    My problem with Factorio seems to be that there really isn’t any point to optimization. There’s infinite room, infinite resources, and you technically win after your first rocket. Ok, so get your time down…Even so, you can replicate the same spaghetti base 50 times and launch 50 rockets every half hour, or whatever. Why bother keeping it tight? It’s like making a base “look good” or putting down esthetic items – if they serve no function or goal, why would I?
    This is a personal thing, of course – it’s also why I don’t play Minecraft. I need some sort of goal or progression or end point to work towards, or feel a sense of….sense in doing something. Getting my base as efficient as possible is absolutely a goal in some games…Just doesn’t seem to be so in a game where everything is infinite.

    1. Retsam says:

      My problem with Factorio seems to be that there really isn’t any point to optimization

      Optimizing in Factorio isn’t really just “launch more rockets faster” – in fact, I’ve barely ever spent any time playing a file after I launch my rocket. It’s largely a necessary step to just get to the point of launching rockets at all.

      Like in the early game, you’re fine producing just a handful of green circuits, but by the end game, you need to be producing them in staggering quantities if you want to launch a rocket at all. (Or at least, assuming you don’t want to leave the game running for literal hours days to do it)

      Like, you need something like 40,000 green chips to launch a rocket (many of them refined into red and blue chips) and that’s really only 1/3 of the total cost of the rocket. In total, a rocket takes about 100K copper and 50K iron – it’s going to take a lot of “optimizing” to really even make that feasible in the first place.

      And as for physical dimensions of the base, it’s not just an aesthetic thing, because you’re implicitly motivated to keep your base compact both because it becomes tedious to traverse your base the larger it gets, and the more it costs you in belts to transport items over longer distances.

      1. Abnaxis says:

        Also, the relative costs for many recipes have an “expensive” mode recipe, and you can multiply the science costs in settings to even get the rocket parts researched. That’s even before you get into mods that add even more research and complexity…

        I’m hundreds of hours of playtime in because I like setting everything so I HAVE to build a megabase to even get through the basic science in a reasonable time, and since all community designs assume “normal” recipe costs (the expensive recipes have different material ratios than normal) I have to work out my own logistics and production– but i can still engage and pick up tips from the community by learning the fundamentals that lead to the optimal normal designs.

        I keep restating when I catch something I find too suboptimal to want to rebuild. However, I’m betting if I ever actually launch the rocket in going to lose a lot of motivation to keep playing so I’m OK still being on the treadmill.

    2. Echo Tango says:

      The infinite space and resources are blocked by aliens, which get tougher as you destroy more of their bases. So, in order to keep pushing outwards, you need to spend an increasing portion of your resources on attacks and continued defense. It varies by player skill, but everyone eventually needs to spend less resources on redundant, inefficient factories, so they have enough to build their munitions with. (Alternately, become more efficient with your weapons spending, to compensate for your inefficient factory.)

    3. Tom says:

      There are a couple of motivators to optimise in-game – particularly the local wildlife. On harder difficulty levels or more challenging maps, I find one can remarkably rapidly run out of room to expand (or pollute, for that matter) without aggravating the local wildlife, which is not to be tangled with for a couple of reasons, IMO. Not only is combat in this game a perilous affair that I wouldn’t recommend to anyone who doesn’t enjoy blatant save-scumming, but, since I’M the intruder on THEIR planet, and there’s no way to survive encroaching on an alien nest without completely exterminating it, I REALLY don’t feel I’m in the moral right if I end up doing that more than is absolutely necessary to stay alive and get off this planet myself.

      Really, though, the best reason to optimise is just the pride and satisfaction at having come up with something really elegant and efficient, which is hard.

      It’s a bit like “beating” Hitman 2: Silent Assassin – any fool can get to the end of the game whilst barely breaking a sweat if they don’t mind just psychopathically murdering every living thing that gets in their way, but to beat the game and actually get the “Silent Assassin” rating at the end of each level? That’s just a tad more of a challenge.

    4. Javier says:

      Optimization is the difference between building a rocket in 10 hours or 10 minutes. You can set the base to build the minimum items possible, go afk and let the game run overnight, and then check the next day to see your rocket (or your base devoured by aliens). But if you want to win in a reasonable time frame you need to scale up.

      I do agree though in the sense there’s no point to the post-game. I really wish they had added a post-rocket goal other than just ‘build moar’ because I’ve never felt compelled to keep playing much past that point.

  5. Geebs says:

    I’ve never played Factorio, but the impression I get is that it’s a game about throughput and not travel time; i.e. once you have a conveyor connecting two things it’s not how long the conveyor is that matters but the rate at which things enter and exit the conveyor. I’m guessing that conveyors aren’t punitively expensive to build, either?

    So, surely the outpost model makes much more sense than the main bus approach?

    1. Retsam says:

      It’s usually not “outpost vs. bus”, but “outpost and bus”, as you’re still generally going to want to have a large central factory that does a lot of the processing, because while there are some things that can cleanly be processed in an outpost (e.g. iron copper = green circuit), more advanced things usually require random other inputs: like say, coal, or plastic, or gas.

      So if you were really trying an “outpost only” model, you’d basically end up with a huge spaghetti graph of connections between outposts for all the various things that different outposts need.

      And, if you’re suggesting using belts to connect outposts, that really isn’t practical – a train has much higher throughput than belts, and you need to run separate belts for every kind of item you want to transport, while trains can share the same tracks. When I add a new outpost to a train network, I can usually reuse 90% of the existing rail, but if I were doing belts, I’d have to run completely new belts. (And an individual belt isn’t expensive, but enough to run a long way likely can be)

      So train connections are the way to go with outposts… and I love trains, but they introduce a complexity of their own. Just designing your rail network to prevent trains from getting stuck is an interesting problem on its own. The more separate lines you try to run, the more you try to split resources from one output and send it to multiple other outposts, the more complex it gets, (e.g. one outpost may “starve” while another has a surplus).

      So, the model where all the outposts feed into a single large central base (with a bus) is usually a lot simpler than having a lot of “connections” between outposts.

      1. Echo Tango says:

        You can set up your outposts and intermediate bases with circuit conditions and limits on the number of trains, though. For example, disable a “need steel” train stop, if its stores have more than a certain amount. Then the steel-supply train will pick other train stops to deliver the steel.

        1. Echo Tango says:

          I forgot to add the part where this makes sense: this was in response to the complaint of trains’ complexity. There’s some basic rules you can figure out, to get about 50% of the efficiency and benefit of trains. A little more complex gets you something like 85%. They only really become very complex when you try to get the full amount from every train, which I usually never bother with. :)

          1. Decius says:

            The real complexity comes from trying to maximize the throughput of the train tracks.

            You start needing to add more trains, but at a point determined by the rail design adding more trains decreases the throughput of the tracks.

            And adding more lanes is an option but that can also decrease throughput.

            1. Echo Tango says:

              Yeah, last I found for tips, was to keep as many single-lane trains and separate your different networks of trains as much as possible. The posts were from a few years ago, so I don’t know if the devs changed pathing enough to make meticulous track-laying less necessary, but at least some of the later patches from that time were already going in that direction. :)

              1. Javier says:

                All I’ve ever done was setup a one-way rail network (parallel tracks) with each train assigned to a specific stop. All trains use the same main tracks. Go there, get the stuff, come back when full. Works fine up to the rocket. I just blueprint track segments with signals and then copy and paste them. Usually have 2-3 trains for iron and copper, 1 for coal, stone, oil, and uranium. If I feel like I’m not getting enough of a resource I set up a new base and add another train, though by late game the iron mines are usually consuming themselves so fast it’s hard to keep up. Never really get traffic jams as long as you add enough space at the base for trains to queue up or bypass each other.

              2. Decius says:

                In the last version I saw, you could do a lot of smart things like get trains off of the main lines into holding slots if their station was full using signals.

                But in general a two-track system (eg trains always drive on the right or always on the left) works out to at least the 90% level.

    2. Erik says:

      It’s all about timing, where you are in your build process.

      During Burner City phase, you’re almost always doing spaghetti at best. Once you get power and are ready for blocks of smelters, busses start to make sense. But until you’ve done a fair amount of research you can’t even build train infrastructure, and you probably don’t have the military tech you need to keep the biters from overrunning outposts yet (biters get denser the further from your starting point you get). Once you’ve got far enough to get enough tech and you have spare fuel for the trains and enough ammo for guns/power for lasers, then you’re finally ready to think about serious outposts.

      1. Echo Tango says:

        Trains require almost no fuel compared to other things like smelters, and the research is very low in the red/green, so those aren’t really much of a concern in getting trains up and running. Fighting aliens with enough turrets and guns is though[1], but more importantly, the default (non-train-world) settings don’t really encourage trains at all. Resources are plentiful and close together, so you can get by with belts for a very long time.

        [1] Especially since aliens spread new bases in the default settings. The first couple games I played, I had walls of turrets to keep them out, but by the time I started running low on supplies, the aliens had spread to carpet nearly every square foot of the map, so expansion was a massive chore. The default settings really seem to let players soft-lock themselves by turtling, which is also a dominant strategy. I’ve only played train-world settings (no alien expansion) in the years since then, so I don’t know if they’ve changed expansion mechanics to make the aliens less of a trap for players who aren’t expanding early and constantly.

        1. Javier says:

          In my earlier games I could ignore bug hives and just build a double-wall of laser turrets without ever being in danger.

          In my last game (last beta before 1.0 release) I had to go out and clear bases from my pollution cloud or i’d get overwhelmed. However I was playing the no laser and no solar challenges.

    3. Decius says:

      Belts aren’t punitively expensive, but they aren’t trivially expensive either.

  6. Lino says:

    Shamus, have you ever thought of streaming games like Factorio? Given your audience, it seems like a good fit, it could help you reach new people, and it might even bring in some extra revenue. Even if you don’t get as big as Ninja, it could be a nice sort of side-gig.

  7. bobbert says:

    I really enjoy Factorio. I get the feeling that trains are supper strong but have never really figured them out.

    I would love to see a worked example. Start with all green techs, a box of 10,000 rails, 500 assemblers, 500 furnaces, and 1000 arms, and a box each of iron and copper (Simulating having torn down a mid-sized base in the old style)

    1. Echo Tango says:

      For your early trains, it’s good enough to just have train stops and totally separate lines for each train. Then you don’t need to worry about signaling for multi-train, multi-stop stations, or for shared two-lane highway systems. If you don’t have your lines for different trains cross at all, then you don’t even need to figure out signals. If you do need a crossing, you just need chain signals for the trains entering the intersection, and regular signals as they leave the intersection. (So for a simple two-line crossing, you only need two chain and two normal signals, right beside where the tracks cross.)

  8. Abnaxis says:

    You can try the Downtown LA solution and add more lanes, but eventually you run into horrendous load-balancing problems where some lanes are saturated and others are almost empty.

    Shamus, did you know splitters can prioritize inputs and outputs? If priory is set it makes the splitter only “take” from one lane of the other is empty and/or only output to one lane if the “priority” lane is full.

    That means if you have a full bus, you can put it through a staircase of splitters which will shove all the material to one “side” of the bus, only allowing materials into a lane if the lane next to it is already full. It’s functionality they recently added that caught me by surprise after a long break, it makes balancing large buses much more trivial than it used to be, and it makes it easy to “spot check” even very large buses if you use it.

    1. Shamus says:

      I did not know about that. Thanks!

    2. Retsam says:

      Yeah, some of these nice splitter quality-of-life changes were one of the later additions to the game in 0.16. I’m always forgetting they exist, too, because they weren’t in the game when I first learned it…

      1. Echo Tango says:

        They also have filters built in for free, too!

        1. Decius says:

          Yeah, you can use the filters to put multiple things on the same belt, if you’re very careful about keeping any one of them from backing up.

          Fancy smelting setups use them to sort the smelter outputs, and those setups only let ore into the system when it will be able to exit.

  9. Gautsu says:

    Just out of curiosity how much of you reader base are engineers/programmers?

    1. Lino says:

      Oh, I’d love to know that, too! Even if Shamus doesn’t remember the data from back when he used to have Google Analytics for this site, he could make a poll. A year or two ago he made one for the Diecast, and he got a lot of responses.

      If he ever did a poll like that again, I’d be very interested to know the results – it would definitely make for an interesting blog post (but then again, maybe I’m alone in my interest – I don’t know what percentage of this site’s readership are into statistics…).

      1. Gautsu says:

        I know making generalizations can lead to a lot of problems but I notice a ton of buy in on posts about games like this, Satisfactory, Minecraft, SimCity, etc., and on his topics over coding and language. It would be interesting to see if there is a correlation. My background is liberal arts into paramilitary, which probably explains why story, art, and music matter to me more than systems

        1. Lino says:

          My theory is that programmers are just a segment of a pretty much evenly split audience. The reason I think that is the fact that Shamus has accumulated a diverse audience throughout the years. DM of the Rings has brought in some people interested in tabletop RPGs some of whom have stuck around. His time at the Escapist brought in people interested in game design and the games industry (it’s certainly where I first heard of Shamus, with uis rants on EA). His time with Spoiler Warning brought in… a more general audience, I guess (don’t really know what kind of people watched that). His Mass Effect Retrospective brought in people interested in storytelling and game design.

          I think you could argue that some of these audiences have a higher than average representation of programmers and other technical people. But if you look at the articles with the most comments (which is a good way to gauge engagement), the most comments by far go to his more general articles – game industry rants, end-of-year round-ups… In one word – things that most people can form an opinion on.

          Then again, maybe those are just the people writing comments…

  10. Smosh says:

    The thing about Factorio that breaks my heart is that I think a lot of the recipes are very badly designed, and it has a handful of really massive issues because of that. Satisfactory is significantly better about that. To give some examples:

    1. Copper does nothing, but you need a lot of it. You don’t actually need (or want) copper on your bus. 99% of your copper goes into chip production. On top of that, the three levels of chips (green, red, blue) are made from one another, but in such a ratio and with so few extra parts that the best layout for chips is to not use a single belt. Just have grabbers between factories. 6 green factories into 4 red factories into 2 red factories, if I remember correctly. This means that this triangle of chip factories is better than dealing with belts.

    2. Science labs don’t need belts. You should never put belts around your science labs. You should put them in a row, and have grabbers carry stuff between them. This makes the fun part of balancing six types of ingredients around a large part of your base completely trivial. Just feed the first one, and then let the grabbers chain between the labs. Even without modded belts you can easily serve about a dozen labs in a chain, and then you just split in front of that and add more parallel chains. But you never want to deal with actual belts there.

    3. Solar panels are OP (and too early in the tech tree). I have never used nuclear, because it’s way more effort than plonking down a blueprint of 30 solar panels in one click, and there’s no drawback to doing that. Space is not a limiting factor when your power plants can be anywhere (unlike nuclear, which needs input belts). Laser turrets solve the problem of defense. Just slap down a BP with 8 turrets plus a large power pole in the middle, then deconstruct after use. Ammo or the tank are superfluous, just keep slapping down turrets that shoot energy, of which you have infinite due to solar panels.

    4. Logistic bots plus programmable chests really trivialize all production of items you need in quantities of less than thousands. You just have an input and output chest next to a lonely factory, program the factory with what you want made (e.g. solar panels) and then shift-click the input chest (and set some stack limits). Your bots will go grab the ingredients, and the factory will start producing. Soon you’ll have three stacks of solar panels which refresh themselves. This works for basically all buildings, train cars, upgrade modules, etc. I usually end up with a cluster of about 30 of these mini factories, covering half the tech tree just in case I ever need something.

    1. Echo Tango says:

      Some of these could be solved by another balance pass. From my limited time playing normal games, and longer time playing train worlds, this is how I’d do it: Solar panels should be about half as effective, and accumulators should be about a quarter as effective. Maybe even a quarter solar, and an eighth accumulator, if there was a “mark II” later on in the tech tree. For robots, I’d give them a lot less battery, and a slower recharge; I think they’re still useful to be in the game, but they’re definitely too easy to use on too many recipes. Removing the ability for inserters to pull from science labs and feed later ones – that’s an easy fix, and would at least require players to surround their labs with multiple lanes of belts. It’s not much more of a puzzle, but at least it’s something. Unfortunately, I don’t think the devs or many players would want those style of changes; They seem to operate under the assumption that if you’re choosing to ignore unbalanced things, then they’re not really unbalanced. ^^;

      The one thing you don’t quite have right, is the ratios of the different circuits. Green’s copper wires are useful to put in-line with inserters feeding the circuits directly (a small triangle of 3 assemblers on wires, 2 on green), but red and blue circuits are built much more slowly, so you can save a lot of wasted assemblers by using belts to feed them their earlier circuits along with the other ingredients. :)

      1. Decius says:

        Power is supposed to be a solvable problem, not a thing that you constantly have to manage. Once you can produce solar panels and electric accumulators you’ve solved that problem and shouldn’t have to worry about it any more than you worry about getting more railroad tracks after you’ve automated that adequately.

        1. Echo Tango says:

          The issue with that, is that solar is available much earlier in the game than nuclear, which is also much more complex. There’s no real trade-off to be made between those two systems, so solar’s just making an entire subsystem of the game totally pointless.

          1. Decius says:

            A good tradeoff would be a nerf to photovoltaic energy production (to make it not the endgame solution) and add a solar thermal power method.

            That would synergize well with nuclear thermal energy, by having multiple heat sources for steam turbines.

    2. Retsam says:

      Yeah, solar and logistics bots are the two things I usually avoid because I think they make the game less interesting.

      Electricity as a whole could stand to be more interesting – all throughout the game, it’s pretty trivial to have plentiful energy supply – even in the early game it takes basically no effort to have much more electricity than you’ll really need for a long time. (Just throw down a few steam engines, add a belt for coal, a turret or two for defense and you’re done)

      And, yeah, solar in particular could really use a nerf. It’s pollution free, not very expensive to build, not very hard to build (especially if you automate it with robots), and like you say, space is not exactly a limited resource.

      The one downside is that you need to make a bunch of batteries to go with it, since it’s an inconsistently available resource, but that’s pretty trivial, too. (Unlike real life where the lack of energy storage is a big issue with power grids – 95% of our power storage doesn’t come from batteries, but from pumping water uphill)

  11. Ralph says:

    Generally the community use the term ‘megabase’ for a factory that can consistently produce 1000 of each science a minute, however its designed.

    Your outpost based base might be considered a train base, the next logical level of which is ‘city blocks’ where you build a standardised grid of rails and put subfactories in the squares that get all their input and output via trains.

  12. Tom says:

    One enhancement to the basic bus concept I had some success with, last time I played Factorio, was to loop it back on itself and turn it into a sort-of ring buffer, or baggage carousel. This had the effect of not requiring ever growing numbers of production facilities to be added only at the very start of the bus to ensure enough material could be added to make sure at least some made it all the way to the end; they could be added anywhere around the loop that there was a gap with relatively little worry.

    This approach could be further refined by instead adding radial tributary buses that fed into the ring at nigh arbitrary points from clusters of production facilities to feed into the ring at key locations; splitters or selective grabbers also allowed outgoing branches from the core ring as well. The really nice thing about it was that there was no risk of accidentally having over-supply piling up in one area when demand there suddenly dropped, whilst some facility further upstream on the same belt was starving of the same resource – it would just loop back around to it again. You could also (if you’re a rebel and like living dangerously) have different things transported in the same stream with a bit less risk (but by no means none; it could still happen if the entire loop became glutted with one type!) of one particular item piling up and blocking the other one from getting to where it needed to be.

    Ultimately, this central-ring-buffer-and-radial-bus approach kind of functioned like a microcosm of the outpost model – only with no silent-death-on-wheels, I mean “trains,” to worry about!

    I also experimented with multiple linked ring-buffers. It was particularly handy having one concentric belt circling the entire perimeter of the base supplying bullets to all the turrets, when alien attacks were getting bad and the lasers (and the heavy-duty power grid they needed) weren’t ready yet – this belt could be fed at just one or two points and relied upon to ensure that all turrets were topped up everywhere – and kept topped up once the belt itself was completely loaded with bullets when the turrets were all full, like a gigantic contiguous magazine.

    1. Decius says:

      I like the idea of a ring bus, but despair at how to make a small one larger.

      1. Tom says:

        Yeah, that bit got tricky! Building a larger “U” shaped expansion alongside the existing, running loop, and then grafting it in at the junctions when it was basically already ready to go, helped eliminate downtime in the existing structure, but otherwise the only really useful technique I found was to always leave a few open pathways to expand, rather than building up too densely around the existing loop.

  13. Tom says:

    Fun fact: There are a few real-life examples of cities being laid out on something a bit like the “Bus” model, such as Magnitogorsk in the former USSR.

    https://en.wikipedia.org/wiki/Linear_city

  14. RFS-81 says:

    Interesting! I only played very little Factorio. I don’t think I’d have come up with the bus idea. My natural instinct would have been to directly try the outpost model, and probably create a horrible spaghetti base in the process.

  15. Javier says:

    My bus strategy always worked okay. Since the more advanced products are only needed for rocket/advanced research, you don’t have to add *everything* to it. I think in the end I only have iron plates, copper, green circuits, oil, and maybe batteries. Just put the rocket at the end of the line and all products flow to consumption. You can ‘cheat’ quite a bit later on with robots too.

    I hate doing plate production off-site because it makes resource bases take way too long to set up. By the time I am optimizing the setup for rocket launches I have to set up new mining bases constantly. Nearly as soon as I get a new one set up another is being exhausted. Having a central refining area just makes more sense than moving all those furnaces constantly.

    1. Decius says:

      Run power, place the blueprints, let the bots do the work.

      Deconstruct plan the furnaces when you’re done.

      It does take up extra inventory and logistics slots.

      1. Javier says:

        And tons of space, which is always an issue with defending outposts.

        A full furnace setup with towers + modules needs a lot of real estate.

        1. Decius says:

          A blue belt of furnaces is the longest line you can usefully make. Are you adding productivity modules and making the line longer?

  16. Gordon says:

    Another way to come at this is modular bases, these are bases that take coal, iron, copper, oil and water and produce a modest amount of science. This should be heavily beacon’d and balanced, but modest in scale. Once you have one of these working and fairly well tuned you can just stamp them down.

Thanks for joining the discussion. Be nice, don't post angry, and enjoy yourself. This is supposed to be fun. Your email address will not be published. Required fields are marked*

You can enclose spoilers in <strike> tags like so:
<strike>Darth Vader is Luke's father!</strike>

You can make things italics like this:
Can you imagine having Darth Vader as your <i>father</i>?

You can make things bold like this:
I'm <b>very</b> glad Darth Vader isn't my father.

You can make links like this:
I'm reading about <a href="http://en.wikipedia.org/wiki/Darth_Vader">Darth Vader</a> on Wikipedia!

You can quote someone like this:
Darth Vader said <blockquote>Luke, I am your father.</blockquote>

Leave a Reply to Droid Cancel reply

Your email address will not be published.