I wrote this a while back… I still think it’s true (though I don’t think its “finished”)

---

Factorio

So there’s this game I play… just a little bit. Factorio.

In playing this game, I’ve realized that there are several parts of the game play that are directly applicable to software design. The idea of Patterns becomes more clear on how to explain them and how to use them in regular software when one can point to something a bit more concrete (all be it a construct in a virtual world). A visual example of reasonable design and problems of scale are also software design issues that become more apparent with factorio.

Patterns

Patterns are a favorite rant of mine - that developers are asking for a pattern to do something and you take a Something and a SomethingElse and link them together and you’ve got a working application.

Factorio gives me a better way to explain what a Pattern is.

One of the problems that I’ve had in factorio is a pump that flickers on and off rather quickly. This made a mess of the power display (a very high frequency sine wave was evident - determining the actual overall power consumption over time became more challenging) and lights that were hooked up to it to indicate that the pump was on were flickering at a high frequency (a rather annoying strobe).

The cause was that the pump (and light) were connected to a tank containing refined oil. The pump was to pump off excess when it got to 24,000 units. If the tank was at 24,100 units the pump would pump off 200 units putting it at 23,900 and shutting off. One sixtieth of a second later, something would push another 200 units of refined oil into the tank and the pump would trigger on and off for a sixtieth of a second - the flickering and the high frequency showing up in the power.

The solution to this is to use what is known as a Schmitt trigger. This is a circuit that feeds back to itself with a positive feedback loop. When the trigger turns on at a given threshold it will remain on until the value drops below a different threshold. The way that the trigger was set up was so that when the material reached 24,000 units, it would turn the pump on until the level was at 22,000 units.

The way this was implemented was to use a decider combinator which takes a signal as input (the amount of material in the tank) and sends a signal as output (the value 1 in a given channel) based on some logic (the amount of material in the tank is greater than 24,000). Then a second combinator - an arithmetic combinator - would take that signal of 1 and then multiply it by 2,000 and send that result into the input of the decider combinator. The result would be that the signal is now 26,000 and it would run until the material drops to 24,000 in which case the signal from the decider would switch from 1 to 0 and the arithmetic combinator would stop sending the additional 2000 units as a signal… and we would see the real value of the tank at 22,000.

The Schmitt trigger is a Pattern.

It is silly to be suggesting that one would design something based on the answers to “what are useful Patterns when creating an oil processing area?” One doesn’t add something unless its necessary to solve a problem. And one doesn’t go looking for places to use a Schmitt trigger or other Pattern - they are tools for solving specific problems.

Reasonable design

The first base that a person builds is often what is known as a spaghetti base. The layout is ad-hoc. As you need something from somewhere (some iron plates) to get to somewhere else you split off from a convenient, nearby belt with some iron on it and run it over to the place it is needed. It sounds ok at first, but doing this a few dozen times the layout becomes more and more convoluted.

Enter the main bus.

The main bus is a design where there is a large number of belts running down the center of the base and things tap off of it perpendicular for specific factories that build a given item.

The taps off are well researched designs that have a specific fraction of the items shunted off to the factory. Instead of trying to figure out where the iron came from and how to get more iron down to that place maybe a few hundred tiles away, one can look at the main bus and see a dozen tiles and understand what that sub factory is making and how many resources it needs.

The reasonable design allows one to more quickly fix issues of resource starvation and allocation along with refactoring of specific areas of the overall system without worry about impact to things downstream. The base is reasonable.

Problems of scale

After playing a bit and winning the game a time or two, one gets the urge to build BIG. Not these little “launch a rocket every couple of minutes” but rather “launch a rocket every second.”

The design for the one rocket every few minutes is fundamentally different than the design for one rocket every second. The layout of the base for a simple mainline works well - but it doesn’t have the throughput for materials that would enable the launch a rocket every second goal.

For this, one starts building outpost factories that do one thing, and one thing well. This outpost takes iron ore and produces iron plates. That outpost takes iron plates and copper plates and produces green circuits. So on and so forth.

This is a very different design - switching from a main bus to train logistics (trains become the way to move massive amounts of material). The very structure of the base for a megabase vs a regular base shows differences at every level.

Many times one reads about developers having difficulties with microservices and trying to build something to scale to 1000 users per second. And then comes the moment when they are asked how many users per second they’re currently getting and the answer is something along the lines of “Um, we’re getting maybe 5 a second on a good day… but we’re getting ready for being Amazon or Twitter scale.”

Design for what works. It is often easier to redesign a working system up than it is to try to start out with the megabase or amazon scale system and fight all those little problems of outpost base train networks and microservices that you haven’t encountered before in a working system.