Hello, this is the last Friday of 2017, and as such, the last Friday facts of this year.
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 :)
- 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.
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.
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:
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.
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:
As always, let us know what you think on our forum.