Hacker News new | ask | show | jobs
by lvice 1909 days ago
This winter break I spent an embarrassing amount of time on Satisfactory on Steam, which is essentially a nicer (and probably easier) modern refresh of Factorio.

While I played, I came to similar conclusions to the article. Building factories in this game is very very similar conceptually to building software. I ran into exactly the same problems that I ran while I build software like:

- If I don't plan ahead enough the scope and layout of the factory, I end up with a spaghetti mess that is very difficult to rectify (technical debt)

- If I plan too much ahead, I overwhelm myself without even starting. The amount over-engineering and over-preparation becomes counterproductive and demoralizing.

- Starting new factories is fun. Maintaining and extending a factory that is starting to show serious design issues is a chore. I always tend to want to scrap the factory and start fresh.

- While designing a factory, modularization is key. You can go with a "monolithic" factory where you provide all possible materials as input, and try to build everything as output. It is very efficient transportation wise, and can centralize all management, but it can and it will become an unmaintainable mess. You can also design factories as "microservices", where each factory is a very compact, clean and scoped. It will only produce nails, or rubber, or copper wire. When you need to increase production of that item, you just duplicate the module (horizontal scaling). It seems fantastic at first, but the issue is now transportation. Dozens of micro-factories have to communicate with themselves to combine and produce more complicated items. The physical distance makes planning transportation a logistic and construction nightmare. So you have to find the right compromise between monolithic and micro-services.

I think I agree with the article that you can extract a lot of information about how good a person can be at software development by the way he plays Factorio/Satisfactory. Not so practical though :)

13 comments

Saying satisfactory is a nicer factorio is ignoring everything that makes factorio a good game.
I think Satisfactory is “nicer” in that it’s prettier and more user-friendly, has higher production values, etc. Not to speak for the parent comment but I took “nicer” to be a very deliberate choice instead of “better.”

It is true that Factorio is currently a better game and I suspect that will be the case even when Satisfactory is complete. I don’t really think it’s intended to be a 3D Factorio (even if that’s the easiest way to describe it): it seems that the design is to be less intricate as a construction management game, but with more details in the world design and player exploration: there are elements of No Man’s Sky or Astroneer that are absent in Factorio. So I am still curious to see where the devs will take it.

Yes that's what I meant. I don't know factorio very well, "nicer" meant just that Satisfactory is more focused on being a pretty game with cool graphics and world exploration, and less "hardcore" on the automation stuff.
As someone who has played a bunch of Factorio but only heard about Satisfactory: Can you elaborate on that?
Factorio is very much like programming on a good team, automation, expansion, refactoring, tooling used to solve your problems.

Satisfactory is cool, but at no point do you get the "ok so I built this entire factory and now I can just replicate it modularly" - no, just place every, single, block, by, hand.

To me factorio is a rethinking of the RTS game, satisfactory is like a really nice minecraft mod.

> satisfactory is like a really nice minecraft mod.

Which is ironic considering a big part of the original inspiration for Factorio was factory building mods for minecraft.

Factorio didn't have blueprints either, early on. I suspect Satisfactory will add them as it is still in early access
They've said they won't have blueprints.

Now, granted, they might change their minds -- but it's hard to imagine how blueprints would work. Factorio is played on a 2D plane, with few obstacles in general and none that can't be removed; Satisfactory is played in a 3D world with immutable obstacles.

The game is tuned towards not needing blueprints. You don't need large quantities of anything, just a small amount of every item -- the complexity scales up, but the scale itself kinda doesn't. Yes, some players will attempt to turn the entire output of the map into turbo-motors, producing exactly the right amount of every ingredient, and will build their factory in the sky to avoid dealing with the terrain--

And yes, blueprints could be useful in this specific case. But that's not most players.

I think its possible, and I might switch over my opinion if such a thing existed - it'd still be hard to optimize it to build worlds of "factorio level" complexity.
Factorio is (kind of) infinitely scalable. There is no max map size, and the game engine's performance is so incredibly good that it can support absolutely insanely massive factories. You can go as big as you can imagine, and the game will keep up.

It's also ridiculously stable, in the ~thousand hours I've played I've never had a crash or a game breaking bug.

Meanwhile satisfactory puts you on a fixed-size map and will slow down to a crawl once you build too much. This limits a lot of the things you can do in the game.

The simple answer is scale. The recipes in satisfactory and factorio are pretty similar in complexity, but the production chains in factorio are quite a bit larger. Also a lot of complexity comes in with scaling production up in factorio, since you largely have to scale horizontally, but in satisfactory, most of the scaling is vertical. Later, you can do more horizontal scaling, but even into the mid-game, you're pretty constrained by the amount of resource locations you have access to.
I play both. Satisfactory has more game in the sense of doing things besides designing a factory. Factorio is close to pure factory building, whereas it's like 70% in saisfactory.

Satisfactory has more elements of a traditional open-world action game (that just happens to borrow factorio's factory system).

Also dipped my toes into Satisfactory this winter - after spending over 2,000 hours in Factorio.

Games like these challenge your ability to manage complex systems. Remembering which parts of your system processes which data (aka, "materials"). Finding and addressing bottlenecks in production lines. Maintaining and upgrading components, while creating new production lines using the techniques you learn. Managing time spent refactoring old systems vs replacing them with new ones. Etc, etc, etc. Planning properly - as you mention - is extremely critical to building a good factory.

However, despite over a decade of software development experience, and some time in Factorio, my first several play throughs in Satisfactory where an efficiency disaster, and even my recent ones were an ugly mess of spaghetti for the first few days of gameplay.

It took several playthroughs for me to grok the mechanics well enough to build a somewhat efficient factory. If my first couple tries were reviewed in a job interview I highly doubt I'd get the job.

There are strong similarities between these games and the mechanics software development, but like any new system, it takes time to create a true intuitive understanding of the mechanics and demonstrate them in front of others. If you're going to interview someone for a job, you're better off testing their ability to play the game that they'll be playing on a daily basis if they get hired: "Software Development".

Software Development, the game!

Want to play a game where you will never run out of new content? Where you are constantly challenged by new issues that'll haunt your dreams and make you lose sleep? Software Development is the game for you! With an ever changing landscape, where components and frameworks are updated daily! That's right, DAILY! This MASSIVE-multiplayer-online game never turns off. There are actively hundreds of thousands of players right now!

And you know what the best part is? Software Development is not "Pay-to-Play" like all those other games that try to steal those valuable dollars out of your pocket.

No, in Software Development YOU get PAID to play. That's right! All you have to do is find a company, nail a job interview, and enjoy playing the game you love while they hand you buckets of REAL LIFE MONEY that you can spend on other games that you have to pay to play. And also, food and rent and stuff...

Download now at, the internet.

Disclaimer: I've only played the Factorio demo.

If that's the analogy, then I don't think it captures the core difficulty of software, which is unknown unknowns. That is, you write something that depends on an external system working a certain way, you follow its spec and depend on it working that way, and then it just ... doesn't, and you have to find exactly where it deviates, possibly making up some complicated kludge.

To capture that, there would have to be e.g. some hidden logic about which direction the output comes out that you have to deal with and work around until you understand it.

There's not a lot of unknown unknowns in factorio, but one thing which it really captures about software development is your own decisions coming back to bite you, or emergent complexity from notionally simple rules. As your factory grows you'll find yourself wishing you'd built things differently because suddenly something needs to expand beyond what you expected or some part of it is right in the way of a train network. Train networks are really tricky to make work effectively, it's very easy to have deadlocks appearing if you make a mistake, and you might not notice until you suddenly don't have any power because the trail with the coal is stuck waiting at a fouled up junction or something like that. There's a lot of opportunity to debug problems as they appear even in something you designed entirely yourself (and in a multiplayer game it's even more so because you might be detangling someone else's build).

A lot of the process of learning the game is basically learning patterns to reduce this. At the higher level of megabase design it's basically about designing a modular system so you can scale things out as efficiently as possible (and there's lots of possible variations of this).

IANAProgrammer, to some extent I create my own GIGO issues which are like small instances of poorly defined behaviour. Sometimes you'll realise your whole world has ground to a halt and it's a conveyor backed up because one item arrived at an inserter and blocked it.

I play a bit of DSP but have at least 3 different mitigations which are akin to input sanitising. However, if you just stick a filtered inserter by a conveyor to grab errant materials then it can comeback and bite you ... though I've found either I can route them back to the proper channel or I can get away with the technical debt by throwing enough storage at them and leaving it until the thing needs refactoring.

You can have too much realism! I like that every green-circuit board works, rather than getting failures of systems that use that item with some random errors (that increase of your closer to the sun, say). I think that would be too frustrating.

I think this could potentially be the Biters - the enemies in the game that will periodically attack your base. You can guess that they will attack your base, but you are never sure quite when and it's always a concern in the back of your head.
I think this part is captured by Satisfactory "Tier" system. As you progress in the game, you unlock Tiers which allow you to build new materials and structures. The issue often is that you optimize the hell out of your factories to build something that is needed at you current Tier, and when you unlock the next one, you suddenly have to refactor everything to build the new items, that require different ratio of materials and inputs.
Satisfactory is really great, highly recommended from me as well. I think the verticality really adds a lot of fun over Factorio where you are restricted to keeping everything on the same level. Can make some really confusing spaghetti though...
The loss of 3D was one of the biggest things I missed when moving on from industrial mods for minecraft (the inspiration for factorio).

I recently got an RTX card and played around with the minecraft RTX demos. I decided to look further into behavior packs, and apparently the scripting API is much more capable than it previously was. The community of people making content is basically nonexistent, but I now think it's just because people have moved on.

Everything is in place to have added blocks, oregen, ticking tile entities, power generation/distribution, multiblocks, etc. It would be nice to see a behavior pack that picks up the torch of gregtech/industrialcraft.

Unfortunately, most of the unofficial GT versions have lacked proper vision. That is, vision in a way that is not aligned with GT proper, and what really draws players of industrial games in.

Anyway, here is a promising example. I hope to see more industrial content for minecraft for windows 10.

https://mcpedl.com/advanced-machinery/?cookie_check=1

Yeah, I love both factorio and satisfactory, but factorio ended up being the one I dumped more hours into.

Satisfactory ended up hiding too many details as you move around - the first person view and the very large structures made it really hard to untangle the mess.

Satisfactory felt like writing regexes - Basically write only, hard to read and parse afterwards.

That said, man the first person view is fun when you're actually doing the building. Just not nearly as fun once things have gone wrong and you need to debug.

Don't know if I agree on the height issues... every machine has ladders, they give you a tower fairly early on, and you can always walk on conveyors

As for debugging, I've found that planning a build on paper, keeping in mind production ratios, eliminates the need to experiment and debug, and then building simply becomes figuring out how to route conveyors

I've never had issues troubleshooting by getting to a high place and looking at the big picture, but to be honest since I started planning my builds on paper it barely even comes up

Now check out Dyson Sphere Program, it's like those games but in space ;)
I just got it recently and I enjoyed the heck out of it.
I've got to the "I probably need to leave my starter solar system in order to increase my DS production rate" stage, and honestly I think that's my limit. I find I can't recall where everything is (I think that can be fixed to some extent) and I'm not about to start writing documentation for a game!
>I'm not about to start writing documentation for a game!

Ha, I have a dsp.yml file for exactly that :D

I'll hand in my geek card at the next AGM. :D
This is exactly why I don't play games like factorio or tis-100. It's too much like work for me.
I honestly stopped after the winter holidays for this reason. At one point, it felt a bit too similar to actually working... but I enjoyed it very much until the "spaghetti factory point of no return" :)
I haven't played Satisfactory since the water update, so I have no idea if my approach still works, but IMO the easiest way to design an efficient factory is to not bother trying to balance anything, and scale out in only one direction as needed. Feed everything along a central stack of belts, and multiplex inputs/outputs via splitters/combiners so any individual machine line will always have throughput.

It doesn't make for a very exciting build, but it's very rote and dependable.

Also - build the entire thing high up in the sky.

I think that's why I dont want to get into these games. They feel like work!
The latest update in Experimental (in Early Access on April 13) adds Drones for point-to-point delivery without needing connecting belts or rails or whatever. They're pretty low-bandwidth so you can't use them to transport raw materials at any scale, but if your "microservices" are sufficiently focused at a higher tier, you can tie them all together pretty easily with Drones now.

At least, in theory. Drones are T8 tech, and I'm not _quite_ there yet to start putting that theory into practice. But that's the stated intent, at least.

+1 on this. I could never get into Factorio with the simple graphics and 2D top-down.

Satisfactory is freakin incredible and it is easily the best new game I have played in the last 10 years.

I am the complete opposite of you.

I could never get into Satisfactory with the 3D graphics, but I absolutely love Factorio.

If you enjoyed Satisfactory you might also want to try out Dyson Sphere Program. It doesn't provide the veritical building but it is a different take on the factorio/satisfactory style of gameplay.
I tried DSP, very fun game but the performance is terrible. i7-9700K and RTX2080 and I get 20 FPS before using even 1/10th of the first planet. Can't recommend it currently.
I've only played the demo of factorio, but on the same computer (AMD Ryzen 5, RX540) DSP runs much better for me - there's a noticeable slowdown on save now that I've covered about half my starting planet but other than that it's stutter free.
Interesting, while i haven't built a sphere yet I have factories going on multiple planets and haven't noticed any performance issues. I'm on a a 2700k with a 970GTX. Not suggesting you don't have issues, but perhaps there is a fix?
Factorio runs on Windows, Mac and Linux; Satisfactory only runs (currently) on Windows. Factorio is the better option, though Satisfactory is a great game non-the-less.
This is the reason why I don’t like playing factorio. I’d rather make real software and get paid or build something usable vs a game version of it. I spend a lot of time already doing it as my job, and it stresses me out in a similar way.
I like factorio because I don't have to have 17 meetings to get alignment on changing 3 lines of code. "I objectively need more electricity, so I will refactor the nuclear reactor" is the only agreement needed
That applies to any project where you work alone too.
The major difference between Factorio and software is you can't refactor in Factorio. Your options are to spaghetti or start fresh. You can't really pick and choose good pieces of your layout because of physical restrictions and the game is a giant math equation, and you want inputs to match outputs at every step of the way - if you don't have the space to do this you don't have the space.

It's like if in the software world you could greenfield, waterfall, or spaghetti. There is no agile in Factorio, which is broadly accepted as most commonly the best way to develop a piece of software.

You can absolutely refactor in factorio...in fact you have to refactor as you get access to better technologies. Just like software, refactorability is largely dependent on how well you design your base at the beginning. If you leave plenty of room for expansion and compartmentalize different production areas, it makes it extremely easy to upgrade with minimal disruption to the factory. And also like software, if you don't put any thought into the design at the beginning, it will probably be easier to start from scratch than try to redesign on the fly.
Ultimately how well your base is designed is completely based upon what things you need to produce in the future, what their inputs are, what their outputs are, what those outputs will be inputs into, and in which quantities you need to produce all of this stuff.

These are all things a new player has no clue about. All you're really saying is an experienced player that has done enough researching and equation balancing (X miners feeds Y furnaces and a line of belt can support Z miners) ahead of time should be able to design a base that doesn't require too much demolishing. And presumably, not overdesign in unnecessary base components.

It assumes perfect knowledge.

The closest to refactoring in Factorio is the ability to use bots to tear down and build blueprints. But you get that ability long after it would first be useful - that would be around when you get plastics, which easily triples the size of your base.

Ultimately how well your program is designed is completely based upon what features you need to develop in the future, what their parameters are, what their return values are, what those return values will be arguments into, and in what scales you need to run all of this stuff.

These are all things a new programmer has no clue about. All you're really saying is an experienced programmer that has done enough researching and equation balancing (X algorithms feeds Y threads and a processor can support Z cores) ahead of time should be able to design a program that doesn't require too much changes in the future. And presumably, not overdesign in unnecessary micro optimizations.

It assumes perfect knowledge.

The closest to refactoring in programming is the ability to use IDEs to remove dead code and do code generation. But programers learn about IDEs long after they would first be useful - that would be around when you get to integrations, which easily triples the code base of your program.

Everything you mentioned is also true about programming

But you can refactor... you can clear away everything and you get back 100% of materials
Demolishing your base and building a new one is not anything like refactoring.
It's exactly like refactoring. You can replace a component that does something with a different structure for accomplishing that. Of course, if the system was tangled, then you may need to refactor other components first (read: relocate them to give room). The structure of the base around something is going to place limits on the refactoring. If the base is so horrible that you decide to gut it entirely, it's just like a rewrite.
The efficiency of "refactoring" in Factorio is like refactoring code using notepad while typing with your toes and you're only allowed to compile the source once you're done. Which is to say: on a completely different level!
Why not? You clear out the part you don't like, and build anew

No, code refactoring does not fit perfectly in this analogy. And your ability to do so is somewhat dependent on how you build. But I think all those factors are simply part of the puzzle in refactoring a factory