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 (734) - 96% of the 734 user reviews in the last 30 days are positive.
All Reviews:
Overwhelmingly Positive (28,809) - 98% of the 28,809 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 (271)

July 20

Friday Facts #252 - Sound design & Map editor

New sound design
Val: Do you remember the smell of the fresh air near the seashore? Can you describe, a forest that rumbles its trees after a summer rain? All that you hear and see goes right into your mind. All of our senses are connected with each other in our memories. When we feel at least one of them, our imagination brings the others. Sometimes, and even often, we can't see the object, but we can hear it! You can't see the wind, but you feel it and hear it! The bird is singing. You can't see it hiding in a bush, but you hear a beautiful song and can define the direction it comes from.

The forest, the sea, the desert... Night and day. Clanking of a loading cannon and snoring of unseen monsters. That is what we are planning to do. To put the unseen colors of sound and add some feeling of life to the planet of Factorio. Even the emptiness has it's own voice...

Albert: As you probably know, we are in a stage of polishing all the possible aspects of the game.

Last week we were cooperating with Val, our new sound designer, and we spent the entire week defining new concepts for environmental sounds and sound effects. Also we were working on the sound of the biter nests and the artillery cannon. This is definitely a huge subject full of details that can really improve the play experience of Factorio. Here I can show you a work in progress of the artillery cannon:


We have to tweak some behaviour of the entity in order to make it act more mechanical, but overall, the possibilities that sound design can bring to the game are really interesting. Compare the simple shooting of the cannon in the actual version with this proof of concept with all those details in rotation and loading. Of course this level of detail complicates the work a little bit, but I'm convinced it's worth it.

Spawners redesign in HR
We are also working in parallel with Ernestas, who is improving the look of the enemies. Right now we can show a sneak peek of how the new spawners look in HR. Together with TOGoS, we are working in a more specific map generation in order to improve the composition of the nests. The intention is to generate a special ambience for those areas that makes you feel like you are in enemy territory.

Everything here is a work in progress, let us see how we end up with all those plans. Soon I'd like to show how the nests look with the animations, the ambience, and all the biters and worms around.

Nobody uses the Map editor
Factorio has had a Map Editor since the early stages of development. It was initially used to create the current campaigns and scenarios, and from time to time we would use it to help diagnose desyncs. However, as development continued the Map Editor seemed to have been forgotten.

Inside the Factorio engine, almost every game GUI/action is associated with the player that is looking at the GUI and doing the action. This makes sense because when the game is running everything is done by a specific player, and GUIs need to know stuff about that player. When actions are processed the game applies them to a specific player in the world, and handles stuff like multiplayer syncing of actions done by different players. In the Map Editor there is no "player" - there is just the editor - and this has caused a massive divide in what the editor can do compared to the main game.

Because the Map Editor has no 'player' it can't use any of the action processing logic the normal game uses, and instead uses a large copy-paste of the action processing and attempts to apply it to the map knowing there's no player associated. This 'works' for the most part, but some actions are inherently tied to a player and simply don't work in this disassociated context. Having this split of 'game' and 'editor' means we had to essentially write any action processing logic twice: once for the game, and once for the editor. Most people skipped the second part and so the editor fell behind. From time to time someone would report a problem with it, or ask if we could add some new functionality (or even if it could just do what the normal game could do). The internal joke was always "Nobody uses the Map Editor" to explain-away why it was so lacking.

When 0.17 tasks where being assigned, the topic of the Map Editor was brought up and I (Rseding) indicated I would be interested in working on it. Knowing what the problems where and how I wanted to go about fixing them I started. Several months of work (and several false-starts) later, I now have a 90%-there new Map Editor.

The new Map Editor has several key differences over the old one:
  • I removed the separation of 'normal game' and 'map editor'. The Map Editor is built right into the standard game logic. Anything the normal game can do it can do automatically. For those familiar with Factorio's modding: it's a new controller like the 'god controller', called 'editor controller'.
  • The standard interaction mechanics of the normal game 'just work' in the Map Editor (Hotkeys, QoL shortcuts, Pipette tool, etc.).
  • The Map Editor can be toggled on and off while playing any game. You no longer need to save, exit the game, go to the map editor, convert-save-to-scenario, and then finally load-in-map-editor. You can just be playing the game and switch to the editor (and back).
  • The Map Editor is multiplayer compatible: It doesn't make any distinction between singleplayer and multiplayer - it just works for both.
  • The Map Editor can pause/unpause the normal entity update but still interact (in multiplayer as well). Non-map-editor players are frozen in place but can still talk, switch to/from the editor, connect, and disconnect from the game.
  • The Map Editor is King. Anything you want to do, it lets you do (if I thought of it), at no point during development did I decide "No, you just can't do that with the editor - it would be too powerful". The point of it is to be powerful.


After replicating the functionality of the old editor, I started working on new features that have been requested by community and other team members:
  • A new cloning tool to copy entities/decoratives/tiles in any combination from one area (and surface) to another. This copies almost everything about the entity - items, recipes, variations and so on:


  • A paint-bucket tool for painting tiles that would paint-bucket replace all tiles of a specific type under the mouse:


  • Extending the force-editor to create/remove/edit forces fully.
  • Extending the entity-editor to let you place entities on other forces than the defaults.
  • Extending the decorative editor to have more fine-grain control of placing/removing without needing to know the exact decorative you're looking at.
  • Controlling the simulation rate and controlling tick execution.


Finally what I see as the ultimate request: "Ability to Copy & Paste an area from 1 map to another, transferring tiles/doodads/biters/trees/entities/items/...". The key part being "from 1 map to another" meaning "let me import stuff from other save files". I have a plan to make this work, but it will be restricted to single-player only. Still, I can see it being incredibly powerful when finished.

In summary: there is still more work to be done but the new Map Editor is coming together amazingly. I'm looking forward to what people will create/do with the new power the new Map Editor will bring. For us it will greatly speed up the work on the new campaign maps.

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

July 13

Friday Facts #251 - A Fistful of Frames

Factorio at the National Library of Technology Prague
If you are in Prague this summer, and wanting to satiate your Factorio cravings, you can stop in to the National Library of Technology Prague, where Factorio is loaded onto 150 computers for all to play. Entry is free for all visitors Monday to Friday 08:00 - 22:00 until the 31st of August. The PC's are running Linux (Fedora), loaded with a custom build of the game HanziQ put together, and you can host LAN servers and play with your friends.

On the 23rd of July we will be hosting our own Factorio LAN party at the library starting at 16:00 CEST (Prague time), so you can come along and play with us. It is advised to bring your own set of headphones if you are going to attend.

Rendering optimization
As we started to modernize our rendering backend, the absolute must have was to make it at least as fast as the old one. We had the chance to do things however we wanted, so we were excited about the capabilities newer APIs unlocked for us, and we had lot of ideas how to draw sprites as fast as possible.

But first, there is no need to reinvent the wheel, so let’s see how Allegro makes the magic happen. Allegro utilizes sprite batching, which means it draws multiple sprites that use same texture and rendering state, using a single command sent to the GPU. These draw commands are usually referred to as draw calls. Allegro draws sprites using 6 vertices, and it batches them into a C allocated buffer. Whenever a batch ends, it is passed to the OpenGL or DirectX drawing function that copies it (in order to not stall the CPU) and send the draw call.

That looks pretty reasonable, but we can’t do the exact same thing, because in DirectX 10, there are no functions for drawing from C-arrays directly, and it is mandatory to use vertex buffers. So our first version created vertex buffer to which current batch was always copied for use in a draw call, and we would reallocate a buffer with a larger size if the current batch wouldn’t fit. It was running quite fine, probably not as fast as Allegro version, and it lagged noticeably whenever the vertex buffer would need to be resized.

After reading some articles, for example optimizing rendering in Galactic Civilizations 3 and buffer object streaming on the OpenGL Wiki (which was very helpful), it became clear that the way to go is to have a vertex buffer of fixed size, and keep adding to until it is full. When we finish writing a batch to the buffer, we don't send a draw call right away, we write where this batch starts and ends into a queue, and keep writing into the buffer. When the buffer is full, we unmap it from system memory, and send all the queued draw calls at once. This saves on the expensive operation of mapping and unmapping the vertex buffer for each batch.

As we were trying to figure out how to serve data to the GPU in the most efficient way, we were also experimenting with what kind of data to send to GPU. The less data we send, the better, and Allegro was using 6 vertices per sprite with a total size of 144 bytes. We wanted to do point sprites which would require only 48 bytes per sprite and less overall maths for the CPU to prepare a single sprite. Our first idea was to use instancing, but we quickly changed our mind without even trying, because when researching the method, we stumbled upon this presentation specifically warning against using instancing for objects with low polygon count (like sprites). Out next idea was to implement point sprites using a geometry shader.

We tried it, and it worked great. We got some speedup due CPU needing to prepare less data, but when doing research how different APIs work with geometry shaders, we found out that Metal (and therefore MoltenVK) on macOS doesn’t support geometry shaders at all. After more digging, we found an article called Why Geometry Shaders Are Slow. So we tested using the geometry shader on a range of PCs in the office, and found that while it was faster on PCs with new graphics cards, the older machines took a noticeable performance hit. Due to the lack of support on macOS and the possible slowdown on slower machines, we decided to drop the idea.

It seems the best way to do point sprites is to use a constant buffer or texture buffer to pass point data to a vertex shader, and expand points into quads there. But at this time we already have all the optimizations mentioned in the first part, and the CPU part of rendering is now fast enough that we have put the point sprite idea on ice the for time being. Instead, the CPU will prepare 4 vertices per sprite with a total size of 80 bytes, and we will use a static index buffer to expand them to two triangles.

The following benchmark results are from various computers. The benchmark rendered a single frame at max zoom out (about 25,000 sprites) 600 times as fast as possible without updating the game, and the graph shows the average time to prepare and render the frame. On computers with integrated GPU there was little improvement because those seem to be bottlenecked by the GPU.

We also noticed higher speed-ups on AMD cards compared to nVidia cards. For example in my computer I have a GTX 1060 6GB and Radeon R7 360. In 0.16 rendering was much slower on the Radeon than on the GeForce, but with the new renderer the performance is almost the same (as it should be because GPU finishes its job faster than the CPU can feed it draw commands). Next we need to improve the GPU side of things, mainly excessive usage of video memory (VRAM), but more on that topic in some future Friday Facts...

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