As you already know, in 0.15 we have reworked the science packs and added infinite science. Moreand different science packs make the game a lot more interesting. It reduces the complexity ofblue science (which is great for newer players) while adding complexity later, and you now haveto decide what to research first, especially with the more expensive game modes (which isinteresting for advanced players), and infinite science adds something to do forever in the game.



However, one of my biggest complaints about Factorio always was that the rocket has nopurpose, even though it is being propagated at all the points as the final step of the game. It issaid at the trailer, at the introduction of freeplay, and by being the most advanced research,everything seems like it’s the thing to desire, but when I launched it for the first time and seeingthe victory screen, I was feeling like "And now what...".

For me there is one main reason why Factorio is so awesome and why I can forget myselfplaying until 4 a.m., and that reason is the infinite loop of 'there is always a bottleneck', youalways need to fix something, you have not enough power, or your production of a particularproduct is insufficient etc.



When you launch the rocket, you escape from this loop because it doesn’t lead anywhere. Aswe can see, we have learned to take the rocket as a measurable resource sink to quantify thesize of our factories, which is great, but I think it makes sense to us only because we got usedto it, not because it made sense in the first place, or at least it didn’t to me.

Now when 0.15 adds infinite research, I started to ask myself why would I launch the rocket atall, and I have seen many of you ask similar questions.

To compare the two, the infinite science is also quantifiable as I can see the amount I producedin the production screen, it also has an interesting crafting recipe (rocket parts vs. all sciencepacks together), and it is also an infinite resource sink. The main difference is, the infiniteresearch is actually useful.



This is where the space science comes into play. We now have a space science pack,obtained by launching a rocket. You get 1000 of these science packs per rocket, and everyinfinite research requires these science packs. Such a simple feature, but it closes the infinitegame loop again. But of course in case you want to just launch rockets without worrying aboutscience, you can still do that, just like previously.

We have also added more infinite researches, so now apart from worker robot speed, combatrobot follower count and mining productivity bonus researches, we also have all of thecombative damage upgrades infinite (not shooting speed as that would get ridiculous sooner orlater), however their prices increase exponentially to prevent it from getting too extreme.



The rocket has to have a satellite in order to get the science packs (the rocket has to be ablesend back the discoveries, right?). The rocket silo now has an auto-launch checkbox so you canlaunch them automatically, and the launch is only going to happen when you insert satellite. Soyou can control the inserter with satellite to only launch rockets when you need the sciencepacks automatically through circuit network.

Of course we also added support for mods, so you can define what do you get from sending arocket, and depending on what you put in the rocket - say, if you put a tank into the rocket, youreceive 100 raw fish, because that would make perfect sense.

We can build up on this concept in the future, but for now this already brings a lot of sense tothe game as it is.



As a bonus, here is a album of my factory where I tested the infinite science concept.
There is a great amount of new graphics and high resolution translations of old ones. Thebiggest news is obviously the nuclear power, so let’s have a look at that.



As you can see, the whole process starts with a mining drill and new uranium ore graphics (itglows at night by the way). Since mining uranium requires sulfuric acid, we needed to add anew patch for pipe connection. The acid flows between neighbouring miners, so you only needto bring pipes to the edge ones.

The first step of uranium processing happens at the centrifuge, which creates U-238 and U-235in certain percentages. Most of the time you get a U-238, but sometimes you get a U-235.When you get a U-235, you can turn it into uranium fuel cell which goes to the nuclear reactor.The nuclear reactor heats up and transfers the heat to heat exchangers, optionally via heatpipes when the setup gets bigger. The heat exchanger accepts water and outputs steam whichthen goes to the steam turbines which generate power.



The centrifuge can do a few other processes which are useful for getting more U-235 andre-utilizing burnt out fuel cells into more U-238. Even though it’s one of the most expectedthings, we probably didn’t mention before that you can make uranium ammo and tank shellsfrom U-238, and U-235 can be used to create warheads for rocket launcher missiles whicherase about 50 tile area per shot of anything in the way, including you if you don’t run fastenough.

The steam comes out of the heat exchangers at 500 degrees, which is the maximum a steam turbine canutilize. A steam engine in comparison can only make use of steam up to 165 degrees - which iswhat a normal boiler produces. So if you use a steam turbine with normal boiler, it will work, butthe turbine will have a poor efficiency. And if you use steam engine with heat exchangers, it willwork, but a lot of the heat will be lost for no benefit.



As you already know from earlier, we have also changed the boiler to be 2x3 tiles instead of 1x1which required new graphics. We also added high resolution steam engine to make them gotogether nicely. This also allows for some new designs which is very nice. The ratio of boilers tosteam engines is exactly 1 boiler to 2 steam engines now.

As you already see with the nuclear graphics, they all have their high resolution versions, butwhat else is there?

Currently in early versions of 0.15 you can look forward to the following in high resolution:

• Resources
• Electric mining drill
• Belts, splitters and underground belts
• Pipes and pump
• Rails, rail signals & rail station
• Locomotive, cargo wagon and fluid wagon
• Furnaces
• Assembling machines
• Refinery and chemical plant
• Boiler & steam engine
• Nuclear power graphics - centrifuge, nuclear reactor, heat pipe, heat exchanger, steam
• Steam turbine
• Car
• Programmable speaker

Everything in the following picture except inserters is in high resolution. The high resolution terrain integration is still in progress, so it won't make it to 0.15 right away.



During 0.15 stabilization we will be adding more high resolution graphics, with the aim to doeverything. Let’s see how that goes, but seeing what we already have, we are confident we canget it done sooner or later.

For a long time we have been keeping some placeholder icons and we wanted to replace theskin of the GUI in 0.13 already. Here is how it looks like now.


The changes aren’t massive, but it has a big impact on everything. Because of that, some of ouricons needed changing so that they don’t become less visible. There are also many new iconreplacements for the old awful things like mining drill, laser turret, rail signals, and more. We willlikely tweak it further, but this is what we have for now. The technology tree looks like this.



We have reworked the map colors to make them look nicer and give a little bit more info whatis what.



As you can probably see, it has been a lot of work, and we are very proud of it.The best part is that you will all be able to help us play and test 0.15 this coming Tuesday, so let us know what you think on our forums or I personally am also active on reddit.

As you already know, in 0.15 we have reworked the science packs and added infinite science. Moreand different science packs make the game a lot more interesting. It reduces the complexity ofblue science (which is great for newer players) while adding complexity later, and you now haveto decide what to research first, especially with the more expensive game modes (which isinteresting for advanced players), and infinite science adds something to do forever in the game.



However, one of my biggest complaints about Factorio always was that the rocket has nopurpose, even though it is being propagated at all the points as the final step of the game. It issaid at the trailer, at the introduction of freeplay, and by being the most advanced research,everything seems like it’s the thing to desire, but when I launched it for the first time and seeingthe victory screen, I was feeling like "And now what...".

For me there is one main reason why Factorio is so awesome and why I can forget myselfplaying until 4 a.m., and that reason is the infinite loop of 'there is always a bottleneck', youalways need to fix something, you have not enough power, or your production of a particularproduct is insufficient etc.



When you launch the rocket, you escape from this loop because it doesn’t lead anywhere. Aswe can see, we have learned to take the rocket as a measurable resource sink to quantify thesize of our factories, which is great, but I think it makes sense to us only because we got usedto it, not because it made sense in the first place, or at least it didn’t to me.

Now when 0.15 adds infinite research, I started to ask myself why would I launch the rocket atall, and I have seen many of you ask similar questions.

To compare the two, the infinite science is also quantifiable as I can see the amount I producedin the production screen, it also has an interesting crafting recipe (rocket parts vs. all sciencepacks together), and it is also an infinite resource sink. The main difference is, the infiniteresearch is actually useful.



This is where the space science comes into play. We now have a space science pack,obtained by launching a rocket. You get 1000 of these science packs per rocket, and everyinfinite research requires these science packs. Such a simple feature, but it closes the infinitegame loop again. But of course in case you want to just launch rockets without worrying aboutscience, you can still do that, just like previously.

We have also added more infinite researches, so now apart from worker robot speed, combatrobot follower count and mining productivity bonus researches, we also have all of thecombative damage upgrades infinite (not shooting speed as that would get ridiculous sooner orlater), however their prices increase exponentially to prevent it from getting too extreme.



The rocket has to have a satellite in order to get the science packs (the rocket has to be ablesend back the discoveries, right?). The rocket silo now has an auto-launch checkbox so you canlaunch them automatically, and the launch is only going to happen when you insert satellite. Soyou can control the inserter with satellite to only launch rockets when you need the sciencepacks automatically through circuit network.

Of course we also added support for mods, so you can define what do you get from sending arocket, and depending on what you put in the rocket - say, if you put a tank into the rocket, youreceive 100 raw fish, because that would make perfect sense.

We can build up on this concept in the future, but for now this already brings a lot of sense tothe game as it is.



As a bonus, here is a album of my factory where I tested the infinite science concept.
There is a great amount of new graphics and high resolution translations of old ones. Thebiggest news is obviously the nuclear power, so let’s have a look at that.



As you can see, the whole process starts with a mining drill and new uranium ore graphics (itglows at night by the way). Since mining uranium requires sulfuric acid, we needed to add anew patch for pipe connection. The acid flows between neighbouring miners, so you only needto bring pipes to the edge ones.

The first step of uranium processing happens at the centrifuge, which creates U-238 and U-235in certain percentages. Most of the time you get a U-238, but sometimes you get a U-235.When you get a U-235, you can turn it into uranium fuel cell which goes to the nuclear reactor.The nuclear reactor heats up and transfers the heat to heat exchangers, optionally via heatpipes when the setup gets bigger. The heat exchanger accepts water and outputs steam whichthen goes to the steam turbines which generate power.



The centrifuge can do a few other processes which are useful for getting more U-235 andre-utilizing burnt out fuel cells into more U-238. Even though it’s one of the most expectedthings, we probably didn’t mention before that you can make uranium ammo and tank shellsfrom U-238, and U-235 can be used to create warheads for rocket launcher missiles whicherase about 50 tile area per shot of anything in the way, including you if you don’t run fastenough.

The steam comes out of the heat exchangers at 500 degrees, which is the maximum a steam turbine canutilize. A steam engine in comparison can only make use of steam up to 165 degrees - which iswhat a normal boiler produces. So if you use a steam turbine with normal boiler, it will work, butthe turbine will have a poor efficiency. And if you use steam engine with heat exchangers, it willwork, but a lot of the heat will be lost for no benefit.



As you already know from earlier, we have also changed the boiler to be 2x3 tiles instead of 1x1which required new graphics. We also added high resolution steam engine to make them gotogether nicely. This also allows for some new designs which is very nice. The ratio of boilers tosteam engines is exactly 1 boiler to 2 steam engines now.

As you already see with the nuclear graphics, they all have their high resolution versions, butwhat else is there?

Currently in early versions of 0.15 you can look forward to the following in high resolution:

• Resources
• Electric mining drill
• Belts, splitters and underground belts
• Pipes and pump
• Rails, rail signals & rail station
• Locomotive, cargo wagon and fluid wagon
• Furnaces
• Assembling machines
• Refinery and chemical plant
• Boiler & steam engine
• Nuclear power graphics - centrifuge, nuclear reactor, heat pipe, heat exchanger, steam
• Steam turbine
• Car
• Programmable speaker

Everything in the following picture except inserters is in high resolution. The high resolution terrain integration is still in progress, so it won't make it to 0.15 right away.



During 0.15 stabilization we will be adding more high resolution graphics, with the aim to doeverything. Let’s see how that goes, but seeing what we already have, we are confident we canget it done sooner or later.

For a long time we have been keeping some placeholder icons and we wanted to replace theskin of the GUI in 0.13 already. Here is how it looks like now.


The changes aren’t massive, but it has a big impact on everything. Because of that, some of ouricons needed changing so that they don’t become less visible. There are also many new iconreplacements for the old awful things like mining drill, laser turret, rail signals, and more. We willlikely tweak it further, but this is what we have for now. The technology tree looks like this.



We have reworked the map colors to make them look nicer and give a little bit more info whatis what.



As you can probably see, it has been a lot of work, and we are very proud of it.The best part is that you will all be able to help us play and test 0.15 this coming Tuesday, so let us know what you think on our forums or I personally am also active on reddit.

Hello, another week of tepid weather here, but the work on the final necessities to 0.15.0 continues with full force.

We started a new map on Monday, we wanted to see how the game feels with our new 'marathon' map preset, which (among other things) makes many recipes more expensive.



What may seem like blasphemy to some, the expensive setting also changes a few of the normal recipe ratios, so new designs had to be thought up:



A long time ago we talked about our automated testing in FFF-62, and over the last 2 years and 4 major versions, we've added quite significantly to our suite of tests.

https://youtu.be/erYjMMBXy7A

We have our server constantly running all these tests 24/7, and when something breaks it sends our a sterny worded email to the developers who made the latest commits to the repository. Its sometimes surprisingly how some innocent change can break some wholly unrelated test, but it certainly helps us catch these issues before they make it out the door.

This might be quite a short Friday facts, but we are trying to spend as much time getting things ready for release. If you have any thoughts or feedback, please let us know on our forum

Hello, another week of tepid weather here, but the work on the final necessities to 0.15.0 continues with full force.

We started a new map on Monday, we wanted to see how the game feels with our new 'marathon' map preset, which (among other things) makes many recipes more expensive.



What may seem like blasphemy to some, the expensive setting also changes a few of the normal recipe ratios, so new designs had to be thought up:



A long time ago we talked about our automated testing in FFF-62, and over the last 2 years and 4 major versions, we've added quite significantly to our suite of tests.

https://youtu.be/erYjMMBXy7A

We have our server constantly running all these tests 24/7, and when something breaks it sends our a sterny worded email to the developers who made the latest commits to the repository. Its sometimes surprisingly how some innocent change can break some wholly unrelated test, but it certainly helps us catch these issues before they make it out the door.

This might be quite a short Friday facts, but we are trying to spend as much time getting things ready for release. If you have any thoughts or feedback, please let us know on our forum

Hello, the sunny spring weather seems to have taken a break these last few days after Denis' arrival to the office. His work continues on the belts optimization, as the rest of the team has been playtesting 0.15, as well as closing off remaining minor features on our Trello board.

Internal playtesting kicked off early this week, and it seems we're either doing something right or wrong, as it doesn't seem we are finding many major bugs. Of the ones we've found, most have been fairly easy to solve after initial diagnosis, which is greatly simplified by playing on our internal 'Fast debug' build.

Kovarex has polished up the 'zoom to map' feature mentioned previously, with a card of community suggestions to checkout in the future. There was some choice to make on whether to allow building from the map zoomed in or not, and in the end we decided that building ghosts/bleuprints from the map is an amazing feature. Posila and I finished our first implementation of the mini-tutorials, which are accessed in-game through a simple (for now) Gui:



We also have a new addition to our GFX department, so please everyone give welcome to Ernestas, a talented artist from Lithuania, who has been getting acquainted with us all here in the office. Albert has been digging deeply with Cube into terrain generation fixes, while his work continues on the nuclear reactor model.
We received a lot of community feedback about our proposal for how the nightvision could look. So now after several weeks to think upon the problem, Posila has implemented a new look, with the first use of shaders in the game:



No doubt the art department will still want to apply some finishing touches, but we are happy with how it turned out. We hope the use of shaders could start to add some extra dimension to the way the game looks, and since their processing is done on the GPU, it should have very little impact on performance.

There are still a hundred minor features I could talk about in these FFF posts, but this close to release, I would rather not spoil the surprise. As always, if you have any comments or otherwise, please let us know on our forums.

Hello, the sunny spring weather seems to have taken a break these last few days after Denis' arrival to the office. His work continues on the belts optimization, as the rest of the team has been playtesting 0.15, as well as closing off remaining minor features on our Trello board.

Internal playtesting kicked off early this week, and it seems we're either doing something right or wrong, as it doesn't seem we are finding many major bugs. Of the ones we've found, most have been fairly easy to solve after initial diagnosis, which is greatly simplified by playing on our internal 'Fast debug' build.

Kovarex has polished up the 'zoom to map' feature mentioned previously, with a card of community suggestions to checkout in the future. There was some choice to make on whether to allow building from the map zoomed in or not, and in the end we decided that building ghosts/bleuprints from the map is an amazing feature. Posila and I finished our first implementation of the mini-tutorials, which are accessed in-game through a simple (for now) Gui:



We also have a new addition to our GFX department, so please everyone give welcome to Ernestas, a talented artist from Lithuania, who has been getting acquainted with us all here in the office. Albert has been digging deeply with Cube into terrain generation fixes, while his work continues on the nuclear reactor model.
We received a lot of community feedback about our proposal for how the nightvision could look. So now after several weeks to think upon the problem, Posila has implemented a new look, with the first use of shaders in the game:



No doubt the art department will still want to apply some finishing touches, but we are happy with how it turned out. We hope the use of shaders could start to add some extra dimension to the way the game looks, and since their processing is done on the GPU, it should have very little impact on performance.

There are still a hundred minor features I could talk about in these FFF posts, but this close to release, I would rather not spoil the surprise. As always, if you have any comments or otherwise, please let us know on our forums.

Today, it is exactly 5 years since the initial Factorio commit. As you may, or may not know, the first version was created in java, and it took me (kovarex) a whole 12 days to realize that it is not a good idea, and I switched to C++. As a small celebration I provide the Factorio pre-alpha version 0.1. It is a good reminder of how much the game has moved forward in all directions. The controls are cumbersome, the graphics are funny and glitchy, the GUI is horrible. The campaign has 4 levels, where the last one is quite a challenging defense mission. There are also 2 savegames with one of the first Factorio Factories ever created.



The improvements to how multiplayer works in 0.14 made having an open multiplayer game not out of the question. However this introduced a new problem, in that there is no way to protect yourself from people that just want to ruin the fun. To try to fix those problems I've added 3 new things for 0.15: white-list support, the ability to disable friendly fire, and an input action permissions system.

Factorio handles all player actions and interactions through our system of 'input actions'. The input actions tell the game what the player is trying to do, where and what keys/clicks he is making, and basically all game state interactions are done with input actions. This makes it relatively easy to filter what players can and can't do, by limiting what input actions they can perform, which can now be controlled through the permissions system:



The permissions system is completely optional, and it supports any number of permission groups, allowing server admins to define allowed/disallowed actions for everyone in that group. Before anybody asks: yes you can deny yourself the ability to edit permissions (after confirmation), if for some reason you wanted to do that.

The server console (and RCON) have unrestricted access to edit permissions. So, if you do lock yourself out (I don't recommend you do), you can always get back in through that. Additionally, permissions can be edited through the Lua API since the next logical step would be some automated system to slowly grant players permissions on a public server. The ability to edit permissions through the Lua API is checked so a player with console access can't just give themselves permissions if they don't have the required permissions.

Every so often someone would make a save file built almost exclusively around trains, and run into the same performance problem: when you've got enough trains going, the building and destruction of rail related entities starts to consume so much time that it borders on unplayable. I've known about the performance problems for a while now, but the rail system was one of the few areas I didn't have experience with (knowing how the entire rail system works from a programming perspective).

I decided that during my visit to Prague I'd take the opportunity to extract as much information about the rail system as I could from the rest of the team. That led to HanziQ and I working together for a few days, to the point where we could finally address the problems.

In 0.14 and previous, this is how it would work:

• Build any rail -> tell all trains to re-path if their path is invalid
• Destroy any rail -> tell all trains to re-path if their path is invalid
• Build a train stop -> ...
• Destroy a train stop -> ...
• Do anything related to trains/rails -> tell all trains to re-path if their path is invalid

Obviously that wasn't so great for performance. Instead of starting by fixing the obvious problem, I took advantage of the fact that building any track would cause every train to re-path. With a simple way to benchmark the performance, I set to improving the logic trains use to determine if they need to find a new path, and to optimize the path finding code. After that was done, it was just a matter of building a set of conditions of which trains need to be notified when anything rail related is changed.

Some were simple: when a train stop is destroyed, only the trains currently driving to that stop are affected. Others were a little more complicated: when a rail is destroyed, unless it had a signal, train stop, or connected to two or more rails on opposite sides, nobody needs to know it was destroyed. The end result after all this is now building and managing anything in the rail system for 0.15 has almost no measurable impact on performance.

As always, let us know if you have any thoughts or feedback on our Forum.

Today, it is exactly 5 years since the initial Factorio commit. As you may, or may not know, the first version was created in java, and it took me (kovarex) a whole 12 days to realize that it is not a good idea, and I switched to C++. As a small celebration I provide the Factorio pre-alpha version 0.1. It is a good reminder of how much the game has moved forward in all directions. The controls are cumbersome, the graphics are funny and glitchy, the GUI is horrible. The campaign has 4 levels, where the last one is quite a challenging defense mission. There are also 2 savegames with one of the first Factorio Factories ever created.



The improvements to how multiplayer works in 0.14 made having an open multiplayer game not out of the question. However this introduced a new problem, in that there is no way to protect yourself from people that just want to ruin the fun. To try to fix those problems I've added 3 new things for 0.15: white-list support, the ability to disable friendly fire, and an input action permissions system.

Factorio handles all player actions and interactions through our system of 'input actions'. The input actions tell the game what the player is trying to do, where and what keys/clicks he is making, and basically all game state interactions are done with input actions. This makes it relatively easy to filter what players can and can't do, by limiting what input actions they can perform, which can now be controlled through the permissions system:



The permissions system is completely optional, and it supports any number of permission groups, allowing server admins to define allowed/disallowed actions for everyone in that group. Before anybody asks: yes you can deny yourself the ability to edit permissions (after confirmation), if for some reason you wanted to do that.

The server console (and RCON) have unrestricted access to edit permissions. So, if you do lock yourself out (I don't recommend you do), you can always get back in through that. Additionally, permissions can be edited through the Lua API since the next logical step would be some automated system to slowly grant players permissions on a public server. The ability to edit permissions through the Lua API is checked so a player with console access can't just give themselves permissions if they don't have the required permissions.

Every so often someone would make a save file built almost exclusively around trains, and run into the same performance problem: when you've got enough trains going, the building and destruction of rail related entities starts to consume so much time that it borders on unplayable. I've known about the performance problems for a while now, but the rail system was one of the few areas I didn't have experience with (knowing how the entire rail system works from a programming perspective).

I decided that during my visit to Prague I'd take the opportunity to extract as much information about the rail system as I could from the rest of the team. That led to HanziQ and I working together for a few days, to the point where we could finally address the problems.

In 0.14 and previous, this is how it would work:

• Build any rail -> tell all trains to re-path if their path is invalid
• Destroy any rail -> tell all trains to re-path if their path is invalid
• Build a train stop -> ...
• Destroy a train stop -> ...
• Do anything related to trains/rails -> tell all trains to re-path if their path is invalid

Obviously that wasn't so great for performance. Instead of starting by fixing the obvious problem, I took advantage of the fact that building any track would cause every train to re-path. With a simple way to benchmark the performance, I set to improving the logic trains use to determine if they need to find a new path, and to optimize the path finding code. After that was done, it was just a matter of building a set of conditions of which trains need to be notified when anything rail related is changed.

Some were simple: when a train stop is destroyed, only the trains currently driving to that stop are affected. Others were a little more complicated: when a rail is destroyed, unless it had a signal, train stop, or connected to two or more rails on opposite sides, nobody needs to know it was destroyed. The end result after all this is now building and managing anything in the rail system for 0.15 has almost no measurable impact on performance.

As always, let us know if you have any thoughts or feedback on our Forum.

I saw a lot of discussion where people thought that we are just adding features and delaying 0.15 by that, so I would like to describe the situation. There are several bigger things we wanted to have done for the 0.15 and are not yet ready:

• Transport belt optimization - Which is in the process of finalization
• Pump → fluid wagon connection - The graphics are done, the integration into the game is in progress. It was overall much more complicated than expected.
• Internal GUI rewrite - Which is postponed to 0.16
• Mini-tutorials - We have few example mini tutorials finished, and the integration into the game is in progress
• Nuclear power - Only the graphics of the heat pipes are finished, the rest of the graphics are in the phase of sketching, so less than two weeks is improbable.

Those that don't work on these tasks would have to just wait, so they do smaller tasks. This is why I was doing the map improvements, this is why Rseding is doing the optimizations and map presets etc.

Once everything apart from the nuclear power graphics are done, we will start the playtesting, and we want at least a week of playtesting before considering the experimental release, but it can be more if we encounter some unforeseen problems. The graphics can be integrated just before the release, as it shouldn't introduce new bugs. After the experience with previous release date estimates, all I can say about it is: "We are working on it".

When we are ready to make a release, it will be either on a Monday or a Tuesday, to give ourselves some long working days to bugfix while the reports are fresh. This means we will probably know the Friday beforehand that everything is ready, in which case we will let everyone know in the FFF. To clarify: If you don't hear us mention releasing 0.15, you can rest easy for another week that we aren't going to surprise you.

This is extension of what I did and covered the last time.

More colors
The next step was to work on the map color a little bit. We want to find a good balance between a lot of info provided by the map and colorful chaos. Just adding specific color to a few things (turrets, solar panels, accumulators, different shades of yellow for splitters & underground belts) to make the map much more readable. This is not the definitive version, as the colors might be tweaked, but I can already read the map better:



Turret range option: Optionally viewable as with the other visualizations.


Zoom from map to the world

This took the most time to do, but I like it the most. When you zoom in, at a certain zoom, you just switch from the map view to the game view. We don't want the players to accidentally switch to the map view when playing normally, so it is only applicable when the player is using the map view explicitly. The first obvious problem was, that it would be too strong as you could see everywhere, so we limited this kind of view only to the area covered by radars or other players, the parts not covered still show the map view.

I was afraid of how ugly it would look to combine the game view and the stretched map view, but it actually isn't that bad, and it teaches the players the colors on map as well.





We are considering whether it should be possible or not to build ghosts, blueprints and use deconstruction planner from the map, maybe it could be unlocked by specific research, we might leave further additions like this to 0.16, but it really depends on how long we have to wait for the bigger things to be done.

An extension of the map settings FFF.

We decided to make only the normal and expensive version of recipes and technologies. The easy/simple version would promote the automation even less, and it might even be remotely possible to finish the game by making things mainly by hand crafting, which would push the player the wrong direction. I was experimenting the Expensive recipe costs a little, and it seems that making few vital components, like iron gear wheels, circuits, steel and miners more expensive, might be enough to slow the game down. I personally found it refreshing to not jump through the early game as fast as I'm used to.

To make things more graspable we defined few presets, so when you say that you finished the "death-world" settings, it means something specific.



As always, let us know know you think on our forums.

I saw a lot of discussion where people thought that we are just adding features and delaying 0.15 by that, so I would like to describe the situation. There are several bigger things we wanted to have done for the 0.15 and are not yet ready:

• Transport belt optimization - Which is in the process of finalization
• Pump → fluid wagon connection - The graphics are done, the integration into the game is in progress. It was overall much more complicated than expected.
• Internal GUI rewrite - Which is postponed to 0.16
• Mini-tutorials - We have few example mini tutorials finished, and the integration into the game is in progress
• Nuclear power - Only the graphics of the heat pipes are finished, the rest of the graphics are in the phase of sketching, so less than two weeks is improbable.

Those that don't work on these tasks would have to just wait, so they do smaller tasks. This is why I was doing the map improvements, this is why Rseding is doing the optimizations and map presets etc.

Once everything apart from the nuclear power graphics are done, we will start the playtesting, and we want at least a week of playtesting before considering the experimental release, but it can be more if we encounter some unforeseen problems. The graphics can be integrated just before the release, as it shouldn't introduce new bugs. After the experience with previous release date estimates, all I can say about it is: "We are working on it".

When we are ready to make a release, it will be either on a Monday or a Tuesday, to give ourselves some long working days to bugfix while the reports are fresh. This means we will probably know the Friday beforehand that everything is ready, in which case we will let everyone know in the FFF. To clarify: If you don't hear us mention releasing 0.15, you can rest easy for another week that we aren't going to surprise you.

This is extension of what I did and covered the last time.

More colors
The next step was to work on the map color a little bit. We want to find a good balance between a lot of info provided by the map and colorful chaos. Just adding specific color to a few things (turrets, solar panels, accumulators, different shades of yellow for splitters & underground belts) to make the map much more readable. This is not the definitive version, as the colors might be tweaked, but I can already read the map better:



Turret range option: Optionally viewable as with the other visualizations.


Zoom from map to the world

This took the most time to do, but I like it the most. When you zoom in, at a certain zoom, you just switch from the map view to the game view. We don't want the players to accidentally switch to the map view when playing normally, so it is only applicable when the player is using the map view explicitly. The first obvious problem was, that it would be too strong as you could see everywhere, so we limited this kind of view only to the area covered by radars or other players, the parts not covered still show the map view.

I was afraid of how ugly it would look to combine the game view and the stretched map view, but it actually isn't that bad, and it teaches the players the colors on map as well.





We are considering whether it should be possible or not to build ghosts, blueprints and use deconstruction planner from the map, maybe it could be unlocked by specific research, we might leave further additions like this to 0.16, but it really depends on how long we have to wait for the bigger things to be done.

An extension of the map settings FFF.

We decided to make only the normal and expensive version of recipes and technologies. The easy/simple version would promote the automation even less, and it might even be remotely possible to finish the game by making things mainly by hand crafting, which would push the player the wrong direction. I was experimenting the Expensive recipe costs a little, and it seems that making few vital components, like iron gear wheels, circuits, steel and miners more expensive, might be enough to slow the game down. I personally found it refreshing to not jump through the early game as fast as I'm used to.

To make things more graspable we defined few presets, so when you say that you finished the "death-world" settings, it means something specific.



As always, let us know know you think on our forums.