> a certain component (electronic circuits) was being produced in 4-5 places. I eventually replaced them all with one centralised production array to simplify the factory.
Nah, electronic (green) circuits are high-volume but low-complexity to build. They are a good example of something that should not be produced centrally, because if you do, you have to invest a lot in high-volume transport to get them where they need to go. Much better to build dedicated electronic circuit factories wherever they are specifically needed.
Silly analogy to programming: Microservices. It makes sense to have a microservice to perform, say, user authentication, which is complex and only needed occasionally. It does not make sense to have a microservice to implement printf formatting, because you'll be calling it way too often and it'll waste a ton of network bandwidth. Better to import a string formatting library into each service.
Nah, as others have pointed out, green circuits are used everywhere. Since they meet that requirement, the only thing else to ask is, "Do the materials take up more or less space than the item produced?"
For green circuits, it takes less transport to move the green circuits than to move the materials to make them, so you should make them centrally and distribute the circuits.
Copper wire, on the contrary, is used in many things but takes up more space than copper plate, so you should make it locally.
Electronic circuits are a great example of "it doesn't really matter because for 99% of players the factory won't fall apart due to this decision."
In practice it can go both ways. Many of the production chains that take green circuits as an input require such low quantities that 1-2 assemblers is more than enough, so the marginal complexity of trickling them to where they're needed is low. And they only require the two basic input resources that are needed almost everywhere, so the alternative of making them on site isn't that complex either.
However, if you are trying to do a megabase (where you keep playing post-endgame and basically scale for the sake of scale), your green circuit demand shoots through the roof, and you will end up sinking half of your basic materials into making green circuits. At that point the plumbing itself becomes so complex to maintain high throughput that centralizing green circuits is an economy of scale decision. Additionally, the production ratios (number of assembler units you use for each intermediate product) will change, so it's easier if all of the green circuit production is in one place than to make individual changes in a lot of places.
Green circuits are distinct because (1) they don't save that much space compared to the basic materials you input to make them, and (2) demand for them is modest at first, but becomes a primary bottleneck if you're going for scale, and (3) their inputs are resources you need almost everywhere, so they're already there anyway. Most of the other resources for which you consider centralizing production, you do it because you save a ton of bandwidth by centralizing, or because demand is always high, or because the inputs are more complex to move (such as fluids).
In practice demand for green circuits is so huge primarily because of demand for blue circuits, so I will often make all circuits offsite and ship them in. The 20+:1 compression ratio you get from moving blue circuits offsite is a much bigger win.
Absolutely, Factorio has so many parallels to software engineering. My buddies have joked that you can tell how someone writes code from how they play.
I wonder what they would say about my factory style.
I tend to have a whole bunch of belts running from west to east, each belt carrying one type of item. When I want to add a new product, I put a splitter on each belt that carries and ingredient, with the second output branching down under all the belts carrying other products until it reaches a vertical line of assemblers. The output of those assemblers combines to a new belt that continues east.
The main factory ends up looking almost triangular [0], with vertical strips of assemblers dangling off the hypotenuse. One of the advantages of this approach is that scaling is simple, just add more assemblers and faster belts! Though it's possible to eventually reach a point where even the fastest belts can't carry enough products. In that case, you can just add another vertical strip of assemblers with separate inputs.
> However, if you are trying to do a megabase [...] it's easier if all of the green circuit production is in one place
As you allude to later, it's not really about green circuits for a megabase. Since blue circuits require 24 green circuits (20 directly and 2 for each of 2 red circuits), your huge demand for green circuits comes mainly from blue circuit production. It makes sense to centralize blue circuit production, so most of your green circuit production should be right next door, which is both on-site and centralized. But the green circuit production that isn't feeding directly into blue still doesn't really matter whether it's on-site or centralized.
If belt networks were only about capacity, sure. But you can't put two different kinds of things on the same belt lane without creating some serious trouble. So, the more different kinds of things you want to transport by belts, the more parallel belts you need. Plus, you need those parallel belts early on, even before any of them are running at capacity.
I find it much easier to lay down just iron/copper belts and upgrade them as needed -- upgrading speed in cases where adding parallel lanes is inconvenient.
- using machines efficiently (in the sense that a central production facility means idle-capacity can be used elsewhere)
- replacing production efficiently, I.e. yolo build a potato-quality factory now so that it’s actually producing, then expand it to hyper efficient maxed productivity modules in all the machines between maxed speed beacons later (so your resources go further and you don’t need to spend as much time building remote bases), but do not interrupt production forever to rebuild everything during the transition.
Yolo-building with a high quality strategy to replace components is also a great strategy for startups. In either case the real limiting resource is manpower.
And I typically target about 8 belts of green circuits, to feed a nonstop-rocket shop (avoiding the major transition off belts altogether.) Get a balancer design off the Internet. It’s fine. :)
Sure, but this is only an issue if you need less than a full belts worth of green circuits... if you remove that belt of green circuits, you are going to have to replace is with MORE than one belt of raw materials.
But you only need iron and copper plates to make green circuits; in bigger factories, if you want a central place to make green circuits, you'll end up having to use 3 dedicated belts just for green circuits.
But that's what I had anyway in my last game, a big central line with a lot of the essentials. I think next time I'll go for a central line with just iron and copper and mini bases that take from it, or something. More trains as well, bringing in ore from all over the map.
> Copper wire, on the contrary, is used in many things but takes up more space than copper plate, so you should make it locally.
I thought the same thing, but I think copper plate stores 100 in a stack and copper wire stores 200 in a stack.
I don't know what that means for inserters. (like low density structures - can stackers move more of them, even though you can store less in one slot?)
It's not so much about stack size as it is about how much you can fit / move on a conveyor belt. A lot of the setups I've used involve having a copper wire factory (or two) right next to the factory that uses them, no belts / buffers in between.
Gonna disagree there: green circuits (and their descendents) are needed often enough and in high enough volumes that it absolutely makes sense to bus them. I've got four full lanes being almost completely consumed, much by red circuit production.
Certainly if you need a very small volume in one specific location and already have copper and iron present you can slap down an assembler making copper wire and another making the circuits, but that's generally far less space efficient than just pulling them in from the bus.
> Gonna disagree there: green circuits (and their descendents) are needed often enough and in high enough volumes that it absolutely makes sense to bus them.
I think your parent was making a different argument.
Sure you use green circuits everywhere, but your compression ratio on belts is only 2.5 : 1. Not much better than gears, and I don't think anyone recommends centralizing gear production.
I too centralize green circuit production, but I think it's on the edge of what's reasonable
IMO, the thing that pushes it over the edge for me is that it takes 2 inputs (copper and iron), whereas resources that I distribute like gears or pipes only have 1 input.
To me the "main bus" design feels like Java OOP maximalism. Maybe some sound principles behind it, but feels too heavy-handed, unable to adapt to circumstances. Or at the very least, it's not any fun.
Main bus designs work really well for building one factory to launch a rocket because the resource demands aren't so high that you run into belt scaling problems.
If you're going for one of those crazy ridiculous high output post-endgame factories, the sheer complexity of running 8+ belts of one resource and branching off 2-3 belts at a time, then having to double that to go from 1k SPM to 2k SPM is way too painful. That's why most of the factories you see north of 2k SPM aren't main bus designs (aka well organized monolith), they're modular designs ("microservice" based). I put that in quotes because at those scales the sub-factory for creating a single input resource might be bigger than a whole base used for launching a rocket.
The analogy actually applies really well to software engineering: for a practice that works really well for 99% of the players (main bus), at a certain level of scale the approach breaks down, and you need a different approach to deal with scaling past that point.
As evidence for that, I usually use a main bus design to get to the endgame, but once I start the megabase scale climb, I break the factory out into discrete, networked (by train) modules in order to keep the resource distribution problem under control.
It's like the Event Bus pattern, instead of designing loads of point-to-point supply chains you build one big one where everything is pushed to, allowing random factories to consume the products alongside the bus according to need.
In my experience the main bus is perfectly adaptable until approximately “winning the game” (launching the first rocket). Making some broad assumptions, you need to reserve about 16 belts worth of bus width as an upper bound and that’ll be plenty for 99% of players.
It’s like the point of “most web apps don’t need distributed architectures until much later.”
This is the most interesting, friendly, respectful, online discussion about bussing I've ever read! Usually bussing is such a controversial divisive topic... Kind of like the "tabs -vs- spaces" of transportation and logistics.
>It does not make sense to have a microservice to implement printf formatting, because you'll be calling it way too often and it'll waste a ton of network bandwidth
It doesn't make sense to centrally build on belts. At high volumes where trains become more common it can be useful to move to buffer systems dedicated to circuits.
It highlights what resources you're short on more obviously (steel or copper).
Sometimes with caching it makes more sense to consolidate. Sometimes the scale can cause latency issues! It's about balancing tradeoffs
DRY, also known as single source of truth, is one of the most important principles in SE. I just could not figure out what the single source of truth is in a factory pattern as is the electronic circuit factory. It implies centralizing the code which is responsible by the fabrication of the circuits, what would be their equivalent in the game? The conveyor belts?
Microservices, on the other hand, are overrated and unnecessary in most cases they are applied.
This week I’ve both been playing Factorio, and writing code for a new application. So, lots of figuring out interfaces, architecture and modularity, and how things will work together.
When I change from one of these activities to the other, I have the distinct mental impression that I’m not switching activities at all. When I switch from Factorio to my text editor, it’s such a seamless transition, as if I’m just scrolling to another part of my factory.
Not a sensation I’ve had with any other game, or any other pair of distinct activities, really.
I figure it must mean Factorio makes me a better coder. I better get back to it, then!
This is one of the reasons I don't play Factorio, or games like it. The point of playing games for me is escapism and rest/recuperation. I feel like I only have so much programming time in me - I think playing these types of games makes me less likely to do some real work.
Plus the "achievement high" is much less; at the end of the day, when you win/do well - you know you're supposed to feel that way, the game was designed for you to win.
I like to sometimes just browse around in my side-project's UI or even codebase and appreciate what I built. Of course, you have to be in the right mind-frame for that. You don't want to go looking for your achievement high and end up thinking "Wow, all that effort and this is all you have to show for it?"
I tend to agree with you - but actually I love programming itself and I could do it all day without getting tired. The things that tire me out about work are poor documentation, inconsistent requirements, team politics, other people’s mistakes, compiler errors, version conflicts, the stress of having to deliver by a deadline or having other people depend on me, etc.
Factorio has none of that, it’s just a constant stream of positive mental stimulation.
There's "the itch" - the desire to program, to build something. Which I do find coding-style games tend to satisfy (so there's the fear I will have lessened motivation to work on my side project).
Then there's the "focus" side - I still love programming (and consider myself blessed for that). By "only have so much programming in me" I meant more "I have a limited ability to deeply focus within a given day/week". So I don't want to be thinking too hard when I game - I want to lose myself in the flow specifically without having to concentrate too hard (I find books/movies and playing hockey are great for this too).
Please note, I'm not arguing with anyone here - I guess I'm just talking out loud. It's not my intention to denigrate Factorio-style games in any way.
Yeah, that’s what always stops me from playing these. It’s fun at first (like any new project) but then I realise I could be doing exactly the same work and getting paid for it. Which I guess makes me super lucky in the “I get paid to play video games” sense.
That's kinda why I have taken up traditional film photography recently as a hobby, instead of just playing video games. Most of the video games I would be interested in playing would lean more towards the intellectual type games like Factorio, but yeah it those felt enough like work. I'd get bored playing more mindless games like GTA5 after a few hours, after the thrill of the graphics and open world gameplay died down. Photography has put my mind into a entirely different space, and challenged me in different ways than I'm used too.
I definitely found this with minecraft - building stuff there scratches the same itch as programming, so I mostly stopped doing it, since I'd rather make useful things than some random build in a world only I am ever going to see
But I love programming, why do I need to escape something I like? Even though you code professionally, doesn't mean you can enjoy programming personally.
You need to define rewrite and refactor. Extensive refactoring is rewriting. Analogy is not really great since most of the time in Factorio you will be refactoring by rewriting pieces of your factory.
But the balance is a good metaphor. After some time you will start your factories with at least some semi-bus, rather than just one belt for raw materials etc. but trying to start with final architecture from day 0 is probably a very bad choice.
It is a fun world where programmer-like thinking is rewarded and is a lot more visual. I’m not sure if it helps me be a better programmer but it solves an itch I have as a maker to design/build complex machinery that works together. The rails systems are particularly interesting to design and build.
However, once I launched my first rocket, the desire to play the game dropped and I’m playing other games now. But for a few weeks, I was so engrossed in the game that I even thought about design optimizations in my dreams. I don’t think any video game had me this involved before. I hope they build on top of it to create more interesting mechanics.
Once I launched my first rocket, I figured I’d try to aim for 100 Science Per Minute (spm) to see what the fuss was about in the community. That turned out to be a big and rewarding challenge. I still had a spaghetti base by the end, but it was far more orderly than what I had started with. It also forced me to learn game concepts deeper to hit that scale. Nuclear power production and coherent train system design each took me some time, but the result was well worth it.
I had a similar experience. For the month or so I was hooked, I felt attached in a way I haven't felt to a video game since I was a teenager. It almost felt sad when my interest dropped, like I lost something valuable.
I see a world where it's used to introduce slightly older students to programming (like 7th grade+) just like Minecraft is used in some classrooms right now.
I also would replace the Teamwork part of the article with achieving Modularity and Information Hiding.
Sounds like a game Jeff Bezos would have fun playing if it was about setting up a distribution center. Or rather, ordering production of the game and letting players figure out how he could improve its logistics.
Some of the areas the article leaves out are around throughout and bottlenecks... you are often limited by particular resources, and the ability to get them to the end of your factory line (I.e. the belts are saturated at the start of the line, but empty by the time they get to the new section of the factory)
Another interesting thing you learn is about a form of 'buffer bloat' (although it behaves differently than traditional network buffer bloat)
Essentially, having too much of a buffer for resources can cause inefficiency.
Say, for example, that you notice you are producing more green circuits than you are using. A naive response is to try to store them, so that your green circuit factories are running at full speed, and then when your need for them increases you will have them available.
However, this has two downsides. One, it will pull resources away from things you actually need in order to keep making more green circuits, even though you have more than you can use right now anyway. The copper that could be going to manufacturing the item that is your current bottleneck is instead going towards something you have too much of anyway.
The second issue hits you on the other side... when you DO start using more green circuits than you are producing, you won't notice until your issue is very severe, because you will have been using your reserves for quite a while. By then, you will have to increase your production a lot to make up for it... which might put a different resource out of whack.
The trick is to let the factories overproducing to backup production and stop... let that back pressure behave as a natural production regulator, which will make it much easier to have a factory that always works as efficiently as possible given your current raw material production.
Yep, the only places that I ever really need a buffer are train stops, power facilities, and times when you can't use a byproduct just yet (more-complicated refineries before you get your circuits tuned just right).
One thing I just realized this week is that a power generation buffer needs to alert me on the very first swing of an inserter from a buffer chest. If the coal/solid fuel line isn't completely compressed, that means the doomsday clock has started ticking.
I recommend avoiding steam buffers when you go nuclear. I had a setup with multiple storage tanks to hold steam, and that had buffer bloat because fluid/steam is hard to evenly distribute across many paths.
To be efficient with nuclear, though, you need steam buffers... nuclear power can’t stop burning fuel once it starts, so unless unless you are spending all the power as you generate it, you need to store it. Burn a unit of fuel, store all the steam, and then don’t put more fuel in the reactor until the steam level goes below a threshold, then repeat.
This is especially true because you want to have a group of four reactors together for maximum efficiency, which generates a crazy amount of power. You spend more time not generating more heat and just living off the steam storage than you do burning fuel.
Ok, but it isn't worth it. Yes, you get more "power value" out of nuclear fuel if you ration it. But even if you overbuild your power by 2x your current target load and let the extra go to 'waste', your ore reserves will still likely give you many hundreds of hours of power.
I've tried and made many buffered, circuit-controlled, meticulously fine-tuned power plants that are optimized for fuel conservation and they always have some hitch or edge case where they act erratically, or the steam is not balancing, or the reactors cooled down too much, or... (Or you're lategame and you outscaled it too far and need to eke the UPS back.) And is the moment when you're under siege and losing losing power really the best time to be debugging that 30-combinator fuel-optimizing circuit network you picked up off reddit and randomly modified until it seemed to work? Right.
A challenge: calculate how many hours the total amount of ore you are willing to mine will last you. If you maximize efficiency through productivity modules -- even gradually -- I bet it will be hundreds if not thousands of hours.
So you make a trade: a small fixed increased cost in fully automating and maximizing nuclear fuel production in exchange for the benefit of vastly reducing the complexity of construction and operation of your primary power production facility. No tanks, no circuits, no buffering -- instead, full automation and productivity for fuel production and 100% power all the time. Give yourself a(n automated) backup chest or two of fuel nearby for days (calculate it!) of time to deal with fuel production problems. Would you even have that much time if you burned all the coal in the same area?
> A challenge: calculate how many hours the total amount of ore you are willing to mine will last you. If you maximize efficiency through productivity modules -- even gradually -- I bet it will be hundreds if not thousands of hours.
What do you mean "hours"? It'll last multiple real-time years.
On what planet is a bang-bang controller considered a fine-tuned control system in an automation game? The only simpler system is proportional.
The point of doing it isn't necessarily for some maximum efficiency, but because it is the only problem in the entire game that could even ask the player to make a control system, which is a very fun thing to do.
If you build a controller for a single nuclear reactor, a bang-bang controller is indeed pretty simple once you know how to build an SR latch.
Scaling that to multiple reactors becomes complex because you can no longer control reactors independently and still get adjacency bonuses from them operating together. Further, there are complexities from emergent behavior that you have to control for. Steam turbines, like steam engines, auto scale steam consumption to power demand. The problem is they don’t do it uniformly. If you have 2 turbines attached to 2 tanks and you only need 1, the game might consume all of 1 tank first, leaving you with the 50% burst capacity. It becomes a big problem with day/night cycles and solar/accumulators in the grid.
I never tried to balance this, but I suppose it’s possible by building a circuit to link together all tanks and shut off their flow when one‘s storage deviates too much from the average. This sounds really complex to me and not worth it.
I’ve explained to the best of my understanding of the game engine’s behavior, but I know that fluid mechanics is also inaccurate and complex to design for. There’s a known issue with flow behaving asymmetrically. One reason is because the game updates state in a certain order, so water and steam flow with a bias for certain directions (n, s, e, w).
Also, thanks for teaching me a term from control theory (1)
Ah individual control of a large array of reactors is trickier. I think the bang-bang controller with keeping all reactors synchronized has good legs, but it stops scaling well at some point. If the buffers become the limitation and you don’t want to run all of the reactors synchronized then a PID controller would be a good pick. The output value would choose how far
up the row of reactors you enable. If you could force max load on will, then loop tuning is a possibility.
To maintain the simultaneous reactor bonus, you would want to keep the fueling cycle synchronized and just adjust which reactors are enabled each cycle. This can be done with a clock that has a period of one fuel cycle.
One interesting thing is that due to the nature of reactors, you will have higher efficiency in running more reactors if your buffer does not run out. It might be possible to eek out a little more efficiency if you fall back to a bang-bang controller in low load scenarios (making sure the threshold and number of reactors used won’t overfill the buffer, which is practically unlikely in low load scenarios). I would have to experiment with this a bit more to see if it’s reasonable to capture more efficiency.
All of this is practically orthogonal to the standard players perception of efficiency, but I find it fun.
Reactors don’t top out in efficiency at 4. I went from a 2x2 to a 2x7. My 2x4 power plant was buffered and would create flow problems when half of my buffers drained before the other half. When I scaled to 2x7, I dropped all but one tank to let me monitor when my reactors were above 500C.
My biggest learning with nuclear is that if I’m producing too much power for my factory, I’d rather grow my factory to meet my power supply than to make a more sophisticated power plant. Your mileage may vary.
Playing Factorio certainly feels similar to some kinds of Software Engineering.
But I don't particularly like the comparison because a huge thing about Factorio is the restrictions on physical layout. Due to this physicality it is very expensive to refactor in Factorio, you are going to be working with more components working together at the same time, and the fine details matter way more on every level because if you're off by a single tile, it all comes crumbling down.
Because of this, in Factorio you really cannot refactor your way to a base producing something at a new rate in Factorio. The only method is to design a brand new production line from scratch and rebuild - basically, all you have is waterfall and rewrites in your toolkit.
I don't find this to be true once you have automated production of all the buildings and use construction bots. Combined with the recent(ish) improvements to blueprints, blueprint books, and cut/copy/paste makes fixing those off-by-one errors quite painless: 1. Ctrl+X to cut and auto-deconstruct the build, 2. Ctrl+V to paste in the correct place, 3. Go fix something else for 2 minutes. :)
This essay highlights my core impression of Factorio that's kept me on the fence about buying it - it certainly looks like a fantastic game, but since I already enjoy designing programs and coding, every time I consider trying it out I just tell myself, "I'll just open up my text editor" instead. Is there a good selling point to push people like me past this mindset? Or is the game probably just not for me?
I think the first analogy the author made to shenzen io is still a good one for factorio, just a lesser scale. This is engineering without many of the messy unfun parts. No setting up tool-chains, or build tools, or your environment and being totally lost in what to do. The game itself will (usually) not have bugs and it has a clearly defined goal (which can be difficult for things like personal projects if that part of the creativity/drive just isn't there). So even if it is a game that invokes the messy parts of engineering, it does so without actually making them sometimes intractable because it has been designed around those (and in fact is designed to specifically smooth out the curve of difficulty).
The other thing to keep in mind is that like many of the zachtronics games this one is not directly programming. The spatial orientation puzzles and 2d layout and organization of the factory is distinctly different from most programming. I would compare it to trying a language like Lisp or Haskell when has only used languages like C, C#, and Java. It's a totally different take on the concept of symbolic computation (re: programming). And it is one unlike any programming language you will have ever used. So if you enjoy the experience of learning new paradigms, and viewing classic computational ideas from the perspectives of those new paradigms, factorio might be fun for that.
To me, games like Factorio (and other programming games like Satisfactory, Human Resource Machine, and many of the Zacktronics games), mimic the fast edit-compile-debug loop and solution search that you get when you have minimized a problem to a core algorithm/data structure or some OOP design you are trying to refine.
They take away all of the boilerplate/dependency/platform busywork that you might need to do to actually ship something.
I don't know what it is (despite racking my brains about this for years), but there's something about Factorio that makes it much more fun for me than programming -- unless the programming I'm doing is something I'm intensely interested in, which programming for work rarely is.
Factorio is like a distillation of programming so as to retain the fun parts and minimise the unfun parts.
What do I mean by the unfun parts of programming? Real-world stuff that you inevitably have to deal with but which distracts from the core purpose.
Things like: discovering a bug in a library you depend on; dealing with hardware issues; changing requirements; disagreements with colleagues over tooling; deadlines; dealing with users; ...
I was just thinking... what if Factorio it's the perfect waterfall project?
clear and unchanging requirement (build and launch a rocket), infinite time, infinite resources, perfect technology. The only bugs are those attacking you from time to time.
The only thing left to do is to implement the solution, in whatever manner you please, as long as the requirement is met.
Maybe that's what keeps a programmer so addicted to it; with no stress of changing requirements, or pivoting, or deadlines, one can 100% focus on the technical part.
Thanks y'all. Yeah, basically I was dumb and somehow missed or ignored Factorio's demo. I downloaded and played a bit of the demo last night, and while it's certainly interesting, this type of resource based dynamic system builder just isn't for me if it lacks an adversarial agent.
Then again, while typing this reply, I searched for "competitive Factorio" and found this mod[1]. So, thanks for broadening my gaming horizons!
first, i think there's a demo, so give it a taste for free if you're interested
second, it's similar to how watching a documentary is sort of like knowledge + entertainment. i think you'll find factorio pulls a lot of the same sorts of levers that designing programs and coding do, but it's a different feedback mechanism (visual, or base destroyed by biters) versus... well, i almost would say acceptance/integration tests, but if you're just brainstorming, it's not clear to me.
In your spare time, would you rather do programming projects, or play a game?
If you'd rather do programming, then keep doing what you're doing.
If you'd rather play a game, then download it and see if you like it. If you like it, then play it. If you don't then continue your current habit or search for a different game.
Think of it as a simulation of a load of event emitters / consumers, but you don't have to think about them yourself, allowing you to focus on hooking them up and solving issues like starvation or congestion all the time.
I think you should try the demo and see how it feels. If you’ve found yourself at this particular junction multiple times, might as well indulge and find out.
I watched an hour or so of Let's Plays just now. Factorio really made me reminisce about playing Tekkit, especially the Red Power mods from Eloraam (man, I miss those), plus ComputerCraft, BuildCraft and not to mention IndustrialCraft2. It's the only reason I bothered to learn Lua and FORTH lol. However my thinking now is that programming probably gives me just about the same level of fulfillment and challenges, sooo I think I'll stick to that. Factorio does look very fun though!
Not surprising that you made those connections: one of the main devs and creators of Factorio have mentioned that the game arose in part from their frustrations with the poor scalability of tech/industrial Minecraft mods. Specifically, IC2 is called out as having some influence on the design [of Factorio].
Come on Buildcraft is bad. Buildcraft pipes drop items when they hit full inventories. Eventually you end up dropping a million items on the floor and your game becomes unplayable.
I don't see it like that. Instead you have to engineer your project around the weaknesses. This is one of the fun challenges of using BuildCraft. Of course, I can see how this frustrates server owners, who have to deal with all those users who don't know how to use it correctly (or who use it in the wrong way in order to troll or blackhat).
Factorio is the only game I can think of that could be used for education while not feeling like an "education" game. Most educative games (from my experience) are not fun. But Factorio is a metaphor for real world software engineering and it is done without the player needing to be aware of it. Absolutely beautiful game design.
I feel like this is what education will look in the far future.
Coming to Factorio from a Scala/streaming/data background, I got the connection pretty immediately - so much of Factorio is about designing correctly for backpressure, such that your factory works stably at different levels of capacity and resource consumption. That said, I still never really got the knack of blueprints and large-scale planning, so I've got a long way to go still.
I find it interesting that you mention easily grokking backpressure in Factorio yet have more difficulty with blueprints. In my experience, people "get" blueprints much earlier on than even the idea of backpressure.
Given you say you come from a data streaming background, I (idly) wonder how much your Factorio "skills" could benefit from you picking up a book on design patterns in object-oriented approaches.
Here’s a list of games I think software developers will enjoy if you want to take the enjoyable aspects of software design and automation with none of the downsides:
Human Resource Machine and Seven Billion Humans are among my favorites. They are made by professional game developers, so the interface is really smooth. Seven Billion Humans is the sequel, adding parallel processing.
And don't forget Corewars. You can still compete online against other humans.
I want to enjoy Satisfactory. It has it's own charm to it, and I love their interactions with the community.
But doing everything from a first-person view is often frustrating. Being able to have multiple layers of belts is nice, but sometimes its annoying dealing with collisions. And while the terrain is beautiful, I often find it just gets in the way of your factory more, and the option of just laying out tons of platforms is unnatural and just hides the beautiful scenery.
If you really think about it, Satisfactory is a game about destroying a beautiful planet with huge concrete platforms and heavy machinery in pursuit of strip mining all of the world's resources and delivering them to the capitalist overlords via a space elevator.
At least, that's where I think the story mode's gonna go.
Don't give up on Satisfactory though! Managing collisions gets easier as you play more, mostly just leaving a lot of room and using vertical space. The jetpack really opens up the game.
The last part also has been a key impression from watching a bunch of Let's Plays. Beautiful world, but you are limited in how you integrate with it (which to be fair would be a crazy challenge to do really well, but still).
The author mentions Shenzhen IO. I found great value in that game. It's limitations force you to think about simpler, elegent solutions in ways we frequently don't have to today because storage and ram and CPU cycles are so abundant. I actually feel it's helped me seen simpler, more easily maintained options in my work.
They truly do entice you to find more elegant solutions. One thing they show in the post-mission report is your solution's code line count, energy use, and component cost versus others in a graph. I didn't consider myself "finished" on a puzzle until I had figured out how people got to that super-optimal solution which sometimes took multiples of the amount of time of the original solution but damn was it ever satisfying.
If you like the look of Factorio but are (like me) intimidated by the open-endedness of it, check out the puzzle games by Zachtronics, the developer of Shenzhen I/O. Because they're divided into small levels that teach you how to play, they are much more accessible than Factorio, which requires dozens of hours to get good.
Infinifactory and Opus Magnum are the easiest ones to get into. All are great.
Opus Magnum gets my vote for "best introductory Zachtronics game" - very polished, simple concept, and you can almost always brute force problems rather than be super precise so there are no real "puzzle of death" moments where you just can't figure something out.
Many of the other games build to a level of difficulty that I find drives people away around the mid-point. There's some significant mental leap you need to make, or you need to cram things into an impossibly small space, etc. Opus Magnum is a lot more forgiving in that sense.
I've only played Opus Magnum and Infinifactory, and my experience is that the "programming" and "debugging" environment is far superior in Opus Magnum.
Just sitting back and watching your builds run in Opus Magnum is far more satisfying. And it has an interesting solitaire game, too.
I read about it a couple of months ago (it was featured in one of those App Store articles, I think), but then I promptly forgot about it. Have you tried it? Would you recommend it to people who already know how to code?
Edit: now I think it might've been 7 Billion Humans, by the same company
I've 100%ed both; they are good with a mildly-dark sense of humor. HRM feels like assembly on a very dumb chunk of silicon. 7BH feels like a very dumb GPGPU language.
I've played factorio for years and more recently just focused mainly on speed runs for launching rocket. While there is some analogy between factory design and software design, I wouldn't read too much into it. The biggest lesson from either side is likely modular components that you can connect together quickly with automation tools to make it quick to build. If you incorporate anti bug (literal bugs in factorio) into your designs with automated repair then you almost never have to worry about bugs. Don't have lots of dependencies, build isolated services to focus on certain things. Have a high speed bus for different services to communicate over. Keep comms efficient and direct as possible. Build with scaling in mind. If you need something quick, build in an optimal way without considering scaling beyond your goal.
I've spent so much time in Factorio, I'm sure I'll fire it up again at some point soon now that it's finally hit 1.0. I mean in my opinion it was "done" years ago in that it was a good game, the only thing that might improve it would be a better tutorial, story mode, or more 'endgame' things to reach for (I'd love a technology tree beyond satellites, I'm sure there's mods for that), and / or for the early game to be less tedious; maybe offer an option to have a starter base laid out already, needing some basic repairs. Or as I've seen in the trailer released recently, the crashed ship; have that act as an early game processing plant and source of materials and electricity which you can eventually deconstruct once you've got everything up and running.
What happens to me is that I find 45 minutes to play a game after I put the kids to sleep, so I fire it up, wait 30 minutes for the latest update to patch since I haven't played in 6 months, then realize I'm tired and go to bed.
Play now. Kids ruin gaming. I'm hopeful that soon they'll be old enough to play with me. ...I wonder what game is good to play co-op between a 40 and a 6 year old?
I remember reading a post on r/factorio where someone played factorio with their toddler. The toddler had researched like ten things without making a single assembly machine.
The patches between 0.18 and 1.0 added some very ergonomic blueprint placement in map mode. You can place blueprints directly on the map, and design them in a way so that they snap to a grid.
Nilaus did a video recently on city block architecture, where you make large, uniform blocks to do one thing and one thing well. I want to give this a try, but I may also copy some of his blueprints to start with.
He said this style is like service oriented architecture software design.
I’ve used a mod called simple start (I think) which gives you some nerfed construction drones that move slower than late game drones. They get the job done, though.
There are also jump start blueprints on Factorio prints:
This is a great article! It’s surprising how much tech debt pops up in games like these.
Another game much like this is Satisfactory, which is basically the 3D version of Factorio. I actually wrote a very similar article about it here, though more focused on architecture instead of process: https://medium.com/@wotamRobin/what-satisfactory-and-website...
If you like Factorio, you should also try "Human Resource Machine" by Tomorrow Corporation (https://tomorrowcorporation.com/humanresourcemachine). I am not in any way affiliated with them, but I enjoyed it a lot, so would highly recommend.
I really enjoy playing them both every now and then. I found them to work really well on my Nintendo Switch, where I would just unplug the controllers and play them like a mobile game with the touch screen, as they are perfectly suited for that.
I just realised that I hadn't even tried it with the Joycons. I just went and tested and... it works, but to be honest, it's not great. You have to use them detached and you use the right one like a Wii mote, you point it at the screen and it creates a cursor/finger.
I would 100% recommend rather playing it in handheld and using touch screen after testing it out. Maybe you could get used to it, but personally I hate the "remote pointer" thing.
Unless I'm misunderstanding, but I couldn't get anything to happen in the game when I had the Joycons attached (I only play handheld) and only when I detached did it ask me to place the right one flat on a table to calibrate and then show me how to center the cursor.
As someone who's put a lot of hours in Factorio, I totally agree with the article! I kinda guessed what it was gonna say before reading it.
My coworkers and I played a lot of Factorio in the past and we always joked about it being like a programming job. I even had a trello board for the largest base I ever worked on (I never finished it)
I'm not the parent, but it's nice to deal with an environment where the stakes are low, and I can afford to play. In my day job, I can't often implement greenfield solutions and play with systems as toys without consequence.
One thing that I like about these style of games is that they subtract the fiddly parts of programming that I don't find particularly enjoyable: things like dependency management, fiddly environment details, differing compiler versions screwing things up. This is because, of course, it's not real and so doesn't have to deal with the messiness of the real world.
My main job is programming video games, not boring at all. Even for us Factorio is a perfect addiction. So much so our main game is a train tycoon version of factory automation.
When I started playing Factorio years ago I heard someone saying it closely resembled EE, in that items on the conveyor belts resembled electrical pulses and the belts themselves were wires. It's interesting to see those comparisons shift to software engineering
My 11 year old started playing Factorio a week ago, and I knew it was a gateway drug to software development. I hope he keeps enjoying it and gets a career out of it, would be amazing! Especially the technical debt aspect.
I showed it to a friend last night, first thing he said, 'hey this looks a bit like programming'.
Me being a programmer only saw a 2D version of Minecraft (my initial opinion), and I thought I wouldn't like it too much. Been playing the demo non stop. will buy it later tonight... AFTER work... :+)
p.s. I hope it keep in development for a few years so I can play this with my (now too) little one too.
Factorio has been around in "open beta" for something like 4 years now (and I've been playing it for at least 3), so I suspect it'll be around a while longer.
However, even if the developers stopped updating the game, so long as the game runs on your PC, does it matter? We have people doing crazy things like effectively emulating DOS in Javascript so that you can run DOS programs in a browser window (see archive.org's DOS game section); somehow I don't think you need to worry about not being able to play it in a few years. It's all local by default, so you're not having to worry about someone taking the game servers offline either.
> IMO, playing Factorio will not make you a better software engineer.
I'm of the opposite mind: Factorio helps reinforce good habits, and practice methodical planning and thinking about hacks, tradeoffs and technical debt.
You forgot the most natural analogies to distributed stream processing and handling volume and velocity and how that differs between belts and drones, etc.
Yes, luckily you can use whatever planning methodology you prefer. Graph paper and spreadsheets are frequently mentioned, as is doing the planning at work so that you have more time at home to actually build :)
In biology, if I remember correctly, you have anabolic and catabolic processes: anabolism constructs complex molecules from simpler ones, catabolism breaks down complex molecules into simpler ones. Both processes work together, with catabolism providing the energy for the anabolism.
I've you dig PC games that emulate some of the workflow typical of software development you should definitely checkout Zachtronics games. Almost every single game they've released is a tour de force.
Seriously? Keeping track of technology, reading other people's opinions and first-hand experience, feedback, leads on topical news, trends, developments. The list is endless.
Nah, electronic (green) circuits are high-volume but low-complexity to build. They are a good example of something that should not be produced centrally, because if you do, you have to invest a lot in high-volume transport to get them where they need to go. Much better to build dedicated electronic circuit factories wherever they are specifically needed.
Silly analogy to programming: Microservices. It makes sense to have a microservice to perform, say, user authentication, which is complex and only needed occasionally. It does not make sense to have a microservice to implement printf formatting, because you'll be calling it way too often and it'll waste a ton of network bandwidth. Better to import a string formatting library into each service.