Hello!

The prototyping of the nuclear power is 90% complete. Some parts of the planned stuff like cooling towers and closed water cycle were dropped. The main reason is that the jump the player needs to do when he wants to switch to the nuclear power is big enough already. The secondary goal is to not get too megalomaniac as there are lot of things our graphics department needs to handle for 0.15 already. We can always add these options later if we want to.

I would like to make clear, that all the nuclear related graphics on these pictures are just a placeholders (made by me), the proper graphics will be done later.

The first part of the process is mining of the uranium, which will be done exactly the same way as any other resource.



The uranium processing requires a new entity called centrifuge, it uses 10 ores to create Uranium 238 and Uranium 235. The ratio is set to be as in reality, which means, the Uranium 235 (The better one) has only 0.7% probability.

The uranium 238 itself is not enough to make the nuclear fuel, so it needs to be mixed with 235 again, but in bigger ratio than it had in the ore, specifically 5% of Uranium 235 needs to be in the mix.

There are different ways to handle the problem of leftovers of Uranium 238 in the real life, but to keep things from getting too complicated, the Factorio player invented the "Kovarex enrichment process", which is able to solve this problem.



Once the nuclear fuel is prepared, it can be inserted into the nuclear reactor, the most simple setup is one reactor with 4 boilers.



For every neighbour reactor, there is 100% energy production bonus with the same usage of fuel. This means that 2 connected reactors are more efficient and powerful, but its heat can't be fully used without the heat pipes (the red pipe placeholder), as each reactor needs 8 boilers to be connected to it in this configuration.



The more nuclear reactors connected, the more complex it becomes:



At this moment, there is no danger of the reactor meltdown, there is just maximum temperature of the reactor and the rest is wasted. We might add some risk into the reactors, but we might as well leave it as it is.

One of the new researches in 0.15 is the mining productivity research. It is infinite and every level adds 2% bonus to the mined resources, similar to the way the productivity modules work. Its price increases linearly so its rate of return increases as well.



It helps to greatly diminish the need to erase and build mines too often in bigger late game factories.

We are looking for an experienced reinforcement to our programming team, who would be working mostly on Factorio Mac OS X platform. If you have strong experience in this field and love challenges, you can find more information on our website.

https://www.factorio.com/job/senio-game-developer

As you might or might not know, Starcraft was always one of my favorite games. I spent way more time with it than I would like to admit.
Some time ago, long before I started working on Factorio, I started the bwapi project which provides C++ api to access the starcraft data (units, players, map etc.) and allows to control the units.



I didn't do anything with that for several years, and it lived its own life in the meantime, there are people writing ai as part of the university courses or just for fun and competition. There are tournaments of the AI bots every year since 2011, and the most amazing: Server that runs the bot battles 24/7 and streams it online at https://www.twitch.tv/certicky. They even use custom Module that automatically moves the screen around to show important parts of the map as the game runs, this is the true automation spirit!

Why am I writing this? Well I'm working on Factorio for almost 5 years now and I need a hobby side project, and writing the starcraft AI is perfect for it. It is fun, complex and it is automation! So if you want to compete with my future bot and the other 45 bot programmers, you are welcome.

And as always let us know what you think on our forums.

Hello!

The prototyping of the nuclear power is 90% complete. Some parts of the planned stuff like cooling towers and closed water cycle were dropped. The main reason is that the jump the player needs to do when he wants to switch to the nuclear power is big enough already. The secondary goal is to not get too megalomaniac as there are lot of things our graphics department needs to handle for 0.15 already. We can always add these options later if we want to.

I would like to make clear, that all the nuclear related graphics on these pictures are just a placeholders (made by me), the proper graphics will be done later.

The first part of the process is mining of the uranium, which will be done exactly the same way as any other resource.



The uranium processing requires a new entity called centrifuge, it uses 10 ores to create Uranium 238 and Uranium 235. The ratio is set to be as in reality, which means, the Uranium 235 (The better one) has only 0.7% probability.

The uranium 238 itself is not enough to make the nuclear fuel, so it needs to be mixed with 235 again, but in bigger ratio than it had in the ore, specifically 5% of Uranium 235 needs to be in the mix.

There are different ways to handle the problem of leftovers of Uranium 238 in the real life, but to keep things from getting too complicated, the Factorio player invented the "Kovarex enrichment process", which is able to solve this problem.



Once the nuclear fuel is prepared, it can be inserted into the nuclear reactor, the most simple setup is one reactor with 4 boilers.



For every neighbour reactor, there is 100% energy production bonus with the same usage of fuel. This means that 2 connected reactors are more efficient and powerful, but its heat can't be fully used without the heat pipes (the red pipe placeholder), as each reactor needs 8 boilers to be connected to it in this configuration.



The more nuclear reactors connected, the more complex it becomes:



At this moment, there is no danger of the reactor meltdown, there is just maximum temperature of the reactor and the rest is wasted. We might add some risk into the reactors, but we might as well leave it as it is.

One of the new researches in 0.15 is the mining productivity research. It is infinite and every level adds 2% bonus to the mined resources, similar to the way the productivity modules work. Its price increases linearly so its rate of return increases as well.



It helps to greatly diminish the need to erase and build mines too often in bigger late game factories.

We are looking for an experienced reinforcement to our programming team, who would be working mostly on Factorio Mac OS X platform. If you have strong experience in this field and love challenges, you can find more information on our website.

https://www.factorio.com/job/senio-game-developer

As you might or might not know, Starcraft was always one of my favorite games. I spent way more time with it than I would like to admit.
Some time ago, long before I started working on Factorio, I started the bwapi project which provides C++ api to access the starcraft data (units, players, map etc.) and allows to control the units.



I didn't do anything with that for several years, and it lived its own life in the meantime, there are people writing ai as part of the university courses or just for fun and competition. There are tournaments of the AI bots every year since 2011, and the most amazing: Server that runs the bot battles 24/7 and streams it online at https://www.twitch.tv/certicky. They even use custom Module that automatically moves the screen around to show important parts of the map as the game runs, this is the true automation spirit!

Why am I writing this? Well I'm working on Factorio for almost 5 years now and I need a hobby side project, and writing the starcraft AI is perfect for it. It is fun, complex and it is automation! So if you want to compete with my future bot and the other 45 bot programmers, you are welcome.

And as always let us know what you think on our forums.

From time to time there is some confusion inside the team about how sprites are blended with the background when rendering, and what kind of effects we are able to achieve by tinting the sprites. So I (Posila) have decided to write up a few paragraphs about how alpha blending works (not only in Factorio), and what it means when someone talks about pre-multiplied alpha.

When the GPU it figuring out what color it should draw on a particular pixel position, it runs a blending operation on just the computed pixel color and original color in the render target. There are several common blending operation modes (additive, multiplicative, overwrite, etc.), but the most common one used in Factorio is alpha blending. It calculates the resulting color using following equation (usually the new color is called 'source' and the background color that is being overwritten is called 'destination'):

You can easily see that a source with alpha 0 will be fully transparent and the one with alpha 1 will be fully opaque.

In games it is common to use a pre-multiplied alpha, which means the color channels of textures are stored in memory being already pre-multiplied by the alpha channel. Alpha blending with pre-multiplied alpha uses a simplified equation:

Besides a slight performance gain from the GPU not having to do bunch of multiplication all the time, this equation allow us to do some extra effects we couldn't do without pre-multiplied alpha.

Factorio renders sprites as colored polygons with texture. We usually refer to the color of a polygon as the 'tint', and every pixel of a sprite is multiplied with its tint. This is useful mainly for color masks, for example the diesel locomotive has a grayscale color mask which is tinted by the color it has set. Tints should have a pre-multiplied alpha too, but they don't have to, so we can use it to lie about the colors and alpha to the GPU. For example if we use tint {r=1,g=1,b=1,a=0} we can simplify previous equation even further and we get additive blending:

This is great because that means we can switch between alpha and additive blending without having to change the blending state in graphics API, which would break sprite batching and result in an increase in the CPU cost of rendering.

For some effects we use a tint with alpha between 0 and 1 heavily. This makes the result appear to be a combination of additive and alpha blending. For example, fire would eventually blend into a single solid color with pure additive blending, or would not look like it is emitting light with pure alpha blending. By using tint (1, 1, 1, 0.35) on the flame sprites, the brightness of overlapping flames adds up partially, but the flames don't completely lose their details. The same trick is used for smoke.

Textures with pre-multiplied alpha also produce better results in texture filtering, which is probably the main reason why they are so widely used in the videogame industry.

Hello! Since I (V453000) last wrote the FFF about rails, I have spent a lot more time to actually work on them further. Just finishing the rails to the current state was a lot of work, and since the new angle of ties broke train signals pretty badly, it was a good time to make these in high resolution as well.

Per usual, as I started digging into it deeper and deeper, I discovered more and more problems like the inconsistent order of sprites, newly appearing issues with sprite drawing (the normal resolution sprites simply didn't show it, but in high resolution old issues become visible), or ridiculous problems like straight rail having different amount of ties in vertical and horizontal, so the chain signal metal plate wouldn't fit them.

Slowly but surely I went over all of the problems, the next mountain to climb was the train stop - since rail sizes changed, the train stop wouldn't fit the new rails anymore. Apart from that, the train stop is from a time when we made high resolution sprites differently, more and more reasons to do it as soon as possible.

There weren't as many unexpected problems as with the signals, just a legion of super specific layering cases, which were probably solved wrongly in the previous version.

There are probably going to be some small changes, but here you can see a little preview:

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

From time to time there is some confusion inside the team about how sprites are blended with the background when rendering, and what kind of effects we are able to achieve by tinting the sprites. So I (Posila) have decided to write up a few paragraphs about how alpha blending works (not only in Factorio), and what it means when someone talks about pre-multiplied alpha.

When the GPU it figuring out what color it should draw on a particular pixel position, it runs a blending operation on just the computed pixel color and original color in the render target. There are several common blending operation modes (additive, multiplicative, overwrite, etc.), but the most common one used in Factorio is alpha blending. It calculates the resulting color using following equation (usually the new color is called 'source' and the background color that is being overwritten is called 'destination'):

You can easily see that a source with alpha 0 will be fully transparent and the one with alpha 1 will be fully opaque.

In games it is common to use a pre-multiplied alpha, which means the color channels of textures are stored in memory being already pre-multiplied by the alpha channel. Alpha blending with pre-multiplied alpha uses a simplified equation:

Besides a slight performance gain from the GPU not having to do bunch of multiplication all the time, this equation allow us to do some extra effects we couldn't do without pre-multiplied alpha.

Factorio renders sprites as colored polygons with texture. We usually refer to the color of a polygon as the 'tint', and every pixel of a sprite is multiplied with its tint. This is useful mainly for color masks, for example the diesel locomotive has a grayscale color mask which is tinted by the color it has set. Tints should have a pre-multiplied alpha too, but they don't have to, so we can use it to lie about the colors and alpha to the GPU. For example if we use tint {r=1,g=1,b=1,a=0} we can simplify previous equation even further and we get additive blending:

This is great because that means we can switch between alpha and additive blending without having to change the blending state in graphics API, which would break sprite batching and result in an increase in the CPU cost of rendering.

For some effects we use a tint with alpha between 0 and 1 heavily. This makes the result appear to be a combination of additive and alpha blending. For example, fire would eventually blend into a single solid color with pure additive blending, or would not look like it is emitting light with pure alpha blending. By using tint (1, 1, 1, 0.35) on the flame sprites, the brightness of overlapping flames adds up partially, but the flames don't completely lose their details. The same trick is used for smoke.

Textures with pre-multiplied alpha also produce better results in texture filtering, which is probably the main reason why they are so widely used in the videogame industry.

Hello! Since I (V453000) last wrote the FFF about rails, I have spent a lot more time to actually work on them further. Just finishing the rails to the current state was a lot of work, and since the new angle of ties broke train signals pretty badly, it was a good time to make these in high resolution as well.

Per usual, as I started digging into it deeper and deeper, I discovered more and more problems like the inconsistent order of sprites, newly appearing issues with sprite drawing (the normal resolution sprites simply didn't show it, but in high resolution old issues become visible), or ridiculous problems like straight rail having different amount of ties in vertical and horizontal, so the chain signal metal plate wouldn't fit them.

Slowly but surely I went over all of the problems, the next mountain to climb was the train stop - since rail sizes changed, the train stop wouldn't fit the new rails anymore. Apart from that, the train stop is from a time when we made high resolution sprites differently, more and more reasons to do it as soon as possible.

There weren't as many unexpected problems as with the signals, just a legion of super specific layering cases, which were probably solved wrongly in the previous version.

There are probably going to be some small changes, but here you can see a little preview:

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

Hello, It has been very quiet in the office this week, the calm twilight between Christmas and the New year.

Its not much of an exaggeration to say that the steam launch was the biggest event in Factorio history. The many months of preparation and research really came together really well at the end of February, and with the great support from our fans, we managed to top the steam charts for several weeks after launch. To put our success in short terms, 85% of all Factorio sales have taken place in the last 12 months. We're not quite there, but we will definitely have a big celebration when we reach 1 million.

Many months past after steam before our next big landmark. Along the way towards a 0.13 release, and with renewed confidence in the project, we looked at expanding the development team once again. To give a summary of our reinforcements, we welcome Honza and Denis to the C++ side, Jurek and Norbert to the GFX department, and Mishka and Jitka to reinforce me in the Support department. We've also recruited two contractors, one to help with Python related tasks, and the other to work on the new theme art.

0.13 was the largest update we've ever released, and it came at a time when we have the largest number of active players in Factorio history. After launch we had a flurry of reports of broken steam linking, troublesome multiplayer, and a nice list of bugs too. We had been preparing a long time for this, and with our full attention on the pesky bugs, it was not long before we had them in full retreat (more info). Soon though the dust had settled, and with the first waves of bug reports over, we set a good pace of further bugfix updates until it was stable just 2 months later.

Kovarex's displeasure with the multiplayer was sparked into action when he saw the MangledPork MP stream. You can read the chronicle of the multiplayer rewrite if you missed it: part 1, part 2. With the new multiplayer complete, we released a small major update, 0.14. This did not add many new features, but still took a lot of time to bugfix and make stable. Up until a few weeks ago, this was our main priority. Now at the end of the year, we are making great progress on 0.15.

There was a recent article on PCGamesN about fraud, grey-market resellers and what it means for all of us. After our steam release we experienced much of the same issues as many other indie developers and publishers in these regards, so I'd like to explain the problem, our experience, and some advice for any others.

In short the problem is fraud, and the process goes like this:

• A purchase is made on our website using a stolen credit card, hacked paypal etc.
• The purchaser sells the key on the grey market within a couple of days.
• Some weeks later the owner of the credit card notices, and issues a chargeback to us.

In many cases these people use a automated bot to deal with automatically purchasing the game and trying all of details in their credit card database, and then posting these keys to these 3rd party websites. We only saw this fraud happening for us after our steam release, because the real money is in selling steam keys - not many people care about website keys. On our side, the cost is very large, each chargeback costs roughly $20 in fines, effectively a negative sale, and we were seeing upwards of 10% chargebacks on our website transactions. Also each chargeback notice had to be handled on a case-by-case basis, at one point I was spending 12 or more hours a week dealing with individual purchases.

A common saying I hear is that this isn't a problem, because 'The devs just revoke the keys', well that simply isn't true, we don't get notice of a fraudulent payment right away, it can take upwards of 8 weeks for the chargeback to be issued, at which time the key is obviously going to be already sold for profit and forgotten. We still revoke these keys, often to the dismay of the purchaser.

So an easy solution would be to stop offering steam keys, the typical effect of some people ruining it for everyone else, but we didn't want to immediately go down that route. First we tried to add additional 'hassle' for these people. We limited transactions to 2 for each credit card, we tightened up the checks our payment provider offered, and we implemented the steam linking. Each stage of this was only effective for a short period of time, before inevitably the fraudsters adapted to the new circumstances, and our changes were circumvented.

After some research, we switched from processing payments through braintree and paypal, and instead implemented the incredible Humble widget. Specifically Humble widget has a built in fraud prevention, which completely stopped all the chargebacks we were seeing. I highly recommend the Humble widget for anybody looking to process payments on their own website.

In the end this fraudulent activity is only beneficial to the middlemen, in this case the fraudster and the 3rd party marketplace. For the developers, at best they are receiving the price of a normal purchase, and at worst they are charged for the privilege of being defrauded. From the consumer perspective its a bit more difficult, you receive the game for a lower cost, but run the risk of the purchase being revoked.

In summary of all this, I want to list the safe and secure ways of purchasing our game:

• Our webpage through the humble widget.
• Through Steam
• On GOG
• On the Humble store

If you purchase the game through any of these sites and you have any problem, please email in to support[at]factorio.com and we can help you out.

To break up what is otherwise a large wall of text, I have a small preview of a 0.15 feature - the kill statistics:



All in all its been a pretty good year for us here at Factorio. We have a lot of plans for our future, but as always, we listen to you, our community, for a lot of feedback on our direction. So drop in and give us your thoughts on our forum.

Hello, It has been very quiet in the office this week, the calm twilight between Christmas and the New year.

Its not much of an exaggeration to say that the steam launch was the biggest event in Factorio history. The many months of preparation and research really came together really well at the end of February, and with the great support from our fans, we managed to top the steam charts for several weeks after launch. To put our success in short terms, 85% of all Factorio sales have taken place in the last 12 months. We're not quite there, but we will definitely have a big celebration when we reach 1 million.

Many months past after steam before our next big landmark. Along the way towards a 0.13 release, and with renewed confidence in the project, we looked at expanding the development team once again. To give a summary of our reinforcements, we welcome Honza and Denis to the C++ side, Jurek and Norbert to the GFX department, and Mishka and Jitka to reinforce me in the Support department. We've also recruited two contractors, one to help with Python related tasks, and the other to work on the new theme art.

0.13 was the largest update we've ever released, and it came at a time when we have the largest number of active players in Factorio history. After launch we had a flurry of reports of broken steam linking, troublesome multiplayer, and a nice list of bugs too. We had been preparing a long time for this, and with our full attention on the pesky bugs, it was not long before we had them in full retreat (more info). Soon though the dust had settled, and with the first waves of bug reports over, we set a good pace of further bugfix updates until it was stable just 2 months later.

Kovarex's displeasure with the multiplayer was sparked into action when he saw the MangledPork MP stream. You can read the chronicle of the multiplayer rewrite if you missed it: part 1, part 2. With the new multiplayer complete, we released a small major update, 0.14. This did not add many new features, but still took a lot of time to bugfix and make stable. Up until a few weeks ago, this was our main priority. Now at the end of the year, we are making great progress on 0.15.

There was a recent article on PCGamesN about fraud, grey-market resellers and what it means for all of us. After our steam release we experienced much of the same issues as many other indie developers and publishers in these regards, so I'd like to explain the problem, our experience, and some advice for any others.

In short the problem is fraud, and the process goes like this:

• A purchase is made on our website using a stolen credit card, hacked paypal etc.
• The purchaser sells the key on the grey market within a couple of days.
• Some weeks later the owner of the credit card notices, and issues a chargeback to us.

In many cases these people use a automated bot to deal with automatically purchasing the game and trying all of details in their credit card database, and then posting these keys to these 3rd party websites. We only saw this fraud happening for us after our steam release, because the real money is in selling steam keys - not many people care about website keys. On our side, the cost is very large, each chargeback costs roughly $20 in fines, effectively a negative sale, and we were seeing upwards of 10% chargebacks on our website transactions. Also each chargeback notice had to be handled on a case-by-case basis, at one point I was spending 12 or more hours a week dealing with individual purchases.

A common saying I hear is that this isn't a problem, because 'The devs just revoke the keys', well that simply isn't true, we don't get notice of a fraudulent payment right away, it can take upwards of 8 weeks for the chargeback to be issued, at which time the key is obviously going to be already sold for profit and forgotten. We still revoke these keys, often to the dismay of the purchaser.

So an easy solution would be to stop offering steam keys, the typical effect of some people ruining it for everyone else, but we didn't want to immediately go down that route. First we tried to add additional 'hassle' for these people. We limited transactions to 2 for each credit card, we tightened up the checks our payment provider offered, and we implemented the steam linking. Each stage of this was only effective for a short period of time, before inevitably the fraudsters adapted to the new circumstances, and our changes were circumvented.

After some research, we switched from processing payments through braintree and paypal, and instead implemented the incredible Humble widget. Specifically Humble widget has a built in fraud prevention, which completely stopped all the chargebacks we were seeing. I highly recommend the Humble widget for anybody looking to process payments on their own website.

In the end this fraudulent activity is only beneficial to the middlemen, in this case the fraudster and the 3rd party marketplace. For the developers, at best they are receiving the price of a normal purchase, and at worst they are charged for the privilege of being defrauded. From the consumer perspective its a bit more difficult, you receive the game for a lower cost, but run the risk of the purchase being revoked.

In summary of all this, I want to list the safe and secure ways of purchasing our game:

• Our webpage through the humble widget.
• Through Steam
• On GOG
• On the Humble store

If you purchase the game through any of these sites and you have any problem, please email in to support[at]factorio.com and we can help you out.

To break up what is otherwise a large wall of text, I have a small preview of a 0.15 feature - the kill statistics:



All in all its been a pretty good year for us here at Factorio. We have a lot of plans for our future, but as always, we listen to you, our community, for a lot of feedback on our direction. So drop in and give us your thoughts on our forum.

Hello. With Christmas nearly upon us, life in the office has slowed down nearly to the point of complete hibernation. But we still bring you your scheduled programme to give you something to look forward to in the next year.

For the past few weeks, I've been working on our shiny new blueprint library. We already introduced the library in FFF 161, but to briefly recapitulate: The blueprint library is a place for you to keep your blueprints, and it does two things for you:

• Blueprints that you save in your library are saved on your computer, and when you load a new save, those blueprints are still available in your library.
• In multiplayer games players can see each others blueprints and can exchange them easily.

My task with the library is to work on the GUI to make it nice and easy to use. Even though slpwnd said in FFF 161 that the UI is “(hopefully) intuitive to work with” – my initial reaction to the GUI was that it was a cruel and unusual punishment for our users.

One of my biggest gripes was that you had to open the blueprint and then click a button in order to copy it to the library. Getting a blueprint out was a similar process – open it, press a button and you get a blueprint item. On a certain level this made sense – items in the library are not items but rather special records – special in a way that they can be saved on the disk or sent over the network in multiplayer. From a UI point of view, however, it didn't make much sense.

With a bit of work, we've managed to make it so that you can simply move a blueprint from the library window into your hotbar like you would any other item. Converting the blueprint record into a blueprint item is handled mostly transparently.



This wasn't a completely trivial task (as if anything ever is): When copying ablueprint out of the library into your inventory, it might be necessary toactually download the blueprint from the player who owns the blueprint – andthat download can take some time. Our hope is that for most blueprints, the download time won't be much, so the download will be able to complete by thetime the user moves the icon over its destination. For big blueprints, however,this might be a problem. This problem is currently left unsolved – the libraryis very much a work in progress at the current time – but it's likely that we'll either display a progress bar in some corner of the screen, or we'll allow the user to drop the item, but grey it out and display a progress bar over it.

The library window itself has received a bit of a redesign since the last time we showed it in an FFF. Here is the current look of the library:



One of the changes is that it displays the blueprint name under its icon. Didyou know you could rename blueprints? You can, even in 0.14. Naming blueprintswill be very useful with the library, as you can stuff only so much informationinto the preview icon to help you remember which blueprint is which.

Another big change is that we changed the library to a two-panel window. On theright, you can see all of your blueprints – these are the ones that are saved onyour disk and follow you from save to save. They are also automatically shared with others in an MP game. The left panel houses other players' blueprints, and it's there you'll be able to get someone else's blueprint from.

A topic of great debate was what to do with the “Game Blueprints” section inorder to make it easy to understand what it's for and how it works. Game Blueprints are blueprints associated with the save itself – they are useful forsave-specific blueprints that you don't want to drag along with you to every save you play. They are also useful for server-specific setups: When a new player joins an MP game, they can be directed to grab blueprints from this section, rather than being told to hunt them from various other players (who may not even be on at the time!).

I'm still not completely convinced that this is the correct place for Game Blueprints to be. Game Blueprints are somewhat special in that they are tied to a specific save, and in this sense, they don't belong to the left panel. However, introducing a third panel would make the window too wide in my opinion. The interface is still very much work in progress, though, and perhaps we'll figure out an even better way to do it soon.

Seeing how much of a struggle a handful of GUI windows can mean for us, we've been looking for a UI and UX designer. And as a bit of an early Christmas gift,we actually found one! Say hello to Norbert, our official GUI guy.

Norbert is starting for real in January, but he has already spent a week with us. During his week with us he was mostly getting to grips with the rest of the team, but even so he managed to come up with an improved design for one of our GUIs – the blueprint preview GUI.



This is the window you see when you first create a blueprint, or when you open a blueprint item by right-clicking it. it really is the same as it always was, but rearranged.

Remember how I told you earlier in this article you could rename blueprints? In0.14, there is an icon next to the “Blueprint” title that looks like a refresh button. That's how you rename it. Maybe it should not have taken a UI designer to tell us that that was the wrong icon for the task, but at least someone finally told us.

Another point Norbert made was that the old GUI didn't make it entirely clear that you could select which icons would show up on the blueprint item in your inventory. And while we're at it, why not make the preview icon larger so you can see the icons better?

Like everything else, even this GUI is still a work in progress – the annoyingly green tick mark icon is my own creation – Albert will make it look good once he gets around to it, don't you worry. Still, I hope you will appreciate the improvements being done, and maybe Factorio's GUI will be less quirky one day.

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

Hello. With Christmas nearly upon us, life in the office has slowed down nearly to the point of complete hibernation. But we still bring you your scheduled programme to give you something to look forward to in the next year.

For the past few weeks, I've been working on our shiny new blueprint library. We already introduced the library in FFF 161, but to briefly recapitulate: The blueprint library is a place for you to keep your blueprints, and it does two things for you:

• Blueprints that you save in your library are saved on your computer, and when you load a new save, those blueprints are still available in your library.
• In multiplayer games players can see each others blueprints and can exchange them easily.

My task with the library is to work on the GUI to make it nice and easy to use. Even though slpwnd said in FFF 161 that the UI is “(hopefully) intuitive to work with” – my initial reaction to the GUI was that it was a cruel and unusual punishment for our users.

One of my biggest gripes was that you had to open the blueprint and then click a button in order to copy it to the library. Getting a blueprint out was a similar process – open it, press a button and you get a blueprint item. On a certain level this made sense – items in the library are not items but rather special records – special in a way that they can be saved on the disk or sent over the network in multiplayer. From a UI point of view, however, it didn't make much sense.

With a bit of work, we've managed to make it so that you can simply move a blueprint from the library window into your hotbar like you would any other item. Converting the blueprint record into a blueprint item is handled mostly transparently.



This wasn't a completely trivial task (as if anything ever is): When copying ablueprint out of the library into your inventory, it might be necessary toactually download the blueprint from the player who owns the blueprint – andthat download can take some time. Our hope is that for most blueprints, the download time won't be much, so the download will be able to complete by thetime the user moves the icon over its destination. For big blueprints, however,this might be a problem. This problem is currently left unsolved – the libraryis very much a work in progress at the current time – but it's likely that we'll either display a progress bar in some corner of the screen, or we'll allow the user to drop the item, but grey it out and display a progress bar over it.

The library window itself has received a bit of a redesign since the last time we showed it in an FFF. Here is the current look of the library:



One of the changes is that it displays the blueprint name under its icon. Didyou know you could rename blueprints? You can, even in 0.14. Naming blueprintswill be very useful with the library, as you can stuff only so much informationinto the preview icon to help you remember which blueprint is which.

Another big change is that we changed the library to a two-panel window. On theright, you can see all of your blueprints – these are the ones that are saved onyour disk and follow you from save to save. They are also automatically shared with others in an MP game. The left panel houses other players' blueprints, and it's there you'll be able to get someone else's blueprint from.

A topic of great debate was what to do with the “Game Blueprints” section inorder to make it easy to understand what it's for and how it works. Game Blueprints are blueprints associated with the save itself – they are useful forsave-specific blueprints that you don't want to drag along with you to every save you play. They are also useful for server-specific setups: When a new player joins an MP game, they can be directed to grab blueprints from this section, rather than being told to hunt them from various other players (who may not even be on at the time!).

I'm still not completely convinced that this is the correct place for Game Blueprints to be. Game Blueprints are somewhat special in that they are tied to a specific save, and in this sense, they don't belong to the left panel. However, introducing a third panel would make the window too wide in my opinion. The interface is still very much work in progress, though, and perhaps we'll figure out an even better way to do it soon.

Seeing how much of a struggle a handful of GUI windows can mean for us, we've been looking for a UI and UX designer. And as a bit of an early Christmas gift,we actually found one! Say hello to Norbert, our official GUI guy.

Norbert is starting for real in January, but he has already spent a week with us. During his week with us he was mostly getting to grips with the rest of the team, but even so he managed to come up with an improved design for one of our GUIs – the blueprint preview GUI.



This is the window you see when you first create a blueprint, or when you open a blueprint item by right-clicking it. it really is the same as it always was, but rearranged.

Remember how I told you earlier in this article you could rename blueprints? In0.14, there is an icon next to the “Blueprint” title that looks like a refresh button. That's how you rename it. Maybe it should not have taken a UI designer to tell us that that was the wrong icon for the task, but at least someone finally told us.

Another point Norbert made was that the old GUI didn't make it entirely clear that you could select which icons would show up on the blueprint item in your inventory. And while we're at it, why not make the preview icon larger so you can see the icons better?

Like everything else, even this GUI is still a work in progress – the annoyingly green tick mark icon is my own creation – Albert will make it look good once he gets around to it, don't you worry. Still, I hope you will appreciate the improvements being done, and maybe Factorio's GUI will be less quirky one day.

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

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