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 (748) - 97% of the 748 user reviews in the last 30 days are positive.
All Reviews:
Overwhelmingly Positive (35,961) - 98% of the 35,961 user reviews for this game are positive.
Release Date:
Feb 25, 2016
Developer:
Publisher:

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

Curator Review

Recommended
By Ѕtеам 250 April 30, 2018

“Rated 4th best Steam game of all time, with 99% positive reviews from 46,343 gamers!”

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
 

Recent updates View all (297)

January 18

Friday Facts #278 - The new quickbar

It's finally here
The proposal was first mentioned more than 1 and a half years ago, in FFF-191. Since then, we kept mentioning it in our blog posts and players kept asking about it.
After a lot of back and forth within the team on whether we should implement it or not, and how it should work, we finally have it almost ready for 0.17.

The quickbar


To refresh your memory: the quickbar is changed from being a separate inventory to simply a shortcut bar to the player's main inventory. It will mostly work like the current quickbar, except item slots can only be filters.

This means that when you place, for example, an Inserter in the new quickbar, it creates a shortcut telling you how many inserters of that type you have in your main inventory. Clicking the shortcut, will grab the first available stack from the inventory. That shortcut will stay there throughout the game, even if the inserters are depleted temporarily.

This solves quite a few annoyances:
  • No more random items appearing in the quickbar as you craft them.
  • No more items moving to different slots when they get depleted and re-crafted.
  • No more using the quickbar to carry things around.
  • No more "will this be crafted to inventory or to the quickbar?".
  • No more confusion when shift-clicking an item if it will go to the quickbar or the trash slots, or somewhere else.
  • Guides the player to make proper shortcuts. Players are much more likely to remember shortcuts they created themselves.
  • Player is in full control of the quickbar instead of the game trying to be 'smart'.
  • Managing 1 inventory is simpler than managing 2 inventories.
  • Relevant item counts.
The main inventory size was increased by 20 stacks to compensate for the inventory slots that now became shortcuts.

The quickbar pages
A suggestion that quickly gained traction was the ability to configure and switch between multiple pages of shortcuts, not just two.
So the new quickbar is actually 10 pages of shortcuts that you can configure as you like: e.g. a page for general factory building, a page for combat, a page for building trains, a page for building outposts, a page for oil processing, a page with utility blueprints. It's up to the player to configure these pages as they like.



When clicking on the button next to one of the selected pages, a page selector will open which shows all 10 pages of shortcuts. You can then easily select what page(s) you want to actively use and see on the main screen. The number of pages visible on the main screen is configurable.
The page selector also acts as an extended action bar, allowing you to quickly grab an item or blueprint that you don't commonly use, or allowing you to quickly configure your pages.

The default keyboard shortcuts changed a bit: keys 1 to 0 will pick the item in the slots of the top selected page. Shift + 1 to Shift + 0 will change the the top selected page. So an advanced player will be able to quickly swap pages to build what they want.

The ghost cursor
A feature for more advanced players is the ghost cursor: When selecting a 'buildable' item from the quickbar or when using the pipette tool, if you have no items of that type in your inventory, a ghost will be placed in the cursor instead.

It's a common situation where for example you build something and you run out of inserters. So instead of crafting more or running to the other side of the base to get more, you can place ghosts, continuing to focus on designing what you are building instead of being distracted.



To avoid confusion for new players, this feature is off by default and can be turned on in the interface settings menu.

Integration with blueprint library
This is still work in progress, since big changes are also coming to the blueprint library. The plan is that you will be able to create shortcuts for blueprints from the blueprint library. This means you can place your most commonly used blueprints and books in one of the shortcut pages and use them directly from the blueprint library without clogging your main inventory.

Non-GUI progress update
There was some talk following last weeks GUI progress update, as to why we don't release now, and finish the GUI's during the experimental phase. One major clarification I'd like to make, is that it is not only the GUI that is not yet finished. While GUI is currently the largest task remaining to be done for 0.17, there are still some other non-GUI features that are yet to be completed:

Finalization of new Fluid system
The new fluid system (FFF-274) is almost complete, but it is yet to be merged into master. After internal testing we have been making efforts to tune the new behavior, specifically how throughput over distance and flow with different fluids works.

High resolution enemies
The new Biters and Worms have been showcased already in previous blog posts (FFF-259, FFF-268), and the last puzzle piece is the new Spitters. Alongside a graphical update, we have also been experimenting with some functional changes to the enemies.

Further map generation tweaks
We presented our most recent developments on the map generation in FFF-258. Since that post, there have been some further planned changes and improvements, specifically to the placement of tiles, biomes, trees, doodads, cliffs.

Playtesting, bug fixing, and design balancing
It seems to always be the case, but $nextUpdate is going to be the biggest Factorio release so far. While some initial playtesting shows that most things are stable, we have yet to have our typical office-wide week/fortnight of playtesting and tweaking. Inevitably things that we need to solve will come up during this playtesting, so it would be unwise to release before it is complete. There are also over 50 unsorted bug reports in our forum, which we will need to sort through.

Looking over what is left to be done, It is clear to me that the release won't be ready in January.
When we are ready to release 0.17, its launch definitely won't be a surprise. We will announce the exact date in the FFF at least the week before.

As always, let us know what your think on our forum.
46 comments Read more

January 11

Friday Facts #277 - GUI progress update

GUI progress update
This is a continuation of the last status report from FFF-269. As it might not be a surprise, the biggest bottleneck of the 0.17 release is the GUI. I like to believe, that we have learned a lot from the pitfalls of the collaborative creative process of GUI. This is the typical way we were redesigning the GUI:

  • Two to three people started discussing what could be cool to change in the particular GUI. Some people randomly joined and left the ongoing discussion. Arguments to discard certain ideas have to be repeated over and over. Then the discussion is ended because of something.
  • A week later people start talking again, most of them forgot most of the stuff, or were discussing it with different people, so they assume some details of the changes to be understood by everyone, while they aren't.
  • They come to an agreement how it should be done.
  • They have a random discussion about it a week later and figure out, they had completely different ideas about how it should be done, they just didn't articulate them precisely. Both are kind of angry to have to reopen and re-negotiate the subject again.
  • Someone starts to implement the GUI, but half-way through it is uncovered, that there was another layer of misunderstanding when specifying how should the work be done, and we need to go to step 1 again and repeat.

Since many GUIs are thought and worked on in parallel, these situations overlapped and amplified the problems of mixing things up in our heads about what we agreed on in which GUI.

Luckily, we eventually figured out, that it can't be done like this, and since there is a lot of work in the GUI, we need to make a process. It goes like this:
  • First, there is some general discussion about the GUI, all team members can share their ideas.
  • kovarex + Twinsen sit alone in the office, and discuss for some time (can be hours), all the pros and cons of how things should be done, and make some agreement.
  • Twinsen writes a detailed UX document about the GUI containing the structure, and more importantly the behaviour, in a detailed manner.
  • Twinsen + kovarex discuss the UX document and propose changes until they agree on the final version.
  • Albert + Aleš take the UX document and create a UI mockup based on it.
  • kovarex + Twinsen + Albert agree on the UI mockup or propose changes.
  • Someone is assigned to implement the GUI based on the UX document and UI mockup
  • kovarex reviews that the implementation is correct and points out some inconsistencies that he can see. Part of this step is making sure, that we share as many GUI styles and code as possible across different GUIs.
  • kovarex + Albert have a final look on the implementation and fix final details until they both agree that the screen is fully finished.
Having the UX documents/UI mockups always available proved to be a huge time saver. Not only it helps us to solve the communication problems, we also don't have to remember and re-articulate decisions from some time ago as we can just open the document and see what we agreed on and instantly continue where we left off.

A good part of this strict pipeline is that we now have better knowledge of the state of the work progress.
These are the GUI screens that we hope to deliver for 0.17:



You can see, that there is still a lot of to do, but the work tends to accelerate as more and more of the GUI layouts/tilesets/standards are being finalized and reused. The conclusion is that 0.17 experimental in January is possible, but it might be February as well :).

The little details
Also, one of the reasons the work progresses slower, is that since we are making final versions of everything, we want to make it feel polished before we consider it finished, since there won't be time to come back to it.

For example, in every settings screen, we have the 'reset to default' button now. The first logical step was to only enable the button, when some of the options are different from the defaults. But the next logical step was to somehow let the user know, what settings will be changed when he uses the reset button. So we simply highlight all the non-default settings when hovering the reset button, and it feels nice since suddenly you have instant feedback of what you can expect from the action.

https://cdn.factorio.com/assets/img/blog/fff-277-reset.webm
https://cdn.factorio.com/assets/img/blog/fff-277-reset.mp4

I understand, that spending too much time in settings GUI might not look like a good idea, since it is not used that much and the in-game screens are more important, but many of these principles we realize on the way will be useful when designing changes for the in-game GUI.
The scaling problem and solution <font size="2">(kovarex)</font>
One of the many goals of the GUI rewrite was to make sure that the GUI looks correct in all possible UI scale values. By correct, we mainly mean, that the proportions of everything stay the same, so it is just smaller, but not deformed in a weird way. This might look like a simple thing to do, but it isn't as all the GUI values (sizes, widget positions, paddings etc.) are integer values, as in the end, every element needs to be on some specific pixel as long as we want it to be crispy clear.

Imagine that you have a 1 pixel wide gap between two 20 pixel wide buttons and then you want it to show in 120%. The buttons are enlarged to 24 pixels, but the gap either stays 1 pixel or becomes 2, but the proportions of the layout changes.

To solve this (and other issues), we decided to use something we call "modules". 1 module is 4 pixels in standard scale (100%), and almost everything is a multiplication of modules (sizes, positions, paddings etc). On top of that, we limited the possible scale values to be multiples of 25% (from 75% to 200%). This means, that the size of one module can be different (from 3 pixels at 75% to 8 pixels at 200%) but the proportions of everything stay the same, so it looks correct.



This works quite well so far, but it brings another problem for 0.17. I don't know if anyone noticed, but the item slots (inventory/logistic filters, crafting slots etc.) were intentionally scaled less than other UI elements. The reason for this was that the 32✕32 icons we have for all the items/fluids/recipes don't look good if stretched too much.


32✕32 icons that are stretched to 200% don't work good.

But since we had to abolish this special rule for 0.17 we need to make sure that all the 32✕32 icons (285 items, 27 signals, fluids and more) will have to be provided in 64✕64 resolution, so all the supported UI scales will look nice. This is going to be quite a lot of work, but since we render the icons from 3D models anyway, it should be manageable. We will probably push the high-res icons to 0.17 during the experimental phase.

Procedural Wave defense
We have had the Wave defense scenario in the game for a few years now, and over that time I have collected a lot of feedback. One problem I have determined, is that the scenario really lacks replayability, due to the fixed map. Since the map doesn't change at all, once you have a set of blueprints and tactic that works, repeat plays are mostly boring.

With recent changes and the great work by TOGoS, the procedural map generation is working really well, and is very reliable for a given set of settings. This gave me the idea, that it might be possible to make the Wave defense use a new map every time. I have been experimenting with some preset values, and I believe it will work really well.

However I have some indecision within myself, and there are several advantages and disadvantages between a handmade custom maps and randomly generated worlds.

Advantages of a bespoke map
  • The map can be specifically designed and tweaked for a better experience, I can test and iterate the way biters move through the map, adjust the placement of trees, resources, tune the difficulty etc.
  • We don't have to worry about map generation engine changes breaking the scenario.
  • It is a reliable experience for all players, people can share specific tips, designs and tactics that are more specific for the map.
Advantages of procedural maps
  • The scenario has much greater replayability.
  • We don't have to worry about migrating map data, tiles, entities, etc. to newer versions.
  • Any improvements to the map generation will be reflected in the scenario.
  • People can't cheese the scenario using other peoples blueprints.
  • We can add some configuration options for people who want to tailor the experience.
  • It is easy to add support for servers to continue running after victory/defeat.

So I am making the changes now to test whether procedural can work,and it shouldn't take too long as most of the scenario script will remain the same. I wanted to ask for some community feedback and thoughts: Have many of you played the Wave defense? Do you think a random map would be more fun? Do you think you would play it more if the map was different each time?

As always, you are welcome to let us know what your think on our forum.
40 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

Windows
Mac OS X
SteamOS + Linux
    Minimum:
    • 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.
    Recommended:
    • OS: Windows 10, 8, 7 (64 Bit)
    • Processor: Quad core 3Ghz+
    • Memory: 8 GB RAM
    • Graphics: 2GB Video memory
    • Storage: 1 GB available space
    Minimum:
    • 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
    Recommended:
    • 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
    Minimum:
    • 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
    Recommended:
    • OS: Linux (tarball installation)
    • Processor: Quad core 3GHz+
    • Memory: 8 GB RAM
    • Graphics: 2GB Video memory
    • Storage: 1 GB available space

What Curators Say

481 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


Language


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