![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jackOh gosh, I knew this was going to be addictive for me and it was. You're crashed on an alien planet and need to build enough smelting, industry, power etc to eventually launch a rocket. But most of the game is about the layout of stuff, about getting a million conveyor belts getting the right components to the right machines without bumping into each other, and about layout out pipes between lakes, oil refineries, factories etc without getting into a giant knot.
I knew it would be but it's *really* *really* like software engineering. Like, you can *see* exactly what spaghetti code is: when you lay things out neatly and can see where everything is, it's easy to change things, but when you grow your conveyor belt layout organically, you can add *one* line fairly easily just fitting it in here and there, but if you do that often, everything ends up an unchangeable mess and you can't do anything with it without breaking half the existing stuff.
Somewhere in the middle you get useful tools like grabbers which can be programmed in unlimited ways, so you can turn things on only when you need the outputs, and even construction bots which can duplicate large sections of your factory.
Introspection and perfectionism
And you realise things. My instincts are always to build exactly the right amount of intermediates that the outputs need. But that doesn't actually work most of the time. Intermediates you always need for a specific product, and don't need LOTS of, it's often sensible to build a "manufacture the intermediates and final product" block with the assemblers all next to each other. Intermediates you need all over the place it's usually sensible to just manufacture lots of. But then you need to say -- you don't want to process ALL your iron into cogs, or you'll run out of iron for everything else. But you do need a *lot* of cogs. Is it better to just make cogs, and rely on that when you have "enough" cogs and the conveyor belt backs up, the cog machines stop taking iron? But then if you build too many further machines that need cogs, they'll never be satiated and everything that needs iron will start shutting down. Is it better to split the incoming iron 50/50 or some other proportion between iron and the basic iron intermediates like cogs and steel? But then what if that ratio's not correct. Or is it better to adjust depending on which important final products are running short?
My instinct is that there should be a perfect "right" way. But because you need to add new final products and change proportions and cope with raw fuels temporarily running dry, that's basically impossible, it's better to segregate the various stages, and turn on the earlier stages as needed (I haven't actually done that yet but I can see the benefit).
Specific parallels
And likewise, duplicating a section of your factory once you have the right construction bots, and once you manufacture enough of all the buildings etc needed, is just a push of a button and a short wait. But it takes ages to make all the edges line up right so the new conveyors get the right input etc.
Or, a thought occurred to me driving to work, you know construction sites always seem to be "nothing, nothing, nothing, suddenly a building"? Well, software development often *is* like that, and I know exactly why even though I don't like believing it: because there's an awful lot of work in getting things working together, so the actual working on things is comparatively scattered. (And you can either frontload it, and then have years of technical debt and trying to bodge things together, or build everything right but it's ages before you get things working. And wisdom is knowing the right balance :) )
It also gives insight into firefighting vs planning. You need a certain amount of "fixing up" things, at some point ore runs low and you need to lay out dozens of smelters and stuff on a new ore field, there's no way of avoiding that. And often, *something* will back up, or run out, or get mixed between two belts or something, for completely deterministic reasons that you *could* have forseen, and you need to take care of it. But if you spend *all* your time doing that you'll never make any progress. And conversely, sometimes it's easier to take a shortcut, like loading an assembler with the appropriate inputs manually, if you expect it to be a while before you run out -- but even if you do, it's useful to think through where you would put the proper conveyor belt feeds, e.g. by having an inserter that grabs from a chest, but you can replace with a belt when you need. That, "do the simple thing, but leave the connectors in place for replacing it with a polished version when you need" is often a very useful approach.
Aesthetics
It's pretty atmospheric. The background sounds vary according to what's on the screen, so you can *hear* radars blipping and furnaces roaring. I played on peaceful because I didn't want the pressure of fighting off alien wildlife at the same time, but those are pretty beautiful in a monstrous way. And when things are humming along perfectly it's really impressive. It reminds me, how much I love making complicated elegant mechanisms, and I need to do more programming where I design a thing as well as learn a new thing.
I knew it would be but it's *really* *really* like software engineering. Like, you can *see* exactly what spaghetti code is: when you lay things out neatly and can see where everything is, it's easy to change things, but when you grow your conveyor belt layout organically, you can add *one* line fairly easily just fitting it in here and there, but if you do that often, everything ends up an unchangeable mess and you can't do anything with it without breaking half the existing stuff.
Somewhere in the middle you get useful tools like grabbers which can be programmed in unlimited ways, so you can turn things on only when you need the outputs, and even construction bots which can duplicate large sections of your factory.
Introspection and perfectionism
And you realise things. My instincts are always to build exactly the right amount of intermediates that the outputs need. But that doesn't actually work most of the time. Intermediates you always need for a specific product, and don't need LOTS of, it's often sensible to build a "manufacture the intermediates and final product" block with the assemblers all next to each other. Intermediates you need all over the place it's usually sensible to just manufacture lots of. But then you need to say -- you don't want to process ALL your iron into cogs, or you'll run out of iron for everything else. But you do need a *lot* of cogs. Is it better to just make cogs, and rely on that when you have "enough" cogs and the conveyor belt backs up, the cog machines stop taking iron? But then if you build too many further machines that need cogs, they'll never be satiated and everything that needs iron will start shutting down. Is it better to split the incoming iron 50/50 or some other proportion between iron and the basic iron intermediates like cogs and steel? But then what if that ratio's not correct. Or is it better to adjust depending on which important final products are running short?
My instinct is that there should be a perfect "right" way. But because you need to add new final products and change proportions and cope with raw fuels temporarily running dry, that's basically impossible, it's better to segregate the various stages, and turn on the earlier stages as needed (I haven't actually done that yet but I can see the benefit).
Specific parallels
And likewise, duplicating a section of your factory once you have the right construction bots, and once you manufacture enough of all the buildings etc needed, is just a push of a button and a short wait. But it takes ages to make all the edges line up right so the new conveyors get the right input etc.
Or, a thought occurred to me driving to work, you know construction sites always seem to be "nothing, nothing, nothing, suddenly a building"? Well, software development often *is* like that, and I know exactly why even though I don't like believing it: because there's an awful lot of work in getting things working together, so the actual working on things is comparatively scattered. (And you can either frontload it, and then have years of technical debt and trying to bodge things together, or build everything right but it's ages before you get things working. And wisdom is knowing the right balance :) )
It also gives insight into firefighting vs planning. You need a certain amount of "fixing up" things, at some point ore runs low and you need to lay out dozens of smelters and stuff on a new ore field, there's no way of avoiding that. And often, *something* will back up, or run out, or get mixed between two belts or something, for completely deterministic reasons that you *could* have forseen, and you need to take care of it. But if you spend *all* your time doing that you'll never make any progress. And conversely, sometimes it's easier to take a shortcut, like loading an assembler with the appropriate inputs manually, if you expect it to be a while before you run out -- but even if you do, it's useful to think through where you would put the proper conveyor belt feeds, e.g. by having an inserter that grabs from a chest, but you can replace with a belt when you need. That, "do the simple thing, but leave the connectors in place for replacing it with a polished version when you need" is often a very useful approach.
Aesthetics
It's pretty atmospheric. The background sounds vary according to what's on the screen, so you can *hear* radars blipping and furnaces roaring. I played on peaceful because I didn't want the pressure of fighting off alien wildlife at the same time, but those are pretty beautiful in a monstrous way. And when things are humming along perfectly it's really impressive. It reminds me, how much I love making complicated elegant mechanisms, and I need to do more programming where I design a thing as well as learn a new thing.
no subject
Date: 2018-04-10 01:17 pm (UTC)One meta-strategy for tasks like the one you describe is to build in redundancy: if everything is spaced a little wider than needed you can, if necessary, fit things in between. Think Basic line numbering: if you start out with '1, 2, 3' you're toast very quickly. If you use 10, 20, 30 you have wriggle room.
But this is also why test-driven development - 'write the minimum code to pass the current spec' makes no sense to me: once you have hyper-optimised for one set of conditions, the next step will either be cobbled together badly or you'll need to tear it down and start again. Better to build a certain amount of flexibility into the system.
no subject
Date: 2018-04-10 04:23 pm (UTC)Yeah, redundancy is a good description.
this is also why test-driven development... makes no sense to me
I think there's an implicit assumption that you write each stage "right", being as extensible as you need, even if theoretically you don't need to to pass the tests. It works like that for the (unfortunately not prevalent enough) times when I write tests even if I'm not doing TDD per se. But I don't really see that spelled out, and I don't know if it's something you can only do when you already have enough experience.
(Similarly, my impression of agile is that it's great for writing code, but skips over a lot of necessary planning for all but the smallest projects. But that that's ok, it's still good to do, but you do need to plan to do the planning!)
no subject
Date: 2018-04-13 02:51 pm (UTC)It also gives more of an incentive to look into solar / accumulator arrays (and the associated circuit network magic to run down accumulators during the day rather than start burning coal immediately)... and it's good for trains, because you can get to a mining outpost under attack much more quickly. Also, a lot of the power armour chain doesn't really serve any purpose otherwise; and you have little reason to develop nukes if you don't need both the extra power and DU ammo.
[1] joke, you never have a vast overproduction of green circuits.