Factorio is a game about building and creating automated factories to produce items of increasing complexity, within an infinite 2D world. Use your imagination to design your factory, combine simple elements into ingenious structures, and finally protect it from the creatures who don't really like you.
Recent Reviews:
Overwhelmingly Positive (467) - 96% of the 467 user reviews in the last 30 days are positive.
All Reviews:
Overwhelmingly Positive (29,763) - 98% of the 29,763 user reviews for this game are positive.
Release Date:
Feb 25, 2016

Sign in to add this item to your wishlist, follow it, or mark it as not interested

Early Access Game

Get instant access and start playing; get involved with this game as it develops.

Note: This Early Access game is not complete and may or may not change further. If you are not excited to play this game in its current state, then you should wait to see if the game progresses further in development. Learn more

What the developers have to say:

Why Early Access?

“We have been working on Factorio for over 5 years. The game is very stable and is highly optimised for prolonged gameplay and creating huge factories. We have sold over 110,000 copies on our website, and we feel now is the right time to release to a wider audience.”

Approximately how long will this game be in Early Access?

“Our plans for release come as part of an ongoing process, and we are constantly adding new features and content. When we feel the game is complete we will release the full version, and our current estimate is that this will take 8-12 months.”

How is the full version planned to differ from the Early Access version?

“In the full version we hope to have a polished GUI, a multiplayer matching server, integration of mods for players and servers, and a number of other finishing touches and additions to the core gameplay.”

What is the current state of the Early Access version?

“The game has a very strong content base, rich with interesting mechanics and features. Many players report they are still having fun on their maps even after hundreds of hours of gameplay, alongside multiplayer support, and a dedicated modding community.”

Will the game be priced differently during and after Early Access?

“No, the price now is the final price.”

How are you planning on involving the Community in your development process?

“The community is a vital part of our development process. We announce any planned features far in advance so we have time to read peoples' opinions and comments, and for us to discuss the different points of view players may have. Community suggested ideas are commonly brought up in team discussions, and we value highly the input each individual player can have.”
Read more

Buy Factorio

Downloadable Content For This Game


Recent updates View all (279)

September 14

Friday Facts #260 - New fluid system

Hi Factorians,
This is Dominik, and my first FFF post ever! I will use this opportunity to talk to you about the exciting subject of pipes. Yeah, I know, right?

Spring came and with it Twinsen, saying "Pipes suck. Two people already tried to fix it and failed, who wants to be next?", and I’m like "Hey, that’s just pipes, you just make a simple simulation, simple AF. I’m in."
The conditions were even quite lenient:
  • Fluids get where they should.
  • They should act in a predictable manner, with reasonable splitting/joining in junctions.
  • Fluids can travel instantly, if need be.
  • Respect the pipe throughput limitations.
  • Flow can be viewed on the pipes.
  • Don’t do f**** up stuff like running in a circle indefinitely, sloshing back and forth endlessly etc.
  • Should be faster/more UPS efficient.
I am mostly working on the new GUIs, but still, the fact that summer is over and pipes are not done, kinda shows how simple fixing them is. Very naive I was.

Problems with the current system
There are couple mishaps in the current pipe system. Good thing is that they work - the fluids do get from A to B, in most cases anyway. It follows a simple elevation model, fluidboxes will try to equalise with their neighbours, which is quite fast to evaluate and solves the simple cases, but it does not address much outside of running through a straight pipe.

(Green column represents volume, Blue represents flow)

The first of three main issues is that in junctions it behaves in a very random fashion. As a result, you might get recipients that are not getting any fluid where they obviously should be.

The second issue players voice is the limited behavior of the elevation functions. Only a fraction of the fluid is moved to its neighbour, so you rarely have a tank that is entirely full or entirely empty, which is a problem when you try to mix that with the integer based circuit network.

The third issue is performance. Even though the formulas are simple, they are calculated for every connection in every fluidbox, which adds up. As a result, nuclear power is unfeasible for megabases. There are other problems too, such as throughput loss over distance, fluids moving faster or slower depending on the entity update order, etc.

(Fluid flows much quicker in the bottom pipe)

My simulator
The game is not at all practical for testing and debugging pipes, so I built a simple command line pipe simulator to develop the new system in. As I was attacking what I thought to be a simple problem, I started simple, and then had to refactor it several times whenever I realized that the problem is harder than what my simulator can support. I will shortly describe how it works, before going to the model itself.

The pipe layouts are loaded from a text file such as “5 1 \n s p p d 0”, which is 2 dimensions of the system, followed by a 2d layout, in this case just one row source-pipe-pipe-drain-empty. The simulator loads the layout, connects pipes and then updates the system tick by tick on request. I get a very rough overview, as picture below, but most of the time I have to inspect the running code to see what is going on under the hood.

Though now with the new map editor and the ability to step through single ticks, it will be much easier to test in-game too.

Possible solutions
Before going to the current, simulation based model, I will shortly discuss other approaches that we have rejected.

Optimizing the current system
This is something Harkonnen tried a long time ago, to reduce indirection in the update of the fluidboxes. Essentially, instead of each entity updating their own fluidbox, all fluidboxes in a segment would be kept in a singular part of memory, and then the simulation could be updated much faster. Initial experiments showed a performance increase of 30-50% updating all fluidboxes. However this would not address any of the other issues, and would add a significant amount of complexity to the currently quite simple handling of the fluidboxes, which we decided isn't worth the price.

Flow model
Since we are doing flow here, flow algorithms look like a candidate. The most naive Ford–Fulkerson method, although theoretically infinite, could work super fast in our case. Problem is that it only finds the maximum flow - the top limit of what we can push through. We could then divide this max fluid flow between the consumers and kinda get a working results. But the behaviour on the way would be ridiculous with full flow through one pipe and 0 through next, 0 to dead ends etc. In other words, the junction behavior would be entirely broken. Better balanced flow algorithms exist but these also don’t do exactly what we need and the complexity quickly jumps to astronomical realms.

Electric network model
Another proposal was modelling like an electric network. Fluid flow is a popular analogy to their workings, and they do have a lot in common. The great thing about them is that they precisely model the flow branching and it could work out of the box. What it does not allow though is to limit the flow - one wire can, theoretically, run any current, but not so for the pipes, and we don’t want one pipe to be enough to supply whole factory. The limitations could be added, but that would, again, kill it with complexity.

A simplified version of this is what we consider the 'nuclear option'. In short, fluid network and pipes would work like the current electric network, instant transmission from production to consumption. This would increase performance by orders of magnitude, and remove the unintuitive flow of the current system, all consumers would get an equal split of the production, and storage tanks would act like accumulators.

However we have decided not to pursue this, for a few reasons.
  • There would be no visualisation or indication of the flow of fluid.
  • There would be unlimited throughput, one water pipe could supply all boiler and reactor setups.
  • It abstracts away part of the realism and charm of the game. (While this is subjective at best, it does mean something to us.)

Merging fluidboxes
This would mean merging all the similar pipes in a segment into only a single fluidbox that needs updating. This would solve the performance issues, and the throughput loss over distance, however on its own, it would not solve the issues with update order, unintuitive flow direction/splitting etc.

When it comes to the basic physics model, I ended up with something that is not at all realistic, but works well in practice. At the beginning, I tried to do almost realistic physics - as a proof of concept, with momentums and all that. But quickly I became cluttered with complicated formulas and it did not work at all. The system is so heavily discrete that physics are not really applicable.

In Factorio, a full content of a ~meter long pipe moves into the next pipe in one tick and instead of mixing single molecules in a junction all in real time (infinitely little steps) we have to mix/split huge blocks in one shot. It’s more like moving Lego blocks than running fluids. For a long time I was playing with pressure but I dropped even that in favour of just two variables - volume and speed, where the speed kinda models the pressure as well. Volume is the amount of fluid in the segment, speed affects how much of it wants to move on in a tick - as speed x volume. Just this is enough to provide a pretty decent simulation.

Junction model
Most difficulties come from modelling the junctions. The general problem is that when anything does not behave entirely correctly, there exists a situation where it creates a total breakdown, such as no flow into some pipe.

There are colliding forces in play. We can only evaluate one pipe connection (one inlet/outlet) at a time, but the behavior needs to be symmetrical and fair towards pipes that are to be evaluated later (currently it is not). What is the right order of evaluation and how to make it symmetrical without super complex look-ahead?
Well, another big consideration is accuracy vs. complexity.

Over many iterations I kept developing models, followed by counterexamples that killed them.

My model and improvements
The evaluation model I have arrived to works with two passes through the pipes in one tick. The formulas are more complex than the current one so it should be slower, but there will be one improvement to counterbalance it. The rough algorithm in one tick is as follows (I omit many necessary but boring details):
  • (Done at the end of previous step) Every pipe states how much fluid it intends to send to neighbours (called flow reservation) using a simple heuristic.
  • Perform topological sorting by direction of reservations from 0.
  • Evaluate pipes in the opposite direction, i.e. from end to start, against the expected flow.
  • Update a pipe in two stages:
    • Move fluid in it to neighbours proportionally to the space in them, space allocation they gave to the current pipe (providing they were already evaluated), and previous tick flow.
    • Allocate the resulting free space to neighbours that are yet to be evaluated to ensure they get fair share of it.
  • Go through the pipes again and do clean-up and calculate reservations for the next tick.
So in this algorithm, we go from the last pipe, always moving fluid and making space for the next one. The reservations/allocations system ensures good behavior in the junctions. Essentially at every junction, the fluid will try to be split evenly between all the possible connections, which makes things very intuitive.

It works nicely, but unfortunately this system is even more computationally demanding. Here comes in the key improvement which is taking every straight pipe (every segment that has max two connections) and connect it into one piece. No matter how long it is, it will be evaluated in one calculation. Naturally, this loses some realism, but it is insignificant as it is the junctions that matter and those will remain unaffected. So as long as you don’t do crazy stuff like making pipe grids and keep your pipes straight, they will have zero effect on UPS.

To put it more simply, updates will only be run on junctions and segments. At each junction, fluid will be split evenly among the neighbouring segments and junctions, any excess from one neighbour will spill evenly to the others. A segment is just a section of pipe without any splits, and fluid will transfer instantly through segments, but with a limited throughput.

So in the setup above, we would go from updating 32 individual pipes with the 'old' system, to updating 3 junctions (blue) and 8 segments. Since a segment can be any length, overall we expect a big performance increase. It could also lead to more UPS efficient designs, trying to minimize the number of splits in your pipe network, we know some players really enjoy trying to optimize for different metrics.

A last convenience improvement are some rounding mechanisms to fill or move away those 0.0001 fluids, draining the last drops from the pipe system if the sources are disconnected, and filling all the way up if production is greater than consumption. Another point left to consider is how to solve accidentally connecting pipes and tainting your whole oil system with water.

Current state and next steps
All this is nice and already working, but still in the stage of the simulator.
What I still need to do to get it to 0.17:
  • Figure out good model for storage tanks, and how they fit in.
  • Perhaps refactor it from floats to integers, which would make it work more cleanly, but would also make some calculations more complicated. TBD.
  • Finish the algorithm for correctly drawing the flow direction in the connected straight pipes (not that simple).
  • Move it all into the game code.
  • Write tests for it (I am probably overreacting but I feel that this will take as long as all the work up to this point).
So to sum up, we have had this on our minds for a long time now, and performance was not the only issue we have considered. The new system will hopefully address all the issues we mentioned at the start.

As always, let us know what you think on our forum.

Actually, speaking of the forum, you might notice that it underwent some changes this week. Sanqui has updated our forum from phpBB version 3.0 to 3.2, which is a bigger jump than it sounds. It brings us more in line modern web features, the forums are now usable on phones, it heightens security, and paves the way for future extensions. Some style changes are final, but if you have any particular gripes, please say so and we will try to accommodate everybody.
55 comments Read more

September 7

Friday Facts #259 - Scan-codes, Prototype IDs, HR worm

Scan-codes vs Key-codes
While migrating from Allegro to SDL, HanziQ and Jiri replaced the keystroke handling from using key-codes to scan-codes. Before you start jumping with joy, you’ll probably wonder: What is that and why should I care?

Well, funny you should ask. You probably won’t care, unless you live outside of USA and/or you use a non-US keyboard layout. In short, key-code is a key identifier dependant on the symbol the key will output when pressed, scan-code is a key identifier based on the physical location of a key. So for example players with French keyboard layout (AZERTY) have to jump to the control options after launching the game for the first time, and remap movement from WASD to ZQSD, in order to be able to move their character without hurting their hand.

In 0.17, the controls will map to the correct keys by default, regardless of your layout, and stay mapped to those physical keys even if you for some reason change your keyboard layout while the game is running. The disadvantage is, most of the non-US layouts didn’t end up with completely broken controls, so people kept playing with them and got used to them. So they’ll need to get used to the layout the game was originally designed with, or manually configure controls back to what they are used to.

But wait, there is a catch...

A few weeks ago we have announced new construction tools, which are by default bound to quite universal shortcuts (Ctrl+C for copy, Ctrl+X for cut and Ctrl+Z for undo). Bilka pointed out that the German keyboard has Z swapped with Y (as does the Czech one, but developers often don't use it) and undo incorrectly defaults to Ctrl+Y instead. To fix these kind of shortcuts we determine the appropriate default scan-codes at start-up, so that undo is always Ctrl+Z, regardless of your layout, but the action will stay bound to those keys if you change keyboard layout at runtime, which is hopefully a reasonable compromise.

We might do it for other controls too (it feels natural for M to always be the default key to open the map, and T to open the technology screen), but there is another catch. It is completely reasonable for player to walk north, and Ctrl+click some entities. Remember AZERTY keyboard? Player keeps Z pressed down to walk north and presses Ctrl to start control clicking. Well, I tested this and it doesn’t trigger undo, but still stops player from walking. So it is not completely destructive, rather annoying. I am not sure how or if we’ll solve this, perhaps people with these layouts that create these kind of collisions will need resolve them by changing controls options manually.

Stable prototype IDs
The new Map Editor is finished, with one of the last things completed being importing surfaces from other save files. Importing surfaces from one save into another turned out to be quite complex, but not for the reasons you might think. The copying of a surface to a new surface is relatively easy, the main problem came from how we store map data in a save file.

Factorio internally makes lists of every entity, item, decorative and so on at startup and generates a mapping of the text name to an integer ID. This is internally called an ID mapping, and provides several benefits both runtime and when it comes to saving/loading the game. The main benefit being: we (and modders) don't need to track and manually assign ids to everything added to the game - the engine does it all automatically. Anyone familiar with modded Minecraft before version 1.7 can attest to how much of a pain manually handling IDs can be and how easily it can break.

Because things can be added and removed due to our internal changes or by adding/removing/changing mods, the ID mapping often changes. Because it can change we have to include it in the save file to know what it was when the save was created. When Factorio saves the map one of the first things that's written to the save file is that ID mapping.

The way it worked before was: at load time - the game would attempt to restore whatever the ID mapping was for the save it's loading. Anything it can't find means that thing doesn't exist any more, and anything new is stuff added. This lead to saves having different ID mappings for the same set of mods depending on the steps taken to make that save file. This worked for the most part but had a few small problems:
  • Any time something was removed it was signalled by setting the ID at that location in the mapping to 0.
  • The removed IDs couldn't be re-used until the save was fully loaded, saved, and loaded again (leading to gaps in the IDs).
  • Different save files could end up using different IDs even when using the same set of mods.

With the new Map Editor wanting to take any save file and import it into your running game the fact that the ID mapping could be different was a problem. To add to the complexity we also have a migration system in place that lets you tell the game "I want to change all entities/items/... named *A* into *B*". This migration system also works when you remove the source otherwise it wouldn't be that useful.

After several false starts (a common theme when it comes to these complex reworkings), I came up with the following simple requirements:
  • IDs will get assigned once after loading mods - after that they are never allowed to change for the lifetime of the program
  • When a map is loaded instead of restoring the ID mapping it was using it will create a migration from the old ID to the new ID (if it still exists)
  • The tracking of what was removed is done through a different system instead of treating a '0' ID as a removed ID.

During this rework I discovered we were doing a bunch of extra work (some of it even causing bugs) just to restore the save file ID mapping, and I was able to simply delete all of it now that the IDs simply migrate to the correct values any time a save file is loaded. I even inadvertently fixed a bug someone reported related to crashing when loading a specific scenario-using save file due to this rework.

Overall the system is simpler now and doesn't have any of the 'quirks' it used to. The new Map Editor can import any save file the game is capable of loading and it all 'just works'.

HR worms
As you might know already from an earlier post, we are working with Ernestas on the high-res version of the enemies. This is a great excuse for also refining the concept of them. This week we want to show the new look of the worms.

The intention is to keep what we had in the previous version, but to emphasize its personality and behaviour. This new version tries to be more aggressive, powerful and disgusting, while also acting more nervous and agitated. The "fingers" on its head are for digging tunnels, something that wasn't really explained before, and which will also help to express the character of the worm.

Now we are working on the animations, trying to emphasize these concepts, basically the worm is a creature of pure hate and killer instinct. Together with the sound effects, I hope it is going to be a pleasure killing them.

As always, let us know what you think on our forum.
34 comments Read more
See all discussions

Report bugs and leave feedback for this game on the discussion boards

About This Game

Factorio is a game in which you build and maintain factories. You will be mining resources, researching technologies, building infrastructure, automating production and fighting enemies. In the beginning you will find yourself chopping trees, mining ores and crafting mechanical arms and transport belts by hand, but in short time you can become an industrial powerhouse, with huge solar fields, oil refining and cracking, manufacture and deployment of construction and logistic robots, all for your resource needs. However this heavy exploitation of the planet's resources does not sit nicely with the locals, so you will have to be prepared to defend yourself and your machine empire.

Join forces with other players in cooperative Multiplayer, create huge factories, collaborate and delegate tasks between you and your friends. Add mods to increase your enjoyment, from small tweak and helper mods to complete game overhauls, Factorio's ground-up Modding support has allowed content creators from around the world to design interesting and innovative features. While the core gameplay is in the form of the freeplay scenario, there are a range of interesting challenges in the form of Scenarios. If you don't find any maps or scenarios you enjoy, you can create your own with the in-game Map Editor, place down entities, enemies, and terrain in any way you like, and even add your own custom script to make for interesting gameplay.

Discount Disclaimer: We don't have any plans to take part in a sale or to reduce the price for the foreseeable future.

What people say about Factorio

  • No other game in the history of gaming handles the logistics side of management simulator so perfectly. - Reddit
  • I see conveyor belts when I close my eyes. I may have been binging Factorio lately. - Notch, Mojang
  • Factorio is a super duper awesome game where we use conveyor belts to shoot aliens. - Zisteau, Youtube

System Requirements

Mac OS X
SteamOS + Linux
    • OS: Windows 10, 8, 7, Vista (64 Bit)
    • Processor: Dual core 3Ghz+
    • Memory: 4 GB RAM
    • Graphics: 512MB Video Memory
    • Storage: 1 GB available space
    • Additional Notes: Low sprite resolution and Low VRAM usage.
    • OS: Windows 10, 8, 7 (64 Bit)
    • Processor: Quad core 3Ghz+
    • Memory: 8 GB RAM
    • Graphics: 2GB Video memory
    • Storage: 1 GB available space
    • OS: macOS High Sierra, Sierra, OSX El Capitan, Yosemite, Mavericks
    • Processor: Dual core 3Ghz+
    • Memory: 4 GB RAM
    • Graphics: 512MB Video Memory
    • Storage: 1 GB available space
    • Additional Notes: Low sprite resolution and Low VRAM usage
    • OS: macOS High Sierra, Sierra, OSX El Capitan, Yosemite, Mavericks
    • Processor: Quad core 3GHz+
    • Memory: 8 GB RAM
    • Graphics: 2GB Video memory
    • Storage: 1 GB available space
    • OS: Linux (tarball installation)
    • Processor: Dual core 3Ghz+
    • Memory: 4 GB RAM
    • Graphics: 512MB Video Memory
    • Storage: 1 GB available space
    • Additional Notes: Low sprite resolution and Low VRAM usage
    • OS: Linux (tarball installation)
    • Processor: Quad core 3GHz+
    • Memory: 8 GB RAM
    • Graphics: 2GB Video memory
    • Storage: 1 GB available space

What Curators Say

458 Curators have reviewed this product. Click here to see them.
Customer reviews
High Volume of Reviews Detected:
Exclude  or  View Only
Review Type

Purchase Type


Date Range
To view reviews within a date range, please click and drag a selection on a graph above or click on a specific bar.

Show graph

Display As:
Review Beta NEW!
When enabled, will sort reviews by new Helpfulness score. Read more about it in the blog post.
Show graph
Hide graph
Review Helpfulness Beta Enabled
There are no more reviews that match the filters set above
Adjust the filters above to see other reviews
Loading reviews...