Factorio - Klonan
The 0.16 stabilisation update
We had quite a lot of critical bugs after the 0.16.8 release that introduced the logistic chest finalisations mentioned in the last FFF. I'm sorry for the trouble, but it is called experimental version for a reason.

It seems that 7 releases in the past week has been enough to stabilize it. We are finally in a state, where we are fixing more bugs than are reported, and we are reaching the first boundary of less than 100 active bug reports.

It seems that the most urgent things are to be be finished soon, and we could find the needed time to dive into the belt logic to be able to consolidate it. This is my plan for the next week.

Removing logistics bots from the game
During more boring FFF, I like to do these gameplay rants where I share my ideas about game design. Here is one of them.

Ever since I started playing Factorio, I have thought of logistic bots as too powerful. Actually, I refused to use them thinking "surely there is some catch to this and they can't replace belts". Since then I was always a "bot hater". I believed it trivialized base building and managing belts. I also believe that building belts is way more fun due to it's inherent complexities, challenges, and emergent situations (the most common example being belt balancing).

Bots vs. belts is a controversial subject, even in our team, but most of us believe bots are too powerful. So we did small nerfs from time to time in an effort to compensate for this, but we still keep coming to the same conclusion.

My argument is that bots are simply fundamentally better. Bots basically cheat by "teleporting" items, plus they are extremely easy to build and expand. This means that almost any nerf we throw at them is always solved by building more bots and/or more roboports and/or more solar panels. All of this can be done with a simple copy paste using blueprints. Plus they are even UPS friendly, so it seems like bots are the win-win-win solution.

So I had this rather crazy idea of removing logistic bots from the game. Basically my idea was that construction bots would still be a thing and player logistics would still work. This would be done by:
  • Merging logistic and construction bots into just Flying Robots.
  • Removing Active provider, Buffer and Requester chests and having just Passive provider and Storage chests.
  • Flying Robots will do everything construction bots do now and also supply the player.
  • Simplifying recipe complexity a bit so the belt spaghetti does not get ridiculous.

Now, hopefully you aren't smashing your desk and writing us an angry email. Don't worry, logistics bots won't be removed from the game, mostly because it's a feature that has been developed and polished quite a lot. Also many players love the feature, and we've all become used to it over the years. But think of it a different way, imagine there were two parallel universes:
  • The universe we are in, where Factorio has had logistic bots since very early.
  • A universe where Factorio never had this feature. Construction bots were eventually added, and using bots to move items freely is nothing more than an idea that pops up from time to time but it's quickly discarded due to it breaking the game.
Which Factorio would be the best and most fun one for the players in that universe?
To be honest it's very hard to decide. I would go with the more pure Factorio from universe 2 that focuses on it's core and most fun mechanic: belts and belt logistics. I'm curious what you guys think.
I mentioned this, because I think this way often in an attempt to "make the best game ever" without being influenced by my biases of being used to some feature or style of play.

But let's return to reality and the game we have now. Quite recently I actually realized that bots are not as bad as I thought. The logistics system is placed very late in the tech tree, so most of a typical playthrough will be done using belts. The fact that you get this almost game breaking feature is not so bad because it's late in the game. After this you can continue to challenge yourself and build even bigger using bots, or belts or both.

We are still looking to incentivize belt building a bit more, since it is the more fun way to play Factorio, but the question is how.
We have ideas like increasing the power consumption, decreasing the maximum stack size bots can carry to 2 items or buffing belts by adding a "stacked" belt tier.

Like I mentioned before, I try to balance things by looking at numbers and objective facts. I'm trying to determine how much better bots are than belts, so I can know if for example nerfing the stack size to 2 will have the desired effect, or just make players angry. I thought of metrics like throughput over time to set up, or throughput over base size.

But how do these metrics influence the big picture and will any of these make the game more fun in the long run?

We don't know the answer to these questions yet. What is your take on this bots versus belts thing? What changes, if any, could we do to make everything more fun?

Pro-bot arguments:
  • The fact that they are so powerful, gives a very big sense of progression. They are behind a late game research, and gives you things that are very powerful and game changing.
  • It adds large diversity to the game.
Anti-bot arguments:
  • Bot bases are usually less complex and less interesting to look at, manage and expand.
  • Because of their ease of use (and apparent ease of use), players tend to go to bots. We believe that belts are more fun, but we are guiding the player towards a less fun style of play.
  • When you learn that bots exist and how they work, building bases with belts just seems tedious.
Related to this I'd like to give a shout-out to forum member ultramn, for his interesting Self-contained 1,000 SPM base. We analysed his save while we were having some bot vs. belt discussions this week.
His save proves that bots can get ridiculously powerful, but at the same time it shows that there is a lot of fun to be had with bots if you challenge yourself to make something.



As always, let us know what you think on our forum.
Factorio - Klonan
The 0.16 stabilisation update
We had quite a lot of critical bugs after the 0.16.8 release that introduced the logistic chest finalisations mentioned in the last FFF. I'm sorry for the trouble, but it is called experimental version for a reason.

It seems that 7 releases in the past week has been enough to stabilize it. We are finally in a state, where we are fixing more bugs than are reported, and we are reaching the first boundary of less than 100 active bug reports.

It seems that the most urgent things are to be be finished soon, and we could find the needed time to dive into the belt logic to be able to consolidate it. This is my plan for the next week.

Removing logistics bots from the game
During more boring FFF, I like to do these gameplay rants where I share my ideas about game design. Here is one of them.

Ever since I started playing Factorio, I have thought of logistic bots as too powerful. Actually, I refused to use them thinking "surely there is some catch to this and they can't replace belts". Since then I was always a "bot hater". I believed it trivialized base building and managing belts. I also believe that building belts is way more fun due to it's inherent complexities, challenges, and emergent situations (the most common example being belt balancing).

Bots vs. belts is a controversial subject, even in our team, but most of us believe bots are too powerful. So we did small nerfs from time to time in an effort to compensate for this, but we still keep coming to the same conclusion.

My argument is that bots are simply fundamentally better. Bots basically cheat by "teleporting" items, plus they are extremely easy to build and expand. This means that almost any nerf we throw at them is always solved by building more bots and/or more roboports and/or more solar panels. All of this can be done with a simple copy paste using blueprints. Plus they are even UPS friendly, so it seems like bots are the win-win-win solution.

So I had this rather crazy idea of removing logistic bots from the game. Basically my idea was that construction bots would still be a thing and player logistics would still work. This would be done by:
  • Merging logistic and construction bots into just Flying Robots.
  • Removing Active provider, Buffer and Requester chests and having just Passive provider and Storage chests.
  • Flying Robots will do everything construction bots do now and also supply the player.
  • Simplifying recipe complexity a bit so the belt spaghetti does not get ridiculous.

Now, hopefully you aren't smashing your desk and writing us an angry email. Don't worry, logistics bots won't be removed from the game, mostly because it's a feature that has been developed and polished quite a lot. Also many players love the feature, and we've all become used to it over the years. But think of it a different way, imagine there were two parallel universes:
  • The universe we are in, where Factorio has had logistic bots since very early.
  • A universe where Factorio never had this feature. Construction bots were eventually added, and using bots to move items freely is nothing more than an idea that pops up from time to time but it's quickly discarded due to it breaking the game.
Which Factorio would be the best and most fun one for the players in that universe?
To be honest it's very hard to decide. I would go with the more pure Factorio from universe 2 that focuses on it's core and most fun mechanic: belts and belt logistics. I'm curious what you guys think.
I mentioned this, because I think this way often in an attempt to "make the best game ever" without being influenced by my biases of being used to some feature or style of play.

But let's return to reality and the game we have now. Quite recently I actually realized that bots are not as bad as I thought. The logistics system is placed very late in the tech tree, so most of a typical playthrough will be done using belts. The fact that you get this almost game breaking feature is not so bad because it's late in the game. After this you can continue to challenge yourself and build even bigger using bots, or belts or both.

We are still looking to incentivize belt building a bit more, since it is the more fun way to play Factorio, but the question is how.
We have ideas like increasing the power consumption, decreasing the maximum stack size bots can carry to 2 items or buffing belts by adding a "stacked" belt tier.

Like I mentioned before, I try to balance things by looking at numbers and objective facts. I'm trying to determine how much better bots are than belts, so I can know if for example nerfing the stack size to 2 will have the desired effect, or just make players angry. I thought of metrics like throughput over time to set up, or throughput over base size.

But how do these metrics influence the big picture and will any of these make the game more fun in the long run?

We don't know the answer to these questions yet. What is your take on this bots versus belts thing? What changes, if any, could we do to make everything more fun?

Pro-bot arguments:
  • The fact that they are so powerful, gives a very big sense of progression. They are behind a late game research, and gives you things that are very powerful and game changing.
  • It adds large diversity to the game.
Anti-bot arguments:
  • Bot bases are usually less complex and less interesting to look at, manage and expand.
  • Because of their ease of use (and apparent ease of use), players tend to go to bots. We believe that belts are more fun, but we are guiding the player towards a less fun style of play.
  • When you learn that bots exist and how they work, building bases with belts just seems tedious.
Related to this I'd like to give a shout-out to forum member ultramn, for his interesting Self-contained 1,000 SPM base. We analysed his save while we were having some bot vs. belt discussions this week.
His save proves that bots can get ridiculously powerful, but at the same time it shows that there is a lot of fun to be had with bots if you challenge yourself to make something.



As always, let us know what you think on our forum.
Factorio - posila87
Minor Features
  • Added 'allow spectators' option to PvP.
Changes
  • Changed rail world settings to have normal biters frequency.
Bugfixes
  • Fixed loading specific saves wouldn't migrate the character requests correctly to request from buffer chests. more
  • Fixed that migrating saves would make research impossible in the level 4 of New hope campaign. more
  • Fixed that inserters would try to put items into furnaces that could never fit. more
  • Fixed requester chests wouldn't keep up with the request amount demand in logistic heavy saves. more
  • Fixed that request chests weren't equally distributed when there were not enough robots.
  • Fixed that migration to 0.16.8 which de-duplicated logistic requests wasn't doing so for offline players. This could cause crashes as the internal data structures take it as granted.
  • Fixed that download progress bar in the sync save with mods wasn't being updated.
  • Fixed that exiting the connection in progress (by pressing escape) soon enough could result in a screen without any menu.
  • Fixed some PvP game modes being won by launching a rocket.
  • Fixed config.ini would be purged when game decreases graphics settings when loading sprites throws an error. more

You can get experimental releases by selecting the '0.16.x' beta branch under Factorio's properties in Steam.
Factorio - posila87
Minor Features
  • Added 'allow spectators' option to PvP.
Changes
  • Changed rail world settings to have normal biters frequency.
Bugfixes
  • Fixed loading specific saves wouldn't migrate the character requests correctly to request from buffer chests. more
  • Fixed that migrating saves would make research impossible in the level 4 of New hope campaign. more
  • Fixed that inserters would try to put items into furnaces that could never fit. more
  • Fixed requester chests wouldn't keep up with the request amount demand in logistic heavy saves. more
  • Fixed that request chests weren't equally distributed when there were not enough robots.
  • Fixed that migration to 0.16.8 which de-duplicated logistic requests wasn't doing so for offline players. This could cause crashes as the internal data structures take it as granted.
  • Fixed that download progress bar in the sync save with mods wasn't being updated.
  • Fixed that exiting the connection in progress (by pressing escape) soon enough could result in a screen without any menu.
  • Fixed some PvP game modes being won by launching a rocket.
  • Fixed config.ini would be purged when game decreases graphics settings when loading sprites throws an error. more

You can get experimental releases by selecting the '0.16.x' beta branch under Factorio's properties in Steam.
Factorio - posila87
Minor Features
  • Added a time limit option to PvP game modes 'Production score' and 'Oil harvest'
  • Added 'score per minute' to the PvP Production score GUI.
Bugfixes
  • Fixed a crash when blueprinting modded logistic storage chests. more
  • Fixed requester chests wouldn't work with specific combinations of storage, buffer, and provider chests. more
  • Fixed a crash with the command line map preview option. more
  • Fixed the world-icon for the cliff explosive didn't match the item icon. more
  • Fixed the progress indicator in the browse-mods GUI would update too quickly. more
  • Fixed changing the force of a robot waiting to charge would break the robot. more
  • Fixed that joining modded multiplayer games where the spawn area was deleted would error. more
  • Fixed that pasting text didn't work correctly in any text field. more
  • Fixed a crash related to tile transitions. more
  • Fixed logistic storage filters would be ignored in some specific cases. more
  • Fixed that side-loading underground belts could lead to them getting stuck. more
  • Fixed that modded storage chests would allow more than 1 filter when the extra filters weren't valid. more
  • Fixed that the map preview seed wouldn't get used when the generate map GUI had an exchange string entered. more
  • Added yet another migration fixing invalid state created between 0.16.8 and 0.16.11.
  • Fixed that startup mod settings could be changed while in-game by clicking the label on checkboxes. more
  • Fixed that tooltip of disabled widgets didn't work.
  • Added greyed-out look to disabled textfield and checkbox to make it more clear that it isn't editable.
  • Fixed one of the curved rail segment visualizations wasn't aligned correctly. more
  • Fixed that the console could be opened in a paused game where it can't be interacted with.
  • Fixed issues of console in combination with technology GUI in multiplayer. more
  • Fixed changelogs (including mod changelogs) not properly displaying the "All" subversion for a version x.y when there was no version x.y.0. more
  • Fixed horizontal scroll pane scroller. more
  • Fixed that changing value in GameViewSettings in the Lua script didn't update the gui until the game was reloaded.
  • Fixed a crash when controller view is disabled. more
  • Fixed script error when destroying a chest in the supply scenario.
  • Fixed PvP production score price calculation.
Modding
  • Entities without an item-to-place can still be deconstructed if they are minable.
Scripting
  • Added LuaPlayer::blueprint_to_setup read.
  • Changed default value of 'expires' when creating ghost through LuaSurface::create_entity from 'true' to 'false'.
  • Fixed invalid internal state + crashes when ghost without "expires = false" was created through the script when ghost time to live was 0. more

You can get experimental releases by selecting the '0.16.x' beta branch under Factorio's properties in Steam.
Factorio - posila87
Minor Features
  • Added a time limit option to PvP game modes 'Production score' and 'Oil harvest'
  • Added 'score per minute' to the PvP Production score GUI.
Bugfixes
  • Fixed a crash when blueprinting modded logistic storage chests. more
  • Fixed requester chests wouldn't work with specific combinations of storage, buffer, and provider chests. more
  • Fixed a crash with the command line map preview option. more
  • Fixed the world-icon for the cliff explosive didn't match the item icon. more
  • Fixed the progress indicator in the browse-mods GUI would update too quickly. more
  • Fixed changing the force of a robot waiting to charge would break the robot. more
  • Fixed that joining modded multiplayer games where the spawn area was deleted would error. more
  • Fixed that pasting text didn't work correctly in any text field. more
  • Fixed a crash related to tile transitions. more
  • Fixed logistic storage filters would be ignored in some specific cases. more
  • Fixed that side-loading underground belts could lead to them getting stuck. more
  • Fixed that modded storage chests would allow more than 1 filter when the extra filters weren't valid. more
  • Fixed that the map preview seed wouldn't get used when the generate map GUI had an exchange string entered. more
  • Added yet another migration fixing invalid state created between 0.16.8 and 0.16.11.
  • Fixed that startup mod settings could be changed while in-game by clicking the label on checkboxes. more
  • Fixed that tooltip of disabled widgets didn't work.
  • Added greyed-out look to disabled textfield and checkbox to make it more clear that it isn't editable.
  • Fixed one of the curved rail segment visualizations wasn't aligned correctly. more
  • Fixed that the console could be opened in a paused game where it can't be interacted with.
  • Fixed issues of console in combination with technology GUI in multiplayer. more
  • Fixed changelogs (including mod changelogs) not properly displaying the "All" subversion for a version x.y when there was no version x.y.0. more
  • Fixed horizontal scroll pane scroller. more
  • Fixed that changing value in GameViewSettings in the Lua script didn't update the gui until the game was reloaded.
  • Fixed a crash when controller view is disabled. more
  • Fixed script error when destroying a chest in the supply scenario.
  • Fixed PvP production score price calculation.
Modding
  • Entities without an item-to-place can still be deconstructed if they are minable.
Scripting
  • Added LuaPlayer::blueprint_to_setup read.
  • Changed default value of 'expires' when creating ghost through LuaSurface::create_entity from 'true' to 'false'.
  • Fixed invalid internal state + crashes when ghost without "expires = false" was created through the script when ghost time to live was 0. more

You can get experimental releases by selecting the '0.16.x' beta branch under Factorio's properties in Steam.
Factorio - posila87
Bugfixes
  • Fixed crash related to setting logistic requests by circuit network.
  • Fixed requester chest state migration between different save versions.
  • Fixed one of the problems of internal provider data corruption related to setting inventory bar limit.
  • Fixed yet another requester chest state migration error.
  • Fixed that burner inserter didn't show the fuel icon when out of energy sometimes. more
  • Fixed that some specific pre 0.15 maps couldn't be loaded.

You can get experimental releases by selecting the '0.16.x' beta branch under Factorio's properties in Steam.
Factorio - posila87
Bugfixes
  • Fixed crash related to setting logistic requests by circuit network.
  • Fixed requester chest state migration between different save versions.
  • Fixed one of the problems of internal provider data corruption related to setting inventory bar limit.
  • Fixed yet another requester chest state migration error.
  • Fixed that burner inserter didn't show the fuel icon when out of energy sometimes. more
  • Fixed that some specific pre 0.15 maps couldn't be loaded.

You can get experimental releases by selecting the '0.16.x' beta branch under Factorio's properties in Steam.
Factorio - Klonan
Hello, this is the last Friday of 2017, and as such, the last Friday facts of this year.

0.16.8/9 is out
It almost seams that our team never stops. To be honest, even on the Christmas eve, when everything was over and family went to sleep, I couldn't resist to stay up for little while to fix a few things :)

The fluid balancing changing follow-up is in this release
- Changed fluid wagon capacity from 75k to 25k (Same as storage tank). - Lowered fluid wagon weight from 3000 to 1000 (same as cargo wagon). - Changed fluid wagon recipe so it requires just 1 storage tank instead of 3. - Lowered barrel fluid capacity from 250 to 50. (So cargo wagon with barrels holds 20k and logistic robots are not too strong alternative to carrying fluids.) - Decreased barrelling crafting time from 1 second to 0.2 seconds.

The overall feeling we had was that fluid wagon capacity is too large, fluid trains have to barely move around, and waiting for the wagon to be filled often takes too much time.

We also wanted to make sure, that wagon with barrels just can't hold more fluids compared to fluid wagon, because even when barrels are generally more work to handle, it is not what you would intuitively expect.

With the fluid wagon separation gone, the main advantage of barrels is not capacity, but versatility. They can be combined with other barrels of different kind, or items in the train, they can be limited by the inventory limit, or easily filtered by filter inserters, transported by robots, belts etc. This advantage seems to be much more intuitive and I hope it makes sense now as whole with the removal of the fluid wagon separation to you.

The buffer chest finalization
The 0.16.8 also finishes the buffer chests. The promises from last FFF materialized in this update.

Requester chests always have priority over buffer chests, and by default request chests don't even request from buffers chests, only player and construction. This is what we feel is the most common use-case. But as we don't want to limit the possibilities, so the behaviour can be manually changed.



The 2017 recapitulation
Jakub Dvorský, the head of Amanita design, said that projects tend to be more creative in the fist 3 years of the development, while the last 2 years are more about tweaking, polishing and finishing. I feel exactly the same about Factorio. Most of the creative work has been done, and we focus more and more on finishing the game.

We've said it before, that the game will be finished and released during this year and we mean it this time. There is even the joke in the office that the game is always to be released 'next summer', which never comes. But this time we really really mean it, we want to finish the game in 2018. Finishing doesn't necessary mean no new stuff for Factorio, it might even mean the opposite. Why? Because we will have all of our technology/graphical/design debts paid.

Debts from the past we solved this year:
  • We stabilized 0.14, which meant the rewrite of the multiplayer internals based on our experience form the first version, and we now have something that seems to work quite reliably.
  • We went back and created high-resolution variants of the vast majority of the graphics.
  • We revisited the terrain and decoratives for the last time to make an environment we are content with
  • We integrated blueprint usage into network games by allowing them to be copied between players, and allowed them to be moved between individual save games.
  • We have rewritten most of the internals of how GUI works for 0.16, which should simplify additions related to GUI in the future.
  • Opened the subject of interactive mini tutorials, far from finished, but we are getting the experience there as well.
  • Tightened the user integration of mods, once the new mod portal site (which shouldn't be as unusably slow as the current one) is done, it will improve the usability of mods a lot.
  • Improved programming productivity internally by getting rid of boost, improving compile times, extending automated/heavy/valgrind tests on the server, and starting more elaborate internal documentation. So many more problems are discovered early on, and people spend less time figuring out what is wrong.
  • Improved Factorio link time in Visual studio. This was done by Rseding91, who provided the visual studio guys with Factorio sources and kept bothering them until they tested that and improved C++ link time in the 15.5 Visual studio release. The final release of Factorio with all optimisations and link time code generation took 45 minutes to compile and link, and now it takes 3.5 minutes. This sped up our release time quite a bit.

There are still some debts to be finished in 2018, mainly the GUI update, which is actually a huge project. We have very large number of different windows in the game, and if we really want to improve both the looks and the usability, we will have to put a lot of time and thought into it. Also the mini tutorials will have to be finished and few entities will probably be re-designed.

But once all these things are solved, it not only means that we could get out of early access, but also, if we ever decide to add more content to Factorio, having these things finished should pay off by letting us to focus on the new things only instead of having to fix the old ones. Another possibility, is to use the Factorio engine for completely different game or for fast prototyping of crazy ideas. Whatever we decide to do in the future, having polished base seems like an important thing to have.

Almost 6 years of Factorio in numbers
The initial Factorio commit was done 31.3. 2012, so Factorio is in the development for 5 years 9 months.
I did this kind of comparison in fff-88 which was even before the steam release, I hope you don't mind if I compare it with the current state.

Our effort in numbers:
  • In development for 1106 → 2099 days.
  • 88 → 221 public releases.
  • 14 082 → 34 686 commits in the master branch.
  • 204 917 → 465 550 lines of code, 546 339 → 1 258 939 words and 7 693 483 → 17 517 675 characters, this is equivalent to 15 → 35 average books.
  • 20 791 → 56 947 different sprites with 54 114 147 → 336 907 147 non empty pixels.
  • 1492 → 5034 resolved bugs (only counting those reported on our forums).
  • 3027 → 7670 lines in the changelog.
Results in:
  • 56 500 → 341 000 Youtube videos
  • 403 000 → 1 900 000 Google hits of Factorio.
  • 75 146 → 303 773 forum posts
  • 11 704 years of combined playtime played on steam.
  • and finally 74 914 → 1 200 000+ copies sold.

This leads me to different kind of comparisons:
  • 2.7 → 0.42 lines of code per one buyer
  • 12.7 → 16.5 commits per day or
  • 2.7 → 6 Youtube videos per one sprite
  • 2.3 years of playtime per resolved bug report
  • 4 months of playtime per one commit
  • 9.1 days of play for each line of code
  • 18.2 minutes for each pixel
I could go like this for a while :) But mainly, it makes me realize, that making changes, improving things, and fixing even small annoyances in the game is worth it.

I would also like provide the overall graph of commits frequency, some of the releases are quite visible there :)



As always, let us know what you think on our forum.
Factorio - Klonan
Hello, this is the last Friday of 2017, and as such, the last Friday facts of this year.

0.16.8/9 is out
It almost seams that our team never stops. To be honest, even on the Christmas eve, when everything was over and family went to sleep, I couldn't resist to stay up for little while to fix a few things :)

The fluid balancing changing follow-up is in this release
- Changed fluid wagon capacity from 75k to 25k (Same as storage tank). - Lowered fluid wagon weight from 3000 to 1000 (same as cargo wagon). - Changed fluid wagon recipe so it requires just 1 storage tank instead of 3. - Lowered barrel fluid capacity from 250 to 50. (So cargo wagon with barrels holds 20k and logistic robots are not too strong alternative to carrying fluids.) - Decreased barrelling crafting time from 1 second to 0.2 seconds.

The overall feeling we had was that fluid wagon capacity is too large, fluid trains have to barely move around, and waiting for the wagon to be filled often takes too much time.

We also wanted to make sure, that wagon with barrels just can't hold more fluids compared to fluid wagon, because even when barrels are generally more work to handle, it is not what you would intuitively expect.

With the fluid wagon separation gone, the main advantage of barrels is not capacity, but versatility. They can be combined with other barrels of different kind, or items in the train, they can be limited by the inventory limit, or easily filtered by filter inserters, transported by robots, belts etc. This advantage seems to be much more intuitive and I hope it makes sense now as whole with the removal of the fluid wagon separation to you.

The buffer chest finalization
The 0.16.8 also finishes the buffer chests. The promises from last FFF materialized in this update.

Requester chests always have priority over buffer chests, and by default request chests don't even request from buffers chests, only player and construction. This is what we feel is the most common use-case. But as we don't want to limit the possibilities, so the behaviour can be manually changed.



The 2017 recapitulation
Jakub Dvorský, the head of Amanita design, said that projects tend to be more creative in the fist 3 years of the development, while the last 2 years are more about tweaking, polishing and finishing. I feel exactly the same about Factorio. Most of the creative work has been done, and we focus more and more on finishing the game.

We've said it before, that the game will be finished and released during this year and we mean it this time. There is even the joke in the office that the game is always to be released 'next summer', which never comes. But this time we really really mean it, we want to finish the game in 2018. Finishing doesn't necessary mean no new stuff for Factorio, it might even mean the opposite. Why? Because we will have all of our technology/graphical/design debts paid.

Debts from the past we solved this year:
  • We stabilized 0.14, which meant the rewrite of the multiplayer internals based on our experience form the first version, and we now have something that seems to work quite reliably.
  • We went back and created high-resolution variants of the vast majority of the graphics.
  • We revisited the terrain and decoratives for the last time to make an environment we are content with
  • We integrated blueprint usage into network games by allowing them to be copied between players, and allowed them to be moved between individual save games.
  • We have rewritten most of the internals of how GUI works for 0.16, which should simplify additions related to GUI in the future.
  • Opened the subject of interactive mini tutorials, far from finished, but we are getting the experience there as well.
  • Tightened the user integration of mods, once the new mod portal site (which shouldn't be as unusably slow as the current one) is done, it will improve the usability of mods a lot.
  • Improved programming productivity internally by getting rid of boost, improving compile times, extending automated/heavy/valgrind tests on the server, and starting more elaborate internal documentation. So many more problems are discovered early on, and people spend less time figuring out what is wrong.
  • Improved Factorio link time in Visual studio. This was done by Rseding91, who provided the visual studio guys with Factorio sources and kept bothering them until they tested that and improved C++ link time in the 15.5 Visual studio release. The final release of Factorio with all optimisations and link time code generation took 45 minutes to compile and link, and now it takes 3.5 minutes. This sped up our release time quite a bit.

There are still some debts to be finished in 2018, mainly the GUI update, which is actually a huge project. We have very large number of different windows in the game, and if we really want to improve both the looks and the usability, we will have to put a lot of time and thought into it. Also the mini tutorials will have to be finished and few entities will probably be re-designed.

But once all these things are solved, it not only means that we could get out of early access, but also, if we ever decide to add more content to Factorio, having these things finished should pay off by letting us to focus on the new things only instead of having to fix the old ones. Another possibility, is to use the Factorio engine for completely different game or for fast prototyping of crazy ideas. Whatever we decide to do in the future, having polished base seems like an important thing to have.

Almost 6 years of Factorio in numbers
The initial Factorio commit was done 31.3. 2012, so Factorio is in the development for 5 years 9 months.
I did this kind of comparison in fff-88 which was even before the steam release, I hope you don't mind if I compare it with the current state.

Our effort in numbers:
  • In development for 1106 → 2099 days.
  • 88 → 221 public releases.
  • 14 082 → 34 686 commits in the master branch.
  • 204 917 → 465 550 lines of code, 546 339 → 1 258 939 words and 7 693 483 → 17 517 675 characters, this is equivalent to 15 → 35 average books.
  • 20 791 → 56 947 different sprites with 54 114 147 → 336 907 147 non empty pixels.
  • 1492 → 5034 resolved bugs (only counting those reported on our forums).
  • 3027 → 7670 lines in the changelog.
Results in:
  • 56 500 → 341 000 Youtube videos
  • 403 000 → 1 900 000 Google hits of Factorio.
  • 75 146 → 303 773 forum posts
  • 11 704 years of combined playtime played on steam.
  • and finally 74 914 → 1 200 000+ copies sold.

This leads me to different kind of comparisons:
  • 2.7 → 0.42 lines of code per one buyer
  • 12.7 → 16.5 commits per day or
  • 2.7 → 6 Youtube videos per one sprite
  • 2.3 years of playtime per resolved bug report
  • 4 months of playtime per one commit
  • 9.1 days of play for each line of code
  • 18.2 minutes for each pixel
I could go like this for a while :) But mainly, it makes me realize, that making changes, improving things, and fixing even small annoyances in the game is worth it.

I would also like provide the overall graph of commits frequency, some of the releases are quite visible there :)



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