Factorio is a game where you are a teeny tiny engineer has been stranded on a very large and hostile alien world. Your goal is to build a rocket and shoot yourself out of there, but that’s going to take some serious work!
You start with just a few basic tools and materials, and you can use those to build better tools and accumulate more materials all while trying to fend off hostile aliens lovingly called biters.
Now that doesn’t sound so different from other mining, crafting games, but the big difference here is in the scale.
Much like real life – building a rocket by hand, from scratch is impossible. Not only would it be time prohibitive to manually create every nut and bolt you would need, but there are some things that you simply cannot make with your own two hands like battery acid or petroleum products.
Your only hope is to automate the mundane tasks as you bootstrap and leapfrog your way to a highly scalable, and robust distributed factor y system.
Hey, that sounds a lot like programming!
How is Factorio like programming?
Much like programming a highly scalable, distributed system – it’s hard, and you are going to make mistakes, and you are going to spend a TON of time refactoring.
And remember the hostile aliens? They aren’t so bad in the beginning, but as the game progresses they become more and more aggressive. which adds some tension and urgency to your situation, and it means that you are essentially forced to sometimes make short-term tactical decisions that conflict with your larger strategic goals. These decisions help get you through your short-term problems, at the cost of increased pain in the future. This phenomenon, is known to programmers as “Technical Debt” and in many ways, Factorio is really a game about managing Technical Debt.
Sounds like great fun, right? …but really, it is! Let’s start with those biters!
#1 Security by Design, Development, and Deployment / Defense in Depth
If you’re playing with aggressive biters enabled then you need to start thinking about security before you need it. If the aliens are able to skirt or overwhelm your defenses it can be really difficult to recover because you need to balance your time between fortifying your factory, repairing the damage, and keeping your resources flowing.
Life is much easier if you start thinking about security early in the process, because it’s can be difficult or even impossible to recover.
#2 Designing for scale
Much like lesson #1, a little forethought upfront can save you a lot of time down the road when it comes to scaling.
Once you get your basic materials automated, it’s tempting to just fit belts, furnaces and assemblers in where it’s convenient. This works out great in the beginning because it takes a minimum of resources but the routing you need to do gets worse with each addition. A design like the one below is much better, because you can strap on additional components as needed to scale up the factory without having to do any plumbing.
The lesson here, is that it’s important to design for scalability before you need it. If you wait too long, and focus too much on tactical decisions over strategic ones you’ll quickly and frequently find yourself boxed in.
Which brings me to another design time lesson:
#3 Modularity and Abstraction
As your factory grows, you will eventually start running your initial resource pools dry. If you haven’t properly accounted for this inevitability, then it can be difficult to resupply your factory as you add new pools of resources. It’s typical for new players to build their factories around their initial resources. It evolves that way organically because it’s a cheap and convenient strategy early on but it causes great pain and crappy hacks to get around mid to late game as you need to spend a lot of time building in “clever” routing to wiggle resources into your center. If these hacks become bottlenecks then they can be really difficult to work around without changing large portions of your factory.
A better approach is to separate your inputs, logic, and outputs so you can scale and route them independently. This insulates you from having to make changes later because of future expansions.
This one reminds me of the open-closed principle, designs should be open to extension but closed to modification
Speaking of making changes, the next three lessons deal with techniques for making changes
#4 Profiling is important
It can be difficult to see supply chain problems before you suffer an outage, and one outage can often cascade into others. so it’s important to use the “P” screen periodically check on your productivity and consumption rates. If you are using a resource faster than you can make it, then you are eventually going to suffer outages because of it.
Usually you want to scale out to meet production demands, but as resources, space and time are limited it’s important to focus on things in the right priority.
#5 Safe refactoring
Safe refactoring refers to small and discrete changes that make things better without breaking the system. It can be tempting to rip up large swaths of our factory in order to do things “right” but if you go too far down the rabbit hole then it can be difficult to get things back to a stable state.
This can be especially bad if the biters start heating up while you’re redoing the power grid.
Same thing applies to programming, it’s much less risky to make small isolated changes and slowly work your way towards a larger goal. Especially if you have deadlines to meet!
#6 Managing Technical Debt
It’s easy for me to say that you design for scalability up front. Turns out, that is really difficult. You are severely resource constrained in the beginning of the game. If you try designing your factory for the end game at the beginning, then you’re going to need a lot of resources up front to lay the proper infrastructure. Trouble is, it’s hard to gather a lot of the resources you need until you’ve moved up the research tree.
The trick is balance your factory between your current needs and your future plans. It’s a tough balance to get right, much like managing technical debt when you are coding. If you spend a lot of time up front trying to design the perfect system, you run the risk of running out of resources before you start providing value. Additionally, it’s nearly impossible to fully plan a large system out ahead of time so it’s difficult to make correct decisions too early in the process. That’s why it’s important to try and keep a good balance.
Taking on technical debt is a great way to start delivering value early, the trick is to be smart about when you repay those debts.
So woah, those are some pretty heavy lessons!
You aren’t going to learn any syntax or fancy from playing Factorio, (maybe if you start looking at the making mods!) but I do think there are some valuable higher level lessons we can get some experience with by playing the game.
And there ya have it folks that’s how you can justify spending time at work playing Factorio. If your boss gives you a hard time, just tell them that you’re working on these six skills and everything will turn out great.
Let me know what you think in the comments and if you like content like this, make sure to check out the Coding Blocks podcast!
Top comments (9)
Factorio is still sitting in my Steam wish list.
A bunch of years ago I read an article by someone (Mike Acton?) that said something to the effect of SpaceChem being like PS3 SPU (SIMD) programming. For a while I toyed with the idea of using it as a test for potential hires. =)
I've heard of the Zachtronics games a few times, but have yet to really play them. I always thought Opus Magnum looked like a lot of fun. It's on sale today too, sold!
Might as well pick up Space Chem while I'm at it, though it looks a bit daunting :)
I found SpaceChem a bit easier than Opus, maybe I was just younger and had more time to burn though.
If they appeal to you, gave a look at Shenzen I/O, you have to program chips with constrained resources in a fake assembler. I found the difficulty curve quite staisfactory.
I'd never even looked that they have other games. Into the depths of my wish list they go! Thanks for the suggestions.
It was a good read and a very good analogy. Too good even, as in my current playthrough I am stuck in rerouting all the raw inputs to the main two factories I have, which feels like having to do a massive refactor in a big software project!
I think #6 has some links to sacrificial architecture, at each stage the base you are building is just a bootstrap for the next scale that you are going for. It isn’t going to handle the next level of scale but it will be faster to build it to automate some tasks and then trash it when you have robots
I had been a dev for quite a while before I started playing, but it taught me so much about the process of writing code. Automating the simple but repetitive tasks as far a possible is absolutely key to achieving any sort of productivity
Oh, please let's start a DEV.to unofficial-official Factorio server. Please please please.
Oh and before I forget: The Factory Grows
The Factory will grow evermore
:)
I saw a video with 159 people playing in a single Factorio game, it worked out surprisingly well except for a couple jokers that were saving the game and slowing things down.
i really enjoyed reading this