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

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 (296)

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.
32 comments Read more

January 4

Friday Facts #276 - Belt item spacing & Script rendering

Hello, the office is slowly ramping back up after the Christmas and New year festivities.

Belt item spacing
Part of the final polishing and cleanup work of preparation for 1.0 is cleaning up and smoothing out some of the hiccups in the game. Many will remember FFF-266 where we talked about some of these upcoming changes and simplifications. One suggestion that came up was to adjust the belt throughput from its unfriendly 13.33 items/s.

Belt throughput is determined by 2 variables, how far the belt moves items each tick, and how much space there is between each item. There is a visual requirement that belts only move integer number of pixels every tick, so that is 1/2/3 pixels for transport belt, fast belt, express belt respectively. This means the only 'allowed' way to change transport belt throughput is by changing the spacing between the items.

The spacing currently is 9 pixels between items. The fact that each tile is 32 pixels, and that 9 is not a factor of 32, explains the odd throughput number. This spacing also leads to some undesirable behavior, such as when using the circuit network to read the belt contents sometimes the belt can fit 8 items, sometimes it can only fit 6, and the count will fluctuate between the two:



At this point it is quite obvious to reduce the spacing to 8 pixels, which is a factor of 32, and gives a nice even 15.00 items/second, which is what we have done for 0.17:



With a spacing of 8 pixels, belts now always fit exactly 8 items (4 on each side), so for instance, reading a fully compressed belt gives a reliable result:



The change overall gives a 12.5% buff to belts, provides nice round integers for calculating factory requirements, and removes a few oddities. A next step we are considering is tweaking the furnace recipes to match the belt speed, but that is a consideration for another day.

Script rendering
In the last few weeks I have been working on a system that allows mods to easily render geometric shapes, text and sprites in the game world. Like many modding features, the implementation of this rendering system was prompted by a modding interface request. When I first saw this request, I doubted the usefulness of adding a whole new API that needs to handle saving and rendering for just one mod author. A few months later, another mod author discovered a newly added method to create text that was only visible to one player and requested more features for it. Through further discussion with the mod author it became obvious that they were looking for a system to show some helper text and sprites to only one player. After other mod authors joined in to point out that the solutions implemented at the time were not sufficient, the idea of a script rendering system was dug out again and I picked up the task to implement it.

Of course, one does not simply invent a new system without first finding out what the system should be able to do. Here I want to thank the regulars in the #mod-making channel of the Factorio discord. They were a great help in suggesting features and always happy to answer questions about what they render in their mods. I also consulted old modding interface requests on the forums to find out what features were desired, amounting to a total of 12 requests that are now fulfilled by the new system. With this information I wrote a rough design document that listed the desired features without considering their implementation.

The current implementation of the script rendering boasts eight different object types. The basic geometric shapes being line, circle, rectangle, arc and polygon. Additionally, sprites, lights and text can be drawn. One of my main aims was to make the system as flexible as possible which I achieved by making every single property of the render objects changeable after creation. One example of this is that the size or orientation of a sprite can be changed without destroying and recreating it. This differs from the previous rendering that mods used. They would create many entity prototypes which had sprites with the desired orientation or size and then switch those out to change the orientation and size of the sprite. This frequent replacing of entities comes with a considerable performance cost which the script rendering completely eliminates.

Furthermore, the rendering objects are simply identified by numeric IDs which are much more performant to handle in Lua than LuaEntities. Another advantage of this dynamic system is that nothing in the rendering relies on the data stage. Unlike the mentioned technique of using entity prototypes, the script rendering does not need prototype data. This means that scenarios, the so called 'soft-mods', can also make full use of this new system.

https://cdn.factorio.com/assets/img/blog/fff-276-script-render.webm
https://cdn.factorio.com/assets/img/blog/fff-276-script-render.mp4

The first big point in the design document was to allow any target to be either an entity or a position. This point with, the addition of entity offsets, works beautifully in-game. Objects can be 'attached' to entities or placed at static positions. Even a combination of the two is possible if an object like a line has multiple targets. Due to the attachment to entities, the render objects are deleted when the entity is destroyed. This leads to some very useful behavior: If mods for example want to simply place some text above all their entities, they don't have to handle deleting the text when their entities are mined by the player or eaten by biters.

The second big point was conditional visibility, this means that it is possible to restrict the rendering of objects to certain forces and players. This will hopefully see use by the helper mods that prompted the implementation. This conditional visibility had also been requested in the past where it was handled as something that simply 'won't be implemented'. The main reasoning for this was the predicted performance impact of adding the player whitelist to many entities that the base game uses. This performance concern is irrelevant when using the script rendering because it is a completely separate system from the base game rendering. If you don't use mods you won't even notice that it's there and it won't impact game performance.

https://cdn.factorio.com/assets/img/blog/fff-276-script-render-2.webm
https://cdn.factorio.com/assets/img/blog/fff-276-script-render-2.mp4
In combination with other modding additions, the new render system opens a lot of interesting possibilities for mods to explore.

In general, this new system means that mods no longer have to abuse entities like beams, smoke or flying-text for rendering. This opens up a lot of possibilities of new rendering options that previously could not be considered, such as custom fonts for text or easily changeable scale and orientation of sprites. So, mods authors, please think about what rendering options would be useful for your mods and request them on the forum if they are not already implemented.

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

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