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 (496) - 95% of the 496 user reviews in the last 30 days are positive.
All Reviews:
Overwhelmingly Positive (30,209) - 98% of the 30,209 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 (283)

October 12

Friday Facts #264 - Texture streaming

Hello, it is me, posila, with another technical article. Sorry.

Bitmap Cache
In 0.16, we added graphics option mysteriously called "Low VRAM mode", it enables a basic implementation of texture streaming, but I didn't want to call it that way, because I feared its poor performance would give texture streaming a bad name. How it worked? Every sprite has specified some priority, and the "Video memory usage" option - despite its name - controls which priorities of sprites are included in the sprite atlases. What happens to sprites that don't go to atlas? They are loaded as individual sprites. Normally, these sprites are allocated into texture objects. The reasoning behind this is that graphics driver has chance to decide how it wants to layout these small textures in memory, instead of it being forced to work with huge atlases.

What part of a sprite atlas looks like.

When you enable "Low VRAM mode", non-atlas sprites are loaded only to RAM, and texture is allocated for them only when used during rendering. We called class that handled this BitmapCache and there was maximum limit of how many mega-bytes of texture data the bitmap cache could use at once. When this limit was reached, it failed to convert memory bitmap to video texture, and Allegro's drawing system would fallback to software rendering, which absolutely tanked FPS, but this didn't happen... most of the time.

So apart from the obvious problem of falling back to software renderer (which we don't have any more after the graphics rewrite, so the game would crash or skip a sprite if this happened), there are other performance issues. Most sprites have a unique size, so we can't reuse textures for different sprites. Instead, when a sprite needs to be converted to a texture, a new texture is allocated, and when the sprite is evicted from the cache, its texture is destroyed. Creating and destroying textures considerably slows down rendering. The way we do it also fragments memory, so all of the sudden it may fail allocate new texture because there is no large enough consecutive block of memory left. Also, since our sprites are not in an atlas, sprite batching doesn't work and we get another performance hit from issuing thousands of draw calls instead of just hundreds.

I considered it to be an experiment, and actually was kind of surprised that its performance was not as bad as I expected. Sure, it might cause FPS drop to single digits for a moment from time to time, but overall the game was playable (I have a long history of console gaming, so my standards as player might not be very high :)).

Can we make it good enough, so it wouldn't be an experimental option any more, but something that could be enabled by default? Let's see. The problem is texture allocations, so let's allocate one texture for the entire bitmap cache - it would be a sprite atlas that we would dynamically update. That would also improve sprite batching, but when I started to think how to implement it, I quickly ran into a problem dealing with the fragmentation of space. I considered doing "defragmentation" from time to time, but it started to seem like an overwhelming problem, with a very uncertain result.

Virtual texture mapping
As I mentioned in FFF-251, it is very important for our rendering performance to batch sprite draw commands. If multiple consecutive draw commands use the same texture, we can batch them into a single draw call. That's why we build large sprite atlases. Virtual texture mapping - a texture streaming technique popularized by id Software as Mega Textures, seems like a perfect fit for us. All sprites are put into a single virtual atlas, the size of which is not restricted by hardware limits. You still have to be able to store the atlas somewhere, but it doesn't have to be a consecutive chunk of memory. The idea behind it is the same as in virtual memory - memory allocations assign a virtual address that maps to some physical location that can change under the hood (RAM, page file, etc.), sprites are assigned virtual texture coordinates that are mapped to some physical location.

The virtual atlas is divided into tiles or pages (in our case 128x128 pixels), and when rendering we will figure out which tiles are needed, and upload them to a physical texture of much smaller dimensions than the virtual one. In the pixel shader, we then transform virtual texture coordinates to physical ones. To do that, we need an indirection table that says where to find the tiles from the virtual texture in the physical one. It is quite a challenge for 3D engines to figure out which virtual texture pages are needed, but since we go through the game state to determine which sprites should be rendered, we already have this information readily available.

That solves the problem of frequent allocations - we have one texture and just update it. Also, since all the sprites share the same texture coordinate space, we can batch draw calls that use them. Great!

However we could still run out of space in the physical texture. This is more likely if player zooms out a lot, as lot more different sprites can be visible at once. Well, if you zoom out, sprites are scaled down, and we don't need to render sprites in their full resolution. To exploit this, the virtual atlas has a couple levels of details (mipmaps), which are the same texture scaled down to 0.5 size, 0.25 size, etc. and we can stream-in only the mipmap levels that are needed for the current zoom level. We can use lower mipmap levels also if you are zoomed in and there are just too many sprites on the screen. We can also utilize the lower details to limit how much time is spent for streaming per frame to prevent stalls in rendering when a big update is required.

The Virtual atlas technique is big improvement over the old "Low VRAM mode" option, but it is still not good enough. In the ideal case, I would like it to work so well, we could remove low and very-low sprite quality options, and everyone would be able to play the game on normal. What prevents that from happening is that the entire virtual atlas needs to be in RAM. Streaming from HDD has very high latency, and we are not sure yet if it will be feasible for us to do without introducing bad sprite pop-ins, etc.

If you'd like to learn how virtual texture mapping works in more detail, you can read the paper Advanced Virtual Texture Topics, or possibly even more in-depth Software Virtual Textures.

GPU rendering performance
The main motivation behind texture streaming, is to make sure the game is able to run with limited resources, without having to reduce visual quality too much. According to the Steam hardware survey, almost 60% of our players (who have dedicated GPU), have at least 4GB of VRAM and this number grows as people upgrade their computers:

We have received quite a lot of bug reports about rendering performance issues from people with decent GPUs, especially since we started adding high-resolution sprites. Our assumption was that the problems were caused by the game wanting to use more video memory than available (the game is not the only application that wants to use video memory) and the graphics driver has to spend a lot of time to optimize accesses to the textures.

During the graphics rewrite, we learned a lot about how contemporary GPUs work (and are still learning), and we were able to utilize the new APIs to measure how much time rendering takes on a GPU.

To simply draw a 1920x1080 image to a render target of the same size, it takes:
  • ~0.1ms on GeForce GTX 1060.
  • ~0.15 ms on Radeon Vega 64.
  • ~0.2ms on GeForce GTX 750Ti or Radeon R7 360.
  • ~0.75ms on GeForce GT 330M.
  • ~1ms on Intel HD Graphics 5500.
  • ~2ms on Radeon HD 6450.
This seems to scale linearly with the number of pixels written, so it would take ~0.4ms for the GTX 1060 to render the same thing in 4K.

That's pretty fast, but our sprites have a lot of semi-transparent pixels. We also utilize transparency in other ways - from drawing ghosts and applying color masks, to drawing visualizations like logistic area or turret ranges. This results in large amount of overdraw - pixels being written to multiple times. We knew overdraw was something to avoid, but we didn't have any good data on how much it happens in Factorio, until we added the Overdraw visualisation:

The game scene being rendered.

Overdraw visualisation (cyan = 1 draw, green = 2, red >= 10).

Overdraw visualisation when we discard transparent pixels.

Interestingly, discarding completely transparent pixels didn't seem to make any performance difference on modern GPUs, including the Intel HD. Drawing sprites with a lot of completely transparent pixels is faster than an opaque sprite without having to explicitly discard transparent pixels with shaders. However, it did make difference on Radeon HD 6450 and GeForce GT 330M, so perhaps modern GPUs throw away pixels that wouldn't have any effect on the result automatically?

Anyway, a GTX 1060 renders a game scene like this in 1080p in 1ms. That's fast, but it means in 4K it would take 4ms, 10ms on integrated GPUs, and more that a single frame worth of time (16.66ms) on old, non-gaming GPUs. No wonder, scenes heavy on smoke or trees can tank FPS, especially in 4K. Maybe we should do something about that...

As always, let us know what you think on our forum.
19 comments Read more

October 5

Friday Facts #263 - Trains in blueprints

Trains in blueprints
Building trains again and again might be a daunting task. Especially when you start making a lot of mining outposts, artillery/supply trains with filtered cargo wagon slots etc.

So I decided that we should extend blueprints to work with trains as well. The first condition was, that trains are only selected when you explicitly allow it in the checkbox, so they don't get in your way when building rail setups.

Checking the button allows the train that was there to be put into the blueprint (similar to the way tiles work). For the sake of simplicity, we decided that once there is any rail in the blueprint, the train in it will be always buildable (as a ghost obviously), even if there are not rails to support the train at the moment. The train ghost will simply stay there and won't be buildable until rails are placed under it in a way so it can be placed.


If I remove the rails from the blueprint, I get a second type of rail blueprint. In this case, all the parts of need to have rails to support it, this is mainly needed as without rails, there is no rail grid forced, so we should make sure, the train ghost won't be created in some wrong position.


The small touch here is, that the blueprint also contains the schedule. With little-bit of improvisation, I can optimize the mine building a lot in the late game. I create a blueprint of mine train station. The stop will be called Mine X.

Both of the trains in the blueprint will have the Mine X -> Smelting schedule setup. Once I build the blueprint, I just rename the Mine X to whatever I want (Mine 12 for example), and the train schedules are updated as well, so I'm almost ready to go.


The last tweak I'm considering is to allow blueprints to contain the fuel insertion info similar to how they contain the module insertion info for assembling machines now.

Upgrade planner tweaks
When we showed it, the upgrade planner was Prototype ready, but playtesting uncovered various kind of missing tweaks, and as always the real usability is in the details. Especially since the mod already solves most of these issues, we have to at least be as good as the mod.

The first problem was, with underground belts. With the naive approach of just upgrading entities that are selected, it happened quite a lot, that I upgraded some belt area, but I didn't notice, that some of the underground belts have only one side marked for upgrade, so the belts get disconnected when the upgrade is executed:

This was be usually discovered half an hour later when I was investigating the reason of some part of factory not producing. When it happened few times in a row, it was quite annoying... So the fix was, to make sure that the upgrade planner always upgrades connected underground belts in pairs if possible:

Part of the tweak is, that the robot upgrades both part of the underground belt as one action, so the items that are "flowing" underground don't have to be touched.

The next thing we wanted was to not only upgrade entities, but their also contents, so you can now specify module upgrades in the upgrade planner as well. (Please note, that the upgrade planner/blueprint UI is a work in progress, and this particular screen was not yet addressed by our GUI polishing process).

Another feature is to be able to upgrade blueprints with the upgrade planner. The upgrade planner mod could do it as well, but we will be able to integrate it better with our GUI better.

You can immediately see, that another tweak might be to also upgrade the blueprint icons as well.

My thanks goes to galibert, who created the original pull request of this feature (giving source access to stranger sometimes helps us) and Rseding91, who fixed the technical problems and added the tweaks mentioned earlier.

Finalizing features and latency state (technical)
It has been quite a long time since we described our latency hiding system in FFF-83. Since then, we have had to make a tough choice whether to incorporate a new interaction feature into the latency hiding or not as we developed it. With undo, it was kind of implied, that it needs to be incorporated in the latency state system, since you need accurate instant feedback of what you undo-ed, especially when you are undoing few things in a row, and you don't want to do more steps by accident because of the multiplayer delay. Since there are more and more things in the latency state, and they need to interact with each other in a reasonable way, the amount of possible cases starts to grow, so we have to make sure that the corner cases are covered by tests more than in other areas.

Let me present you a quite simple case of what you see compared to what is happening in latency state under the hood, this is a simple thing:


Furnace built

Marked for deconstruction


But when you play in multiplayer, it might easily happen, that after the last undo step, not even the first command to build the actual furnace is in the game yet as the multiplayer latency might be too big. But as the local simulated state must act as it all was done instantly, it needs to solve different kind of situations

What you see (latency state) / Actual game state
Start / Start

Fake furnace created / Nothing yet

Fake furnace fake marked for deconstruction / Nothing yet

Fake furnaces fake mark for deconstruction fake undone / Nothing yet

Now real furnace fake marked for deconstruction / Furnace built in game state

Real furnaces fake mark for deconstruction undone / Furnace marked for deconstruction in game state

What you see is what you get / Furnaces mark for deconstruction undone in game state

Doing all of these kind of cases right might make a big difference between Prototype ready and Release ready. With the undo feature itself, I added 42 different tests and I'm not completely finished.

As always, let us know what you think on our forum.
21 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

467 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...