6 ms·

My friend has 600+ hours played of Factorio. He just beat the game for the first time. I bought it, we played multiplayer. And I taught him the mantra "great i

My friend has 600+ hours played of Factorio. He just beat the game for the first time. I bought it, we played multiplayer. And I taught him the mantra "great is the enemy of good enough". Our run took 14 hours. I also know many people like this at work, and wish they could have the Factorio experience. If you refactor at the first sign of trouble, you remain blind to totally new to problems just around the corner.

skipants 5y ago
That's been my takeaway from these games, too. It really helped with my perfectionism because it makes the negative effects of it tangible; you notice how much more time you lose by trying to be perfect rather than just getting your supply of materials up and running.
- cwkoss 5y ago
  The factorio dev team are such fantastic software engineers, I wonder if this was an emergent feature of building what they want or if there was actually intentionality in making this a common takeaway from playing the game. If you haven't, read their blog! It's a master class in release notes and development communication.
shane_b 5y ago
In software dev, my team has a “naive, naive, refactor” rule for this problem
- rustyminnow 5y ago
  Could you elaborate on this rule?
  - shane_b 5y ago
    I wrote about this https://shaneburkhart.com/i/naive-naive-refactor https://shaneburkhart.com/i/naive-naive-refactor
  - gknoy 5y ago
    My guess is, it has to do with how you handle 1, 2, N. The first time we write something, we write it just for that specific case --- no point overengineering if you don't know you'll need it. (Hence the "YAGNI" advice that is common.) Now, there are two things that code has to handle. You could put in a simple bit of special-case logic, or a case statement, and move on, OR you could instead spend time, codes, and tests making it robust to handle many different types of input, with a type-specific config system that makes it easy to add new type-specific behavior. Our predilection on many teams is to skip the middle part, and write robust automation the first time we hit a special exception. ("This used to be about ordering burgers but now we want to also order shakes, and they don't have a cook-time.") It seems like the OP was suggesting that we do a "crappy" good-enough solution to that intermediate phase of complexity, as there's a chance you might not need more than that.
    - shane_b 5y ago
      Exactly, great explanation
  - mceachen 5y ago
    It may be a reference to https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra... The idea is that you grit your teeth and let code be deduplicated twice (but no more), rather than immediately DRYing up code, so you'll (hopefully) have a better sense of what the common code should look like. (I personally think it's too hard in practice, as common code can be written sufficiently differently to not be recognizable as common by the Engineers Of Tomorrow).
  - shane_b 5y ago
    The first time you implement, the default is to over abstract. The second time even more. By the third, you have a good enough idea of what you need to then build something robust. Each phase is faster. Second iteration is almost always copy and paste of first with small tweaks. I’d rather that than some kind of conditional. The best UI almost never fits the most convenient technical solution so we optimize for UI and then technical.
FeistyOtter 5y ago
In what situations did this mantra help? I am the same as your friend, I have like 100 hours and I have never reached the endgame, always unsatisfied with my factory.
- leetcrew 5y ago
  as you unlock more technologies, it becomes increasingly easy to refactor/maintain a large factory. ex: bots are a major inflection point in the game. you could scale up petroleum processing and red circuits before getting bots (you need these two things to make them), but that involves a lot of manual effort. it's usually better to do a barely sufficient (but tileable!) petroleum and rc setup, then immediately fix it after making a few construction bots. more general tip: clean interfaces are more important than massive capacity up front. in the long run, you will always need more steel/circuits/etc than you can serve with a single production line. but even if the internal layout is a mess, a functional unit with a clean interface can be scaled horizontally forever.
  - dragontamer 5y ago
    Cleanliness doesn't really matter, because space is infinite. ----------- So long as you've unlocked enough military (ie: shotgun in the early game, or tank in the mid-game), you can just clear out more room and then build there. (Shotgun has significant pierce-damage, enough to kill the alien bases. Tank also has significant pierce damage and impact-damage, allowing you to win against small / medium aliens through the midgame rather easily and cheaply) Don't even "tear down" your oldbase. Just fully abandon it and move elsewhere. Even without bots, there's no penalty to "just leaving". --------- Bots / deconstruction planner is more of a thing if you're tired of cleaning out biter-territory and want to "recycle" your old areas.
    - storyinmemo 5y ago
      Hi, it's me your local site reliability engineer. I care about things like latency, monitoring, and being able to understand the overall moving pieces. Scaling things in appropriate ratios is also relevant to me. I'd put you in a storage box and nuke if I could, but let's go have this conversation standing on these train tracks.
deleted 5y ago
[deleted]
tstrimple 5y ago
For me "beating" those type of games isn't the point. I've got nearly 1,500 hours on Rimworld and I've never beaten the game. It's more interesting to me to create different scenarios and see where they go and what stories come from them than to try to optimize for racing to the end.
- hobomatic 5y ago
  Yeah an earlier poster mentioned something about there being no black box problems and that all the information to do anything is already out there to read. I think this is only true if you are looking to beat the game in a prescribed way. There is a massive amount of space for experimentation and defining your own resource restrictions and goal state.
fennecfoxen 5y ago
> great is the enemy of good enough One-man Factorio is a lot different than big-team Factorio. As a single factory-developer, you need to be startup-like and remember that your time in the present is the most valuable resource. So always automate everything the first time, because you WILL need more of that component. But do it in a quick and dirty and unscalable manner so you can move on to something else. Start with box-fed production lines; when you're sick and tired of refilling the boxes, it's time to re-do it better. Build a system to support this throwaway development, where you can tear things down later and replace them and it keeps working. Start with a narrow bus, not eight lanes each for iron and copper — but keep it open for expansion downstream. When you run out of space near the start of the bus, don't just move things a few tiles to squeeze in an incremental upgrade: build a much bigger production line further downstream. You'll have more and better components to do it right. And always, always, always, keep your interconnects separate from your production components. You don't need a single straight-line bus like some people think, right angles and parallels and grids are fine, but if your belts are snaking through something else, it's real hard to tear down that something-else, and it's real hard to scale up. Encapsulation is important. And when you're finally scaling up like crazy, ready for the big leagues, use a high-throughput component someone else developed and have your robots install it.
chrisfosterelli 5y ago
I mean, some people just prefer to play the game more leisurely. It's not a speed run or a business deliverable. I have around 80 hours on my factory so far and it's pretty clear to me I could have "finished" by now with a lot more corner cutting but I'm enjoying the process of exploring each tech tree discovery in depth and scaling things out "right". This takes longer, but it's fun and I feel better about the end result, and isn't that the point? Also -- playing the game over again gives a colossal speed benefit. Probably half of my time spent on this game has been ripping up everything I did that I realize clearly won't work nicely once I reach the next tech tree item. Knowing what the end game looks like in advance saves a lot of time. I think I partly like this game because it reminds me of programming before programming was work. Trying to get through everything as fast as possible sounds like the antithesis of that, but maybe that's just me.
- m463 5y ago
  I got to the point where I could copy-paste walls with lasers around an area and then develop inside it at my leisure. Then the game was no-worries building therapy.
  - DerArzt 5y ago
    No worries until the next bitter wave comes, and oh my god there are 20 behemoths and holly crap this drawing a lot of power, wait why am I experiencing a brown out? Oh no.....my coal mines are electric powered on the same grid as the turrets and the buffer is low......They made it through the wall.....They are destroying the base including the coal mines......Time to start over!
    - sudosysgen 5y ago
      Always good to keep a few coal powered inserters, hehe
    - fennecfoxen 5y ago
      This is why you have a separate defense grid, and a capacitor farm to serve defense demand, and when the capacitors run low you have a logic network to read the value of `A` (accumulator fill %) and turn off everything that isn't critical (mining, etc). (Of course, you'll need this switch at any satellite installation too.) You may need to shift-click some electric poles to disconnect them from other poles, and use copper wire to connect them exactly how you want. Add a lowkey alarm buzzer (the speaker) to let you know this is going on. Try to have a second, louder one that detects whether it's failed and the factory is still on because of a short circuit. Conduct tests by wiring in a constant combinator outputting a fixed value of A (possibly negative).
godshatter 5y ago
A good example of this in Satisfactory (haven't played Factorio) is balancers vs. manifolds. The idea is that you have factory components that need to feed other factory components at a certain speed to get to 100% efficiency. One way to do that is to place the correct number of splitters and mergers to get the right ratios based on the output rate of the various components and the input rate of the others (the balancer way). The other way (the manifold way) is to just hook up one factory component that needs to feed another and let it run until it has filled up it's buffer. Then add a splitter to take the overflow and repeat until you are at 100%. Do this for all inputs. A complicated balancer looks like a drawing of a Christmas tree made of balancers and mergers and takes up a lot of space. A manifold is just a line of constructors or whatever with splitters in front of them going from one output to one input. You can put up a manifold without doing any math and just stop adding factory components when it can't feed the next building. You can sink hours into just designing the perfect balancer for your situation, let alone building it. I always go the manifold way.

skipants 5y ago

That's been my takeaway from these games, too. It really helped with my perfectionism because it makes the negative effects of it tangible; you notice how much more time you lose by trying to be perfect rather than just getting your supply of materials up and running.

cwkoss 5y ago
The factorio dev team are such fantastic software engineers, I wonder if this was an emergent feature of building what they want or if there was actually intentionality in making this a common takeaway from playing the game. If you haven't, read their blog! It's a master class in release notes and development communication.

shane_b 5y ago

In software dev, my team has a “naive, naive, refactor” rule for this problem

rustyminnow 5y ago
Could you elaborate on this rule?
- shane_b 5y ago
  I wrote about this https://shaneburkhart.com/i/naive-naive-refactor https://shaneburkhart.com/i/naive-naive-refactor
- gknoy 5y ago
  My guess is, it has to do with how you handle 1, 2, N. The first time we write something, we write it just for that specific case --- no point overengineering if you don't know you'll need it. (Hence the "YAGNI" advice that is common.) Now, there are two things that code has to handle. You could put in a simple bit of special-case logic, or a case statement, and move on, OR you could instead spend time, codes, and tests making it robust to handle many different types of input, with a type-specific config system that makes it easy to add new type-specific behavior. Our predilection on many teams is to skip the middle part, and write robust automation the first time we hit a special exception. ("This used to be about ordering burgers but now we want to also order shakes, and they don't have a cook-time.") It seems like the OP was suggesting that we do a "crappy" good-enough solution to that intermediate phase of complexity, as there's a chance you might not need more than that.
  - shane_b 5y ago
    Exactly, great explanation
- mceachen 5y ago
  It may be a reference to https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra... The idea is that you grit your teeth and let code be deduplicated twice (but no more), rather than immediately DRYing up code, so you'll (hopefully) have a better sense of what the common code should look like. (I personally think it's too hard in practice, as common code can be written sufficiently differently to not be recognizable as common by the Engineers Of Tomorrow).
- shane_b 5y ago
  The first time you implement, the default is to over abstract. The second time even more. By the third, you have a good enough idea of what you need to then build something robust. Each phase is faster. Second iteration is almost always copy and paste of first with small tweaks. I’d rather that than some kind of conditional. The best UI almost never fits the most convenient technical solution so we optimize for UI and then technical.

FeistyOtter 5y ago

In what situations did this mantra help? I am the same as your friend, I have like 100 hours and I have never reached the endgame, always unsatisfied with my factory.

leetcrew 5y ago
as you unlock more technologies, it becomes increasingly easy to refactor/maintain a large factory. ex: bots are a major inflection point in the game. you could scale up petroleum processing and red circuits before getting bots (you need these two things to make them), but that involves a lot of manual effort. it's usually better to do a barely sufficient (but tileable!) petroleum and rc setup, then immediately fix it after making a few construction bots. more general tip: clean interfaces are more important than massive capacity up front. in the long run, you will always need more steel/circuits/etc than you can serve with a single production line. but even if the internal layout is a mess, a functional unit with a clean interface can be scaled horizontally forever.
- dragontamer 5y ago
  Cleanliness doesn't really matter, because space is infinite. ----------- So long as you've unlocked enough military (ie: shotgun in the early game, or tank in the mid-game), you can just clear out more room and then build there. (Shotgun has significant pierce-damage, enough to kill the alien bases. Tank also has significant pierce damage and impact-damage, allowing you to win against small / medium aliens through the midgame rather easily and cheaply) Don't even "tear down" your oldbase. Just fully abandon it and move elsewhere. Even without bots, there's no penalty to "just leaving". --------- Bots / deconstruction planner is more of a thing if you're tired of cleaning out biter-territory and want to "recycle" your old areas.
  - storyinmemo 5y ago
    Hi, it's me your local site reliability engineer. I care about things like latency, monitoring, and being able to understand the overall moving pieces. Scaling things in appropriate ratios is also relevant to me. I'd put you in a storage box and nuke if I could, but let's go have this conversation standing on these train tracks.

deleted 5y ago

[deleted]

tstrimple 5y ago

For me "beating" those type of games isn't the point. I've got nearly 1,500 hours on Rimworld and I've never beaten the game. It's more interesting to me to create different scenarios and see where they go and what stories come from them than to try to optimize for racing to the end.

hobomatic 5y ago
Yeah an earlier poster mentioned something about there being no black box problems and that all the information to do anything is already out there to read. I think this is only true if you are looking to beat the game in a prescribed way. There is a massive amount of space for experimentation and defining your own resource restrictions and goal state.

fennecfoxen 5y ago

> great is the enemy of good enough One-man Factorio is a lot different than big-team Factorio. As a single factory-developer, you need to be startup-like and remember that your time in the present is the most valuable resource. So always automate everything the first time, because you WILL need more of that component. But do it in a quick and dirty and unscalable manner so you can move on to something else. Start with box-fed production lines; when you're sick and tired of refilling the boxes, it's time to re-do it better. Build a system to support this throwaway development, where you can tear things down later and replace them and it keeps working. Start with a narrow bus, not eight lanes each for iron and copper — but keep it open for expansion downstream. When you run out of space near the start of the bus, don't just move things a few tiles to squeeze in an incremental upgrade: build a much bigger production line further downstream. You'll have more and better components to do it right. And always, always, always, keep your interconnects separate from your production components. You don't need a single straight-line bus like some people think, right angles and parallels and grids are fine, but if your belts are snaking through something else, it's real hard to tear down that something-else, and it's real hard to scale up. Encapsulation is important. And when you're finally scaling up like crazy, ready for the big leagues, use a high-throughput component someone else developed and have your robots install it.

chrisfosterelli 5y ago

I mean, some people just prefer to play the game more leisurely. It's not a speed run or a business deliverable. I have around 80 hours on my factory so far and it's pretty clear to me I could have "finished" by now with a lot more corner cutting but I'm enjoying the process of exploring each tech tree discovery in depth and scaling things out "right". This takes longer, but it's fun and I feel better about the end result, and isn't that the point? Also -- playing the game over again gives a colossal speed benefit. Probably half of my time spent on this game has been ripping up everything I did that I realize clearly won't work nicely once I reach the next tech tree item. Knowing what the end game looks like in advance saves a lot of time. I think I partly like this game because it reminds me of programming before programming was work. Trying to get through everything as fast as possible sounds like the antithesis of that, but maybe that's just me.

m463 5y ago
I got to the point where I could copy-paste walls with lasers around an area and then develop inside it at my leisure. Then the game was no-worries building therapy.
- DerArzt 5y ago
  No worries until the next bitter wave comes, and oh my god there are 20 behemoths and holly crap this drawing a lot of power, wait why am I experiencing a brown out? Oh no.....my coal mines are electric powered on the same grid as the turrets and the buffer is low......They made it through the wall.....They are destroying the base including the coal mines......Time to start over!
  - sudosysgen 5y ago
    Always good to keep a few coal powered inserters, hehe
  - fennecfoxen 5y ago
    This is why you have a separate defense grid, and a capacitor farm to serve defense demand, and when the capacitors run low you have a logic network to read the value of `A` (accumulator fill %) and turn off everything that isn't critical (mining, etc). (Of course, you'll need this switch at any satellite installation too.) You may need to shift-click some electric poles to disconnect them from other poles, and use copper wire to connect them exactly how you want. Add a lowkey alarm buzzer (the speaker) to let you know this is going on. Try to have a second, louder one that detects whether it's failed and the factory is still on because of a short circuit. Conduct tests by wiring in a constant combinator outputting a fixed value of A (possibly negative).

godshatter 5y ago

A good example of this in Satisfactory (haven't played Factorio) is balancers vs. manifolds. The idea is that you have factory components that need to feed other factory components at a certain speed to get to 100% efficiency. One way to do that is to place the correct number of splitters and mergers to get the right ratios based on the output rate of the various components and the input rate of the others (the balancer way). The other way (the manifold way) is to just hook up one factory component that needs to feed another and let it run until it has filled up it's buffer. Then add a splitter to take the overflow and repeat until you are at 100%. Do this for all inputs. A complicated balancer looks like a drawing of a Christmas tree made of balancers and mergers and takes up a lot of space. A manifold is just a line of constructors or whatever with splitters in front of them going from one output to one input. You can put up a manifold without doing any math and just stop adding factory components when it can't feed the next building. You can sink hours into just designing the perfect balancer for your situation, let alone building it. I always go the manifold way.