Factorio and Software Engineering
blog.nindalf.com
blog.nindalf.com
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.
300 copper (= 600 copper cables) + 200 iron => 200 green circuits in a stack.
Microservices, on the other hand, are overrated and unnecessary in most cases they are applied.
You design a decent submodule one time and then make a blueprint and reuse it repeatedly.
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.
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.
That said, your compression ratio on trains is double that again, because the green circuits have a stack size of 200.
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.
> unable to adapt to circumstances
One side main bus should be adaptable to many circumstances. I wonder what you mean by it cannot.
It’s like the point of “most web apps don’t need distributed architectures until much later.”
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.
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 you can, it's called a "sushi belt" and with some simple combinators, it can work reasonably well.
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.
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.
> it doesn't really matter because for 99% of players the factory won't fall apart due to this decision
"Do I Need Kubernetes?"
> it doesn't really matter because for 99% of developers the infrastructure won't fall apart due to this decision
Factorio and Software Engineering :)
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.
[0]https://media.discordapp.net/attachments/741107040079970314/...
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?)
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.
Can make your train routes/efficiencies easier to manage.
This and parent post quickly proved my wrong.
Sometimes with caching it makes more sense to consolidate. Sometimes the scale can cause latency issues! It's about balancing tradeoffs
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!
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.
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?"
Factorio has none of that, it’s just a constant stream of positive mental stimulation.
Different strokes for different people of course.
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.
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.
- Learning to more heavily prototype, bootstrap, and rewrite, rather than refactor.
- learning to "just ship it" and get by with "ugly" operations that work well enough
- learning to balance the two often-contradictory points above
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.
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.
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.
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.
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?
I would take a trade like that every day.
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.
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)
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.
https://en.wikipedia.org/wiki/PID_controller
https://github.com/quchen/articles/blob/factorio/factorio/ci...
What do you mean "hours"? It'll last multiple real-time years.
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.
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.
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.
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.
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.
Hopefully that's helpful.
They take away all of the boilerplate/dependency/platform busywork that you might need to do to actually ship something.
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; ...
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!
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.
- Factorio
- Kerbal Space Program
- Oxygen Not Included
- Shenzhen I/O
- Exapunks
- TIS-100
Always looking for new suggestions :))
And don't forget Corewars. You can still compete online against other humans.
Also Spacechem for learning about threads and mutexes
Factorio but in 3d.
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.
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.
Transport Tycoon and similar games also come to mind. Recent iterations are things like Mashinsky.
Democracy (3) might fit.
Infinifactory and Opus Magnum are the easiest ones to get into. All are great.
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.
Just sitting back and watching your builds run in Opus Magnum is far more satisfying. And it has an interesting solitaire game, too.
Edit: now I think it might've been 7 Billion Humans, by the same company
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?
You could try factorio. It has trains, tanks, bugs to shoot.
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.
https://www.youtube.com/channel/UCD80bzqJh1N7lOqn7n0vKTg
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:
https://factorioprints.com/view/-KuGj0uUTKl8VpIau-_l
I haven’t tried this though, and the top comment says it needs updating. Still seems like a pretty decent start.
https://www.vice.com/en_us/article/4x38aq/why-do-we-play-vid...
I used the excel to get into a job as a developer helping an actuary, and the arbitrage to do market trading.
I can recommend spacechem, which looks simple at first glance, but is all about threads,multiprocessing, mutexes etc.
Silicon Zeroes is also another great game for developers.
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...
There are a few other Zachtronics games that you might like too!
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 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.
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)
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.
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.
I'm of the opposite mind: Factorio helps reinforce good habits, and practice methodical planning and thinking about hacks, tradeoffs and technical debt.