A.I. Learns to Optimize Factorio Blueprints

Added: 2026-05-21

[00:00:00]Building a blueprint is easy, but building an optimized blueprint, now that's complicated. Take a look at this wonderful little blueprint I've built that makes green circuits. You may notice that it has a bit of character.

[00:00:12]But it has the same production as this blueprint, which is much more streamlined. Designing more efficient and organized blueprints take some skill and quite a bit of thought. But let's be honest, doing anything manually in a game about automation feels wrong. So, let's channel the true Factorio spirit and find a way to automate efficient blueprint design.

[00:00:31]To automate the design process, we can leverage a form of machine learning known as a genetic algorithm. A genetic algorithm is a search and optimization technique that mimics the process of natural selection, where the fittest individuals are selected to reproduce and pass on their traits to the next generation. Using this idea, we can generate an initial population of blueprints and evaluate their performance using a fitness function.

[00:00:54]From there, we will select the top-performing designs to serve as the basis for the next generation. We will create designs for the next generation by selecting from the top performers, combining their trades with one another, and potentially introducing random mutations. We can continue this process until we are satisfied with the results.

[00:01:11]Let's take a look at how we can implement this process in Factorio. I've created a script that will set up a little test site for each blueprint in our generation. The size and number of these test sites can be changed according to our optimization parameters. Our blueprints will also need input and output interfaces. So, I've added an infinite chest and loader on the left side for each of the inputs, as well as a bottomless chest and loader on the right side for each output. These are also fully configurable based on what kind of blueprint we want to optimize.

[00:01:40]Now that we have our evaluation infrastructure, we just need a way to generate blueprints to create the members of our population. If you watch my last video, you may already know how we will approach this. If you haven't seen it, then you should definitely check it out. I go into more depth behind the concept I'm about to cover here.

[00:01:56]The easiest way we can generate a blueprint of a given size is to pick a random entity and a random direction for each cell.

[00:02:03]This will work perfectly for entities that occupy a single cell. But when they are larger, we run into a slight issue.

[00:02:08]Larger entities cannot be placed if they overlap with existing entities. While technically it is possible for larger entities to be placed if all overlapping cells have nothing in them, it is statistically improbable. The simplest solution I found is to place larger entities before smaller ones. This allows larger entities to be placed, but it does mean some smaller ones will be blocked.

[00:02:30]To integrate this into the genetic algorithm, we also need to establish clear mechanics for reproduction and mutation. For reproduction, two designs with high fitness are chosen from the current population to generate an offspring for the next generation.

[00:02:44]To create this new design, we can iterate through each cell and select the entity and its orientation from either the first or the second parent. This crossover technique ensures that the new design inherits a functional mix of traits from both parents. To prevent the algorithm from getting stuck in a local optimum, we can slightly mutate the design immediately after reproduction.

[00:03:04]We can do this by iterating through each cell and applying a small percentage chance to trigger a random change.

[00:03:10]When a mutation occurs, we will either change the entity type or its placement direction to a new random value.

[00:03:16]One thing to keep in mind about using a genetic algorithm is that you don't necessarily need to be clever about how you generate traits for each individual, but you do need to be clever about how you evaluate their fitness.

[00:03:27]The reason for this is because the algorithm will do the hard work of exploring possibilities and the fitness function will help direct the search towards the desired result. So how can we effectively evaluate our random blueprints? You might think we can let the blueprint process for some time and check how much of our desired product is placed in the output chest. While this is the ideal scenario, it's far from reality when generating completely random blueprints. Let's take a look at a few designs to help us create a better fitness function.

[00:03:54]We'll start with a simple iron gear blueprint where iron plate is the only input and iron gears are the desired output. To reduce the search space, we will only allow the following entities: assembly machine, inserter, and transport belt.

[00:04:09]As you can see, none of these will produce any iron gears in the output chest.

[00:04:13]So, we need to get clever with our fitness function.

[00:04:16]What are some of the qualities of these factories that resemble something productive?

[00:04:21]Well, for starters, designs with an assembly machine are much more likely to produce something than ones without any.

[00:04:27]Same for ones that have inserters, but we can also give them a boost if they are picking up or dropping off to a transport belt or assembly machine.

[00:04:35]Additionally, we can give higher value to any assembly machine or belt with an iron gear in its inventory.

[00:04:41]While not perfect, these simple qualities will help our fitness function select designs that have a higher potential for production.

[00:04:48]All right, let's see some optimal iron gear blueprints.

[00:05:00]Well, I feel like we're getting somewhere, but it didn't quite achieve the perfectly optimal blueprint I had in mind.

[00:05:06]I let this run for a total of 464 generations at 1,024 blueprints per generation.

[00:05:13]It seems as though we've hit a local minimum in the optimization process.

[00:05:18]As you can see, it eventually got an assembly machine producing iron gears, but didn't get any into the output chest.

[00:05:24]Subsequent generations over selected this suboptimal design and wasn't able to find anything better.

[00:05:30]It was eventually able to manage getting some iron gears into the output chest.

[00:05:34]However, it did not improve the design much after that. It seems as though we need a better way to generate blueprints that actually produce something. But before we get into more complicated generation techniques, let's take a moment to relax with another project I've been working on, Leaf Blower Simulator. This is a cozy online co-op game where you blow leaves around to clean up the environment. It's currently in early access on Steam with lots of new features and content coming in the future updates. There's a free demo available right now if you want to try it out with some friends. I'll leave a link in the description and if you enjoy it, please consider wish listing. It really goes a long way.

[00:06:09]Also, feel free to leave some feedback.

[00:06:11]I'm looking to improve the game in every way I can.

[00:06:14]Also, if you're enjoying the video so far, consider subscribing. I have many more videos planned that you won't want to miss.

[00:06:21]Now, let's get back to optimizing some blueprints.

[00:06:25]So, we need to find a way to cut out the useless noise in our blueprints.

[00:06:29]Ideally, we would be able to generate designs that have no wasted entities or flaws. Then, we would be able to optimize solely on the amount of production and the cost to build. Well, we are in luck. There's an algorithm that can do all of this called wave function collapse.

[00:06:44]Wave function collapse is a procedural generation algorithm that can create complex patterns based on a predefined rule set and set of constraints.

[00:06:53]The algorithm is best illustrated by a simple example. Say we have a map that is defined by a grid and we want to fill it with either land, coast, or sea tiles.

[00:07:03]We can define rules for each of the tiles based on their adjacency to each other.

[00:07:07]For land, we will say it can be adjacent to land on all sides, coast only on the left, right, and bottom, and not adjacent to sea at all.

[00:07:16]Coast can be adjacent to land or sea on the left and right sides, only land above, and only sea below.

[00:07:23]And sea has a similar rule set to land, but effectively the opposite.

[00:07:27]This is all we need to run the wave function collapse algorithm to generate our map.

[00:07:32]We begin with every cell in the map being in a superposition of every type of tile.

[00:07:37]Then, we select the cell with the lowest entropy, which is a measure of uncertainty.

[00:07:42]So, we will select the cell with the fewest tile options. In this case, they all have the same entropy, so we can pick a random cell and collapse it.

[00:07:50]Meaning to select a tile from its possibilities. Let's choose coast for this cell. Once we collapse a cell, we need to update the surrounding cells according to our rule set. We know only a land tile can exist above a coast tile. And same for below with a sea tile.

[00:08:07]For the sides, coast tiles cannot be next to another coast tile. So, we can remove that possibility from each. This will propagate out for any cells that have their possibilities changed and will continue until there's no more changes.

[00:08:20]We've just finished the first collapse and now we will continue selecting the lowest entropy cell and collapsing until the entire map is complete. We can apply this same idea to Factorio since it is heavily reliant on adjacency rules.

[00:08:34]Let's start first with belts since they are the most useful entity for moving items around. In the simplest case, we want belts to connect to each other in a straight line. So, we can define an east belt tile with the rules that an east belt can be placed to the left and to the right. Let's also add an empty tile, which means nothing will be placed in that cell. And we'll say that can go above and below the belt.

[00:08:58]By creating a blueprint grid with these tiles as possibilities, we can collapse into numerous straight belts.

[00:09:04]Now things get a little more difficult.

[00:09:06]Turning the belt is not as simple as just defining an up and down belt that can be placed to the right of our east belt. Doing so would create some slop in the belt network since those belts can be connected from other directions.

[00:09:18]We need to explicitly define each way that a belt can turn.

[00:09:22]To turn upwards, we need to define a belt whose input is on the left and output above. We also need a belt that can accept items from below and output to the right. Similarly, we can define tiles for turning the belt downward.

[00:09:36]Once we populate their adjacency rules to keep the belts connected, we can run the wave function collapse algorithm to see a more interesting belt network.

[00:09:45]This is the basis of our belt network, and if we expand our tile definitions to include all four directions, we can [clears throat] get results that look like this.

[00:09:53]When defining these rules, it's important to keep in mind that the wave function collapse algorithm does not know anything about Factorio or what we're trying to accomplish. It's only following the rules we give it. So, yes, these generations are correct according to our rules. We just need to be more specific.

[00:10:09]What's not specific enough about what we've defined so far?

[00:10:12]Well, for starters, there's no clear goal with what we're generating. There's no purpose for the belt to exist at all.

[00:10:19]So, let's add back in the input and output interfaces from the iron gear blueprint.

[00:10:24]Now, we have a more well-defined purpose.

[00:10:26]Ideally, we want the input belt to start at the input interface, and we want the output belt to end at the output interface. Where the input belt stops and where the output belt begins does not matter, so we can add this into our rules.

[00:10:39]We can first add a resource type to each belt tile to know what they carry. Using this, we can identify if a belt tile is an input belt or an output belt.

[00:10:49]Now, we can add a step to our wave function collapse algorithm.

[00:10:52]When collapsing a cell, we can check if the selected tile has any additional constraints and apply them to adjacent cells.

[00:10:59]We can create an input belt constraint that will ensure the input side of the belt is connected to another input belt.

[00:11:05]Similarly, we can create an output belt constraint to ensure the output side of that belt is connected to another output belt.

[00:11:13]Using these additional constraints, our generations now look like this.

[00:11:16]I'm glossing over a few other constraints I added to make it look this pretty, including one to prevent side loading as well as full loops.

[00:11:24]But now, if we set the input and output to the same item, we've just made a very inefficient way to find the shortest path between two points.

[00:11:42]Now let's try to add some production.

[00:11:44]You may have been thinking, how can an assembler, which occupies a 3x3 space, be represented by a single tile?

[00:11:51]Well, it's as simple as slicing the assembler up into single-cell pieces and defining special rules that will only allow for the pieces to be connected to one another.

[00:12:00]When one piece of it is collapsed, the algorithm will propagate out eliminating any tiles other than the ones that create the assembler.

[00:12:08]And finally, we get to inserters.

[00:12:10]They can technically be placed next to any other entity, but since we want optimal results, we can define constraints to make sure they are useful.

[00:12:18]We first will create an inserter tile for each item that can be moved around.

[00:12:22]Their allowed rules will be populated with every other tile that satisfies its pickup and drop-off constraints.

[00:12:29]A pickup constraint says inserters must be able to pick up the item they move.

[00:12:33]So, the adjacent cell should provide that item. For instance, a transport belt carrying that item or the output of an assembly machine. Similarly, a drop-off constraint says inserters must be able to drop off any item they pick up. So, the adjacent cell should accept that item. For instance, a transport belt or the input of an assembly machine.

[00:12:52]So, when we collapse a cell into an inserter, we must prune the invalid possibilities.

[00:12:58]Now, what we've defined so far is still not enough to guarantee a productive blueprint. While we've outlined the rules for production, there's no guarantee an assembly machine or inserter will be placed. Oftentimes, applying the rules and constraints will back itself into a corner until the only thing left to pick is an empty tile.

[00:13:16]Thankfully, we can apply even more constraints.

[00:13:19]We can apply another form of constraint that happens on a global level instead of just for adjacent cells. These global constraints will be applied after every cell collapse to ensure our blueprint will be productive. I've applied global constraints to guarantee there's at least one assembly machine and that there are inserters to input each ingredient for the recipe as well as an inserter to remove the output. Finally, we have productive blueprints and we can simplify our fitness function to minimize the cost and maximize production in the output chest.

[00:13:48]Before we can run our genetic algorithm to optimize our blueprints, we need to redefine what it means to reproduce and mutate. Each individual is not defined by cells of entities and directions anymore. They are defined by cells of tile possibilities.

[00:14:02]One thing to note is that I've changed the collapse procedure to always pick the first remaining tile in a cell's possibilities to make the algorithm more deterministic. By altering the order of each cell's tile possibilities, we can reintroduce randomness that will give us something to pass on to the next generation. So, in reproducing, we will iterate through the grid and select the tile possibility ordering from one of the parents. And for mutations, we can have a small chance to reorder a particular cell's tile possibility list.

[00:14:31]Now, let's see the optimization progress for an iron gear blueprint.

[00:14:39]You can see the wave function collapse algorithm introduces a lot of variation amongst similar individuals. This is to be expected since changing what tile is selected for a single cell can have rippling effects further away. While it wasn't able to perfectly optimize the blueprint, I'm still impressed it was able to fit two working assembly machines in such a small space.

[00:14:59]Let's try something a bit more complicated. Green circuits with the inputs of iron plate and copper cable.

[00:15:12]Well, this one is taking much longer to compute than the last ones. Let's see what's going on here.

[00:15:18]Here are some of the statistics of each of the blueprints we've tried so far.

[00:15:22]I've even added the more typical green circuit blueprint with inputs of iron plate and copper plate. As the blueprint gets more complex, there are more tiles and it takes longer on average to generate. The wave function collapse algorithm is already not computationally efficient and we've also introduced many constraints which slows down computation even more.

[00:15:42]Constraints increase the potential of backtracking and overall failure to generate.

[00:15:47]All of these delays make for very slow generation evaluation which leads to much less coverage of the search space in a reasonable amount of time.

[00:15:55]Overall, I think this project has been a success. We were able to generate various working blueprints and this can be expanded to work with all entities and eventually all different production lines.

[00:16:05]I would like to look more into speeding up the algorithm, potentially using a compute cluster. So, let me know in the comments if you have any ideas or if you'd like to see more on this topic.

[00:16:15]A lot of time and effort goes into creating videos like these and since you're still here, I'll give you a little sneak peek at some of my next projects. My goal is to work towards creating a fully autonomous bot to play Factorio and beat the game.

[00:16:27]If that sounds interesting to you, then consider subscribing because those videos will be out soon.

[00:16:33]Thank you so much for watching.