Twinsen here. As you might have read in Friday Facts #166, we wanted to do some combat balancing. First, to not bring the hopes of everyone up too much, this did not mean a combat overhaul. It means mostly tweaking numbers to make the game more fun and make some of the the weapons more viable. No new entities or new mechanics.

As I was doing the combat balance, it was clear the everyone has their own different opinion of how combat is, how it should be and how to make it "better". It's hard to please everyone, especially when you are just tweaking numbers.To try to objectively evaluate combat I used the following methodology. As the game progresses, the player's power increases through research, but so do the biters(mainly due to evolution factor).So I split the game in 7 sections based on research progress. Each section also has the evolution factor I tested biters will approximately have in an average game.

• Initial - 0 evolution
• Red - 0.1 evolution
• Red+Green - 0.3 evolution
• Red+Green+Military - 0.4 evolution
• Red+Green+Blue+Military - 0.7 evolution
• Red+Green+Blue+Military+High Tech - 0.9 evolution
• Red+Green+Blue+Military+High Tech+Production - 0.99 evolution

Then for each section I tested both offensive combat and defensive combat using the available guns and turrets and tweaked the numbers accordingly. While tweaking the numbers, I keep this in mind (this is not a complete list):

• Fun always wins: I prefer changes that are more fun and less annoying even if it means it could be slightly unbalanced.
• New weapons should be slightly more powerful than old weapons, to incentivize you to experiment. So near the end game, a rocket launcher will be better than the machine gun.
• Destroying biter bases is hard in the beginning and significantly easier toward the end game, to give the sense of combat power progression.
• Defending is not too hard in the beginning. I try not to put a new player in the situation of "you didn't prepare properly, you have to start a new game, because no matter what you do you will get killed". Then throughout the game you have to upgrade your defenses as the biters evolve.

So far, the changelog looks like this. There are many numbers that were tweaked and are not included in this list.

• Player regains health at a much higher rate, but only after being out of combat for 10 seconds.
• Discharge defense equipment pushes back, stuns and damages nearby enemies when activated by the remote.
• Decreased the size of Discharge defense equipment from 3x3 to 2x2.
• Greatly increased the damage of Personal Laser Defense Equipment.
• Flamthrower gun has a minimum range of 3.
• The flames created on ground from the flamethrower significantly increase in duration and damage when more fuel is added to them by firing at the same spot.
• Increased fire resistance of biter bases.
• Increased the health of player non-combat buildings.
• Increased player health from 100 to 250.
• Increased collected amount and effectiveness of Raw Fish.
• Increased the damage, range and health of biters worms.
• Decreased health and resistance of Behemoth biters.
• Doubled the stack size of all ammos.
• Tweaked the cost and crafting time of some ammos.
• Increased the damage of most player ammos. Greatly increased the damage and fire rate of Rockets and Cannon Shells.
• Increased the collision box of Cannon Shells.
• Increased Tank health and resistances.
• Added research for Tank Cannon Shells damage and shooting speed.
• Tweaked research bonuses and added more end-game research for military upgrades.
• Greatly increased the damage of Mines. They also stun nearby enemies when they explode.
• Biters stop following player after 10 sec of not giving or receiving damage if the player is more than 50 tiles away.
• Other minor changes.

As usual, these changes are not final and will probably change to some degree as we playtest more.
There are still many things to be done. We are always talking about more end-game weapons, so don't worry, the combat in the late-game will be even more worry-free.


There is also one thing that we always talked about trying to remove: turret-creep (destroying biters base building turrets closer and closer). This method is very powerful and usually doesn't cost anything. So far I believe that we did not find a simple, fun and fair solution. Ideas include: large power-up times(annoying and also weakens base defense); simply not allowing turrets to be build near biter bases (makes the player feel cheated); underground anti-turret worms (sugar-coated version of the previous idea). With the combat changes that were done I believe there is almost always an option to destroy bases without being forced to use turret-creep.In the end maybe your ingenuity and effort of building all those electric poles should be rewarded; If the player wants to do it that way, why not let him? Let us know what you think.

With Twinsen diving into the deep end in combat, I (Klonan) started work on a new scenario. A staple of the RTS genre is some sort of a tower defense mode, where mobs spawn and move towards a key building the players must defend, so of course we had to give it a shot in Factorio and see if it works. The traditional definition of a tower defense has the mobs follow a maze like path, and they do not attack the players towers. It works really well in these games due to the mob and tower varieties, interesting upgrade systems and styles, but without these systems here, the gameplay would not be too compelling.

So I opted for a more free form Factorio oriented style, that I'm calling the 'Wave defense'. The players will spawn in one corner of a square map, with biters spawning in the opposite. After some time, the biters will begin spawning for a period, and head towards the silo. After this wave, there is a short skippable intermission before the next more powerful wave starts.



At start of each wave, the rocket silo ticks up if progress by 5%, and on wave 20 you will have to launch a satellite to win. Each unit you kill along the way will reward your team with a bounty, which you can use to purchase any number of upgrades, such as turret damage, shooting speed and more.

The testing of the scenario fits in quite nicely with Twinsen's recent combat changes, it will take many hours of playtesting to find a nice balance to how difficult the scenario, especially in multiplayer. Still I am interested if any of you (the community members) had any different ideas about a 'Tower defense esque' level for the game.

So let us know if you have any thoughts and opinions you'd like to share over on our forum

Twinsen here. As you might have read in Friday Facts #166, we wanted to do some combat balancing. First, to not bring the hopes of everyone up too much, this did not mean a combat overhaul. It means mostly tweaking numbers to make the game more fun and make some of the the weapons more viable. No new entities or new mechanics.

As I was doing the combat balance, it was clear the everyone has their own different opinion of how combat is, how it should be and how to make it "better". It's hard to please everyone, especially when you are just tweaking numbers.To try to objectively evaluate combat I used the following methodology. As the game progresses, the player's power increases through research, but so do the biters(mainly due to evolution factor).So I split the game in 7 sections based on research progress. Each section also has the evolution factor I tested biters will approximately have in an average game.

• Initial - 0 evolution
• Red - 0.1 evolution
• Red+Green - 0.3 evolution
• Red+Green+Military - 0.4 evolution
• Red+Green+Blue+Military - 0.7 evolution
• Red+Green+Blue+Military+High Tech - 0.9 evolution
• Red+Green+Blue+Military+High Tech+Production - 0.99 evolution

Then for each section I tested both offensive combat and defensive combat using the available guns and turrets and tweaked the numbers accordingly. While tweaking the numbers, I keep this in mind (this is not a complete list):

• Fun always wins: I prefer changes that are more fun and less annoying even if it means it could be slightly unbalanced.
• New weapons should be slightly more powerful than old weapons, to incentivize you to experiment. So near the end game, a rocket launcher will be better than the machine gun.
• Destroying biter bases is hard in the beginning and significantly easier toward the end game, to give the sense of combat power progression.
• Defending is not too hard in the beginning. I try not to put a new player in the situation of "you didn't prepare properly, you have to start a new game, because no matter what you do you will get killed". Then throughout the game you have to upgrade your defenses as the biters evolve.

So far, the changelog looks like this. There are many numbers that were tweaked and are not included in this list.

• Player regains health at a much higher rate, but only after being out of combat for 10 seconds.
• Discharge defense equipment pushes back, stuns and damages nearby enemies when activated by the remote.
• Decreased the size of Discharge defense equipment from 3x3 to 2x2.
• Greatly increased the damage of Personal Laser Defense Equipment.
• Flamthrower gun has a minimum range of 3.
• The flames created on ground from the flamethrower significantly increase in duration and damage when more fuel is added to them by firing at the same spot.
• Increased fire resistance of biter bases.
• Increased the health of player non-combat buildings.
• Increased player health from 100 to 250.
• Increased collected amount and effectiveness of Raw Fish.
• Increased the damage, range and health of biters worms.
• Decreased health and resistance of Behemoth biters.
• Doubled the stack size of all ammos.
• Tweaked the cost and crafting time of some ammos.
• Increased the damage of most player ammos. Greatly increased the damage and fire rate of Rockets and Cannon Shells.
• Increased the collision box of Cannon Shells.
• Increased Tank health and resistances.
• Added research for Tank Cannon Shells damage and shooting speed.
• Tweaked research bonuses and added more end-game research for military upgrades.
• Greatly increased the damage of Mines. They also stun nearby enemies when they explode.
• Biters stop following player after 10 sec of not giving or receiving damage if the player is more than 50 tiles away.
• Other minor changes.

As usual, these changes are not final and will probably change to some degree as we playtest more.
There are still many things to be done. We are always talking about more end-game weapons, so don't worry, the combat in the late-game will be even more worry-free.


There is also one thing that we always talked about trying to remove: turret-creep (destroying biters base building turrets closer and closer). This method is very powerful and usually doesn't cost anything. So far I believe that we did not find a simple, fun and fair solution. Ideas include: large power-up times(annoying and also weakens base defense); simply not allowing turrets to be build near biter bases (makes the player feel cheated); underground anti-turret worms (sugar-coated version of the previous idea). With the combat changes that were done I believe there is almost always an option to destroy bases without being forced to use turret-creep.In the end maybe your ingenuity and effort of building all those electric poles should be rewarded; If the player wants to do it that way, why not let him? Let us know what you think.

With Twinsen diving into the deep end in combat, I (Klonan) started work on a new scenario. A staple of the RTS genre is some sort of a tower defense mode, where mobs spawn and move towards a key building the players must defend, so of course we had to give it a shot in Factorio and see if it works. The traditional definition of a tower defense has the mobs follow a maze like path, and they do not attack the players towers. It works really well in these games due to the mob and tower varieties, interesting upgrade systems and styles, but without these systems here, the gameplay would not be too compelling.

So I opted for a more free form Factorio oriented style, that I'm calling the 'Wave defense'. The players will spawn in one corner of a square map, with biters spawning in the opposite. After some time, the biters will begin spawning for a period, and head towards the silo. After this wave, there is a short skippable intermission before the next more powerful wave starts.



At start of each wave, the rocket silo ticks up if progress by 5%, and on wave 20 you will have to launch a satellite to win. Each unit you kill along the way will reward your team with a bounty, which you can use to purchase any number of upgrades, such as turret damage, shooting speed and more.

The testing of the scenario fits in quite nicely with Twinsen's recent combat changes, it will take many hours of playtesting to find a nice balance to how difficult the scenario, especially in multiplayer. Still I am interested if any of you (the community members) had any different ideas about a 'Tower defense esque' level for the game.

So let us know if you have any thoughts and opinions you'd like to share over on our forum

As Twinsen continues tweaking the combat, he started to complain about the “green fog” effect that is applied during night when the player’s character has nightvision goggles equipped. Nightvison in 0.14 works in a way that it reduces the darkness of night, and then draws a transparent green overlay. This washes out the colors, reduces contrast, and makes the picture pretty unpleasant to look at.



The first idea was to just make the green overlay be rendered around light sources, to reward players who put lights into their bases, by not making the base look worse with nightvision on. This didn’t look too good, and as we were trying to figure out how to improve it, other developers, especially artists, caught on to what we were doing, and started to provide their own ideas.

Next we tried to darken only the red and blue channels when nightvision is on. This will make the picture green without losing contrast and we can drop the green overlay. We kept “not applying effect onto lighted area” logic and it started to look interesting.


Albert wasn’t happy with the result though, so we continued experimenting. We added a soft green tint to lighted areas, and a bright green glow onto the transition between light and darkness. Then we added white highlights to light sources and it finally started to pleasant to look at.



We will stick with this version for time being, but plan to work on it more. We can’t agree if this change is for better or worse even inside the team. It seems everybody has their own idea about how nightvision effect should look like and what benefits it should provide to players. For example it would be nice to have goggles with greyscale effect that would highlight biters. So maybe heat vision?

Game developers usually boast about what great tools they have developed to help create content for their game. For Factorio so far there exists a single python script for creating sprite sheets, and the in-game map editor for creating maps, for scenarios and the campaign. We don’t have any database of all entities from which we would generate prototype definitions or anything like that.

There has always been a need for some tools to help the artists with the post-production of sprites, and so we have added a developer feature that allows the Factorio engine to reload any sprite sheet within a second of it being changed. Our artists are very excited about this, as they can edit a sprite in Photoshop, save it and immediately see their changes in the game.

Next we plan to add the ability to modify certain prototype values in runtime. This is again mainly intended for artists, but eventually should help balancing various aspects of the game, as we could just open a developer menu and try out several different values in matter of seconds.Hopefully both of these features are also going to be useful to modders, as it should be available to some extent in builds we release to public.

As always, let us know your thoughts and opinion on our forum

As Twinsen continues tweaking the combat, he started to complain about the “green fog” effect that is applied during night when the player’s character has nightvision goggles equipped. Nightvison in 0.14 works in a way that it reduces the darkness of night, and then draws a transparent green overlay. This washes out the colors, reduces contrast, and makes the picture pretty unpleasant to look at.



The first idea was to just make the green overlay be rendered around light sources, to reward players who put lights into their bases, by not making the base look worse with nightvision on. This didn’t look too good, and as we were trying to figure out how to improve it, other developers, especially artists, caught on to what we were doing, and started to provide their own ideas.

Next we tried to darken only the red and blue channels when nightvision is on. This will make the picture green without losing contrast and we can drop the green overlay. We kept “not applying effect onto lighted area” logic and it started to look interesting.


Albert wasn’t happy with the result though, so we continued experimenting. We added a soft green tint to lighted areas, and a bright green glow onto the transition between light and darkness. Then we added white highlights to light sources and it finally started to pleasant to look at.



We will stick with this version for time being, but plan to work on it more. We can’t agree if this change is for better or worse even inside the team. It seems everybody has their own idea about how nightvision effect should look like and what benefits it should provide to players. For example it would be nice to have goggles with greyscale effect that would highlight biters. So maybe heat vision?

Game developers usually boast about what great tools they have developed to help create content for their game. For Factorio so far there exists a single python script for creating sprite sheets, and the in-game map editor for creating maps, for scenarios and the campaign. We don’t have any database of all entities from which we would generate prototype definitions or anything like that.

There has always been a need for some tools to help the artists with the post-production of sprites, and so we have added a developer feature that allows the Factorio engine to reload any sprite sheet within a second of it being changed. Our artists are very excited about this, as they can edit a sprite in Photoshop, save it and immediately see their changes in the game.

Next we plan to add the ability to modify certain prototype values in runtime. This is again mainly intended for artists, but eventually should help balancing various aspects of the game, as we could just open a developer menu and try out several different values in matter of seconds.Hopefully both of these features are also going to be useful to modders, as it should be available to some extent in builds we release to public.

As always, let us know your thoughts and opinion on our forum

Hello,
Denis has joined us for another month here in the office, a small overlap with Rseding who is flying back to the USA next week. With the festive season upon us, Tomas and Kovarex have both taken some time off for a vacation.

As mentioned in a previous FFF, the implementation of the nuclear power will require some changes to the way the boilers currently work. Instead of heating water inside of their fluidboxes, and passing the slightly heated water along, they now output a to a seperate fluidbox. The initial result of this was a unworkable boiler, the small 1x1 size simply didn't play out to make the system intuitive enough.

So the solution was to increase the size of the boiler. The new size is 3x2, significantly larger than before, and the power output and fuel consumption had to be changed to fit this new size. This means we can say goodbye to the old 1-14-10 ratio of before. What is the new ratio? We haven't calculated it, but this is what a 0.15 set up might look like.



Kovarex has also made the first working prototype of the nuclear reactor and its associated mechanics. Each reactor has these 'heat connections', which can hookup connect with the heat pipes and boilers. Heat is than transferred through these connections, where it is used to boil the water into steam. This is all subject to change, but below is how a simple early nuclear power station could be set up.



This design is of course very inefficient, as the steam engines cannot use all the power available in the steam. Later designs would incorporate the steam turbines and cooling towers, for greater efficiency and power output. The heat pipes will also add a layer of complexity to the puzzle, while the incentive towards larger nuclear power blocks adding to the semi-fractal nature of expanding your designs.

Jurek was focused these days on producing a bunch of new rocks and stones with several different sizes, some new bushes and dry trees. One of the best new improvements is the decals system, a new concept that we are testing on this new biome.

The theory behind it is that even having different randomized tile sizes for generating a terrain, the grid still is somehow noticeable there, not to mention the restrictions that tileability produces for achieving the desired result.

So we came out with the idea of using big patches (decals) that are working independently off the grid, so by using them we can get a lot of detail for the terrain, and the artists don't have to be concerned about tileability at all. As a side effect, the square grid pattern gets broken and the feeling of the terrain is much better.

In the preview we have also the new destroyed railroad, something that Vaclav is working on, he prefers not to show it yet because is not 100% finished, but it is very showable, and fits very nicely in the red desert scene.



The most important thing in this preview, is that after several experiments, we decided not to render anymore in normal-resolution from Blender. Instead we are going to render just in high-resolution and re-scale the output bitmaps to normal-resolution using a bilinear interpolation. This gives a better result than a separate render output, it is sharper and saves us quite some time and many headaches. Next for the red desert will be finding the best rules with Kuba for generating the map, and hopefully that will be all. Honestly I (Albert) can't wait for this moment of procedural fine-tuning joy.

As always, let us know your thoughts and opinion on our forum

Hello,
Denis has joined us for another month here in the office, a small overlap with Rseding who is flying back to the USA next week. With the festive season upon us, Tomas and Kovarex have both taken some time off for a vacation.

As mentioned in a previous FFF, the implementation of the nuclear power will require some changes to the way the boilers currently work. Instead of heating water inside of their fluidboxes, and passing the slightly heated water along, they now output a to a seperate fluidbox. The initial result of this was a unworkable boiler, the small 1x1 size simply didn't play out to make the system intuitive enough.

So the solution was to increase the size of the boiler. The new size is 3x2, significantly larger than before, and the power output and fuel consumption had to be changed to fit this new size. This means we can say goodbye to the old 1-14-10 ratio of before. What is the new ratio? We haven't calculated it, but this is what a 0.15 set up might look like.



Kovarex has also made the first working prototype of the nuclear reactor and its associated mechanics. Each reactor has these 'heat connections', which can hookup connect with the heat pipes and boilers. Heat is than transferred through these connections, where it is used to boil the water into steam. This is all subject to change, but below is how a simple early nuclear power station could be set up.



This design is of course very inefficient, as the steam engines cannot use all the power available in the steam. Later designs would incorporate the steam turbines and cooling towers, for greater efficiency and power output. The heat pipes will also add a layer of complexity to the puzzle, while the incentive towards larger nuclear power blocks adding to the semi-fractal nature of expanding your designs.

Jurek was focused these days on producing a bunch of new rocks and stones with several different sizes, some new bushes and dry trees. One of the best new improvements is the decals system, a new concept that we are testing on this new biome.

The theory behind it is that even having different randomized tile sizes for generating a terrain, the grid still is somehow noticeable there, not to mention the restrictions that tileability produces for achieving the desired result.

So we came out with the idea of using big patches (decals) that are working independently off the grid, so by using them we can get a lot of detail for the terrain, and the artists don't have to be concerned about tileability at all. As a side effect, the square grid pattern gets broken and the feeling of the terrain is much better.

In the preview we have also the new destroyed railroad, something that Vaclav is working on, he prefers not to show it yet because is not 100% finished, but it is very showable, and fits very nicely in the red desert scene.



The most important thing in this preview, is that after several experiments, we decided not to render anymore in normal-resolution from Blender. Instead we are going to render just in high-resolution and re-scale the output bitmaps to normal-resolution using a bilinear interpolation. This gives a better result than a separate render output, it is sharper and saves us quite some time and many headaches. Next for the red desert will be finding the best rules with Kuba for generating the map, and hopefully that will be all. Honestly I (Albert) can't wait for this moment of procedural fine-tuning joy.

As always, let us know your thoughts and opinion on our forum

• Fixed that the game could crash when a game disappeared from the matching server before its details were requested. more
  
• Fixed that numpad numbers didn't work for any game controls. more
  
• Fixed crash when merging forces while a player in one the force to be removed was crafting something. more
  
• Fixed game would be stuck in main menu if Join Game on Steam failed for some reason.
  
• Fixed possible save corruption when roboport was destroyed while robot was repairing it. more
  

You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.

• Fixed that the game could crash when a game disappeared from the matching server before its details were requested. more
  
• Fixed that numpad numbers didn't work for any game controls. more
  
• Fixed crash when merging forces while a player in one the force to be removed was crafting something. more
  
• Fixed game would be stuck in main menu if Join Game on Steam failed for some reason.
  
• Fixed possible save corruption when roboport was destroyed while robot was repairing it. more
  

You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.

Hello,the hopefully final 0.14 version was recently released, meanwhile most of the team have been assigned their major tasks for 0.15.

One of the tasks I picked up was to work on the long overdue combat balance. We identified some of the major problem areas. The most pressing issue is that many of the guns and ammo in the game are too underwhelming for their price, and others are completely useless. One example which clearly stands out if the rocket launcher ammo, rockets and explosive rockets. They cost quite a lot in terms of resources, and the time to set up their production. In combat, they are less effective then their cheaper counterparts, such as the flamethrower.

To illustrate the problem, Twinsen worked on his highly scientific graph of the current combat system, with the X and Y axis representing the Elapsed time, and Power respectively.



After some discussion for some different approaches, without much in the way of solid agreement, it was decided that we need to do some more testing. To ease this process I wrote a small internal mod that will allow us to quickly set up some consistent conditions, and see in a reliable and semi-deterministic way, what sort of effect even the smallest changes would have.



This will hopefully help us collect some solid comparisons for how the combat changes and evolves as the game goes onward. For now I only have a shortlist of what we are trying to accomplish:

• Nerf turret creeping
  
• Generally make the mid-game combat better
  
• Bring things more in line with one another in terms of damage and utility
  
• Make the biters less of an irritant, but still a threat

Community feedback will be really important for us on this topic, so please let us know your thoughts.

Steam has recently announced their Steam award nominations , and there are several categories you can nominate any game for. For example the "Just 5 more minutes" is for the games that keep you playing long long into the night. We think it is a really great idea, allowing the steam community to nominate titles in this way, so be sure to vote for your favorite games.

We had to include this week the absolutely spectacular combinator display by DaveMcW: https://youtu.be/mgfwwqwxdxY
If you like to read more about his creation, you can read his thread on the forum, or even read the recent PC gamer article about it. This player also proved to be a good chance to test the circuit network optimizations in 0.15, and in comparison to 0.14, it runs about 18x faster.

As always, let us know your thoughts and opinion on our forum

Hello,the hopefully final 0.14 version was recently released, meanwhile most of the team have been assigned their major tasks for 0.15.

One of the tasks I picked up was to work on the long overdue combat balance. We identified some of the major problem areas. The most pressing issue is that many of the guns and ammo in the game are too underwhelming for their price, and others are completely useless. One example which clearly stands out if the rocket launcher ammo, rockets and explosive rockets. They cost quite a lot in terms of resources, and the time to set up their production. In combat, they are less effective then their cheaper counterparts, such as the flamethrower.

To illustrate the problem, Twinsen worked on his highly scientific graph of the current combat system, with the X and Y axis representing the Elapsed time, and Power respectively.



After some discussion for some different approaches, without much in the way of solid agreement, it was decided that we need to do some more testing. To ease this process I wrote a small internal mod that will allow us to quickly set up some consistent conditions, and see in a reliable and semi-deterministic way, what sort of effect even the smallest changes would have.



This will hopefully help us collect some solid comparisons for how the combat changes and evolves as the game goes onward. For now I only have a shortlist of what we are trying to accomplish:

• Nerf turret creeping
  
• Generally make the mid-game combat better
  
• Bring things more in line with one another in terms of damage and utility
  
• Make the biters less of an irritant, but still a threat

Community feedback will be really important for us on this topic, so please let us know your thoughts.

Steam has recently announced their Steam award nominations , and there are several categories you can nominate any game for. For example the "Just 5 more minutes" is for the games that keep you playing long long into the night. We think it is a really great idea, allowing the steam community to nominate titles in this way, so be sure to vote for your favorite games.

We had to include this week the absolutely spectacular combinator display by DaveMcW: https://youtu.be/mgfwwqwxdxY
If you like to read more about his creation, you can read his thread on the forum, or even read the recent PC gamer article about it. This player also proved to be a good chance to test the circuit network optimizations in 0.15, and in comparison to 0.14, it runs about 18x faster.

As always, let us know your thoughts and opinion on our forum