Hello, pretty much half of the office has been sick in the past week, but that still hasn't stopped us from progressing in the development of your favourite pollution-generating game (though I have been playing some Cities skyline recently and there you can screw the nature around quite creatively as well).
Infinite research
The reason for infinite research is mainly to give some optional resource sinks for people that like to make huge factories. The research cost/gain ratio is going to have diminishing returns so the player bonuses don't become too absurd.
The main problem was to define the way to specify the research requirements growth. Sometimes it should be linear, sometimes quadratic, sometimes exponential. To make the modding of it free enough, we allowed to specify it via a formula, so for example, the Worker robot speed research 6+ has the formula specified like this: count_formula = "1000*2^(l-6)" where the l stands for the level of the research.
I wrote our own small math formula parser for Factorio, so the formula is parsed only once and stored internally as the graph of the expression, so it can be evaluated quickly for different values. We might find handy usages of this on other places in Factorio later on as well.
Anyway, the formula as it stands means, that the level 6 costs 1000:
As every other level costs twice of the previous one, the level 10 costs already a ton:
This change was easier than I expected and the plan is to have infinite research for most of the upgrade technologies in the game, which is now very simple to add to the game. I'm looking forward to see how far I can go with my playtesting base with these. I'm thinking of a way to improve the circuit production already :)
Blueprint Library
We have made quite some progress on the Blueprint Library, which will be one of the bigger 0.15 features. Check out the introduction in the FFF-156 if you need. At the moment the basics for the singleplayer usage are finished. You can have blueprints stored locally in the game as well as in the persistent (across saves) storage.
There is (hopefully) intuitive gui to work with the library. You can export blueprints and blueprint books from the game to the library. There it is possible to move the blueprints around simply by dragging either within the same storage or for instance from game storage to the persistent storage or vice versa. Of course you can move the blueprints in and out of the blueprint books as well.
Detail guis for blueprints and blueprint books are very similar to the guis already in the game with additional possibility of (instant) crafting and deleting the blueprint / book from the library.
Screenshots show the proof of concept with details of a single blueprint book and then a blueprint within that blueprint book opened.
The next point in the Todo list is to make the whole thing work for the multiplayer as well - you can see other players' blueprints and download them. This will require some fragmentation tricks to avoid hiccups when sending a lot of blueprint data over the network.
Yet another 0.15 optimisation
As part of multithreading update preparations, another nice little optimisation came up. It is related to situations like this: The problem is, that there are a lot of chunks where nothing happens, only pollution needs to be calculated.The pollution simulation is written in a way, that every chunk updates its pollution spread only once per 60 ticks (once per second). Every chunk updates at different moments of the 60 tick cycle, so the cpu drain is distributed.The problem is, that the code was written in this way: // handle pollution (every second for performance reasons) if (tick % 60 == uint32_t(abs(this->position.x) + abs(this->position.y)) % 60) ... handling pollution logic ... This means, that for all of those chunks that have nothing else but pollution, the game has to go through and check whether its pollution shouldn't be updated this particular tick or not. As I know when the chunk is going to be updated next time (in 60 ticks), I can just add it to the particular queue of chunks to be updated in the 60 ticks ahead. This means that these particular chunks (as long as something else doesn't interfere) will not have to be accessed at all in the meantime: This change itself improved the performance of big factories by something like 7%.
UX designer hunt
As you probably know we intend to polish the game and user experience within the coming releases. This includes the GUI overhaul, improving the existing missions and adding the so called mini-tutorials or interactive tips and tricks (mentioned in the previous FFF) - Scott has actually started to work on these and he will bring some news soon.
With all these plans ahead we have figured that we really need a dedicated UI/UX designer to work with us on these projects (and maybe some others). As the situation stands all the work would be done by Albert, however finding a contractor who would come here to Prague and cooperated with us on these would be a big relief of workload for Albert and it would allow him to focus on improving the in-game content. Not mentioning that professional UI/UX designer would ideally have the skills to start working on this immediately, while Albert would need some time to do his research.
Long story short, if someone you know (or you yourself =)) would fit the job description and find the work interesting, send him our way=) It will most probably end up being a couple of months cooperation when we will require the designer to come to Prague occasionally to discuss the progress.
And as always, stop by at our forums and let us know what you think.
Hello, pretty much half of the office has been sick in the past week, but that still hasn't stopped us from progressing in the development of your favourite pollution-generating game (though I have been playing some Cities skyline recently and there you can screw the nature around quite creatively as well).
Infinite research
The reason for infinite research is mainly to give some optional resource sinks for people that like to make huge factories. The research cost/gain ratio is going to have diminishing returns so the player bonuses don't become too absurd.
The main problem was to define the way to specify the research requirements growth. Sometimes it should be linear, sometimes quadratic, sometimes exponential. To make the modding of it free enough, we allowed to specify it via a formula, so for example, the Worker robot speed research 6+ has the formula specified like this: count_formula = "1000*2^(l-6)" where the l stands for the level of the research.
I wrote our own small math formula parser for Factorio, so the formula is parsed only once and stored internally as the graph of the expression, so it can be evaluated quickly for different values. We might find handy usages of this on other places in Factorio later on as well.
Anyway, the formula as it stands means, that the level 6 costs 1000:
As every other level costs twice of the previous one, the level 10 costs already a ton:
This change was easier than I expected and the plan is to have infinite research for most of the upgrade technologies in the game, which is now very simple to add to the game. I'm looking forward to see how far I can go with my playtesting base with these. I'm thinking of a way to improve the circuit production already :)
Blueprint Library
We have made quite some progress on the Blueprint Library, which will be one of the bigger 0.15 features. Check out the introduction in the FFF-156 if you need. At the moment the basics for the singleplayer usage are finished. You can have blueprints stored locally in the game as well as in the persistent (across saves) storage.
There is (hopefully) intuitive gui to work with the library. You can export blueprints and blueprint books from the game to the library. There it is possible to move the blueprints around simply by dragging either within the same storage or for instance from game storage to the persistent storage or vice versa. Of course you can move the blueprints in and out of the blueprint books as well.
Detail guis for blueprints and blueprint books are very similar to the guis already in the game with additional possibility of (instant) crafting and deleting the blueprint / book from the library.
Screenshots show the proof of concept with details of a single blueprint book and then a blueprint within that blueprint book opened.
The next point in the Todo list is to make the whole thing work for the multiplayer as well - you can see other players' blueprints and download them. This will require some fragmentation tricks to avoid hiccups when sending a lot of blueprint data over the network.
Yet another 0.15 optimisation
As part of multithreading update preparations, another nice little optimisation came up. It is related to situations like this: The problem is, that there are a lot of chunks where nothing happens, only pollution needs to be calculated.The pollution simulation is written in a way, that every chunk updates its pollution spread only once per 60 ticks (once per second). Every chunk updates at different moments of the 60 tick cycle, so the cpu drain is distributed.The problem is, that the code was written in this way: // handle pollution (every second for performance reasons) if (tick % 60 == uint32_t(abs(this->position.x) + abs(this->position.y)) % 60) ... handling pollution logic ... This means, that for all of those chunks that have nothing else but pollution, the game has to go through and check whether its pollution shouldn't be updated this particular tick or not. As I know when the chunk is going to be updated next time (in 60 ticks), I can just add it to the particular queue of chunks to be updated in the 60 ticks ahead. This means that these particular chunks (as long as something else doesn't interfere) will not have to be accessed at all in the meantime: This change itself improved the performance of big factories by something like 7%.
UX designer hunt
As you probably know we intend to polish the game and user experience within the coming releases. This includes the GUI overhaul, improving the existing missions and adding the so called mini-tutorials or interactive tips and tricks (mentioned in the previous FFF) - Scott has actually started to work on these and he will bring some news soon.
With all these plans ahead we have figured that we really need a dedicated UI/UX designer to work with us on these projects (and maybe some others). As the situation stands all the work would be done by Albert, however finding a contractor who would come here to Prague and cooperated with us on these would be a big relief of workload for Albert and it would allow him to focus on improving the in-game content. Not mentioning that professional UI/UX designer would ideally have the skills to start working on this immediately, while Albert would need some time to do his research.
Long story short, if someone you know (or you yourself =)) would fit the job description and find the work interesting, send him our way=) It will most probably end up being a couple of months cooperation when we will require the designer to come to Prague occasionally to discuss the progress.
And as always, stop by at our forums and let us know what you think.
Decreased the size of connection accept message with lot of mod which could help some people with 50+ mod multiplayer games. https://forums.factorio.com/33662
Decreased the size of connection accept message with lot of mod which could help some people with 50+ mod multiplayer games. https://forums.factorio.com/33662
This was the first single player playthrough in a long time, so there was a lot of new findings. I also enjoyed all the new features, like blueprint book, auto trash, train conditions etc. These were little things but they helped a lot.
Finding 1 - the game contains a lot already
The game took me 46 hours to finish. I didn't hurry too much, but it is still quite a long time, considering I played the game several times from start to finish already.
It is not always so obvious to me when we are doing little iterative additions one by one, but when playing from start to finish, there are a lot of things to do. I like the moments when I have dozens of improvements to do and I need to choose the most important one for the moment. The complete change of playstyle in different phases of the game (Burner → research → mass production → trains → multibelt setups → construction robots → even bigger mass production → automated delivery → modules → multi platform stations → rocket) felt right. The overall feeling was, that we shouldn't add much to the game content anymore or it will become too complex and big for the newcomers. This means, that when we add nuclear power, dirty mining, and a few little things, that will be it for the vanilla part of the game. We can still do the expansion pack with additional stages of the game and space exploration later, but that is a different story. The additional complexity will have to be optionally available via modding, this is why we have the native mod support.
There are still a lot of things to be done even if we don't want to drown the player in features, like optimisations to make bigger factories run smoother, as a big part of the fun comes from organizing logistics of huge quantities.
Finding 2 - The effects of research changes
The higher tiers of the research were more expensive and slower (compared to the current 0.14) which I believe is a good thing. Choosing what to research felt more important and as things were unlocked slower. I had enough time to go through almost all the stages of the military options as the game progressed, which felt right.
Finding 3 - the most needed changes
The best way to improve the game as I see it, is to minimise the annoying parts of the gameplay.
This is the list of changes for 0.15 I decided to do based on this playthrough:
Decrease the bounding box of burner mining drills,chemical plants and pumpjacks so walking in between them is possible.
Increase stack sizes of belts,walls and pipes from 50 to 100, this is mainly for the later stage of the game with personal roboports, where making train stations and expansions meant having not enough of belts and walls way too often.
Figure some way to have low level personal construction robots earlier in the game.
Change the oil so the minimum yield is dependent on the starting yield so better fields are also better later on.
There are more oil fields (compared to 0.13) which is a good change, but setting them up is quite a chore for big ones, so having fewer of them with higher yield would be better.
MK2 personal roboport is a must, as the limit of 10 robots per roboport is not enough in later stages of the game when building bigger setups.
Concrete shouldn't be blue science (green only)
The electric furnace should be somewhat cheaper. (Especially when it is used in science packs now)
Shift click (ghost placement) should go through trees and rocks as blueprints with shift do.
Enhancement to the belt building mechanics, so building by dragging makes continuous belt.
Limit turret creep as it is way too powerful now (especially with personal roboport) with a turret activation time. As it makes the expansion harder, the resource growth from the center should be higher.
Merging items with different health. - We didn't do the item merging, as we didn't want the player lose his precious items as two 49% items would merge into one, which would prevent the player from repairing both for just a few repair. In reality, I feel that the annoyance of having 8 different stacks of laser turrets/walls in my inventory is not worth the rare possibility of losing an item or two.
MK2 version of boiler and steam engine. It is going to be a must with the nuclear power, but it should be usable with conventional coal power generation as well.
Finding 4 - The interactive tips and tricks is a must
There are many tricks and shortcuts in the game that make the gameplay so much easier. As we don't want to overwhelm the players with huge tutorials in the start, we need to teach them those as the game progresses. This would be done by the little interactive tutorials that would unlock only when it is relevant. Something like this:
You build the first locomotive → Tutorial to setup a train schedule unlocked.
You build a second locomotive → Tutorial of rail signals unlocked.
You build 50 rail signals → Tutorial of chain signals unlocked.
You build 10 requester chests → Tutorial that copy paste from assembler to requester chest does exactly what you need.
etc. etc.
As the tricks would be given to the player in small doses as he plays through the game and mainly when the player is probably just about to use it, we might add lots of these without the fear of overwhelming the player.
As always, if you have any comments or otherwise, please let us know on our forums.
This was the first single player playthrough in a long time, so there was a lot of new findings. I also enjoyed all the new features, like blueprint book, auto trash, train conditions etc. These were little things but they helped a lot.
Finding 1 - the game contains a lot already
The game took me 46 hours to finish. I didn't hurry too much, but it is still quite a long time, considering I played the game several times from start to finish already.
It is not always so obvious to me when we are doing little iterative additions one by one, but when playing from start to finish, there are a lot of things to do. I like the moments when I have dozens of improvements to do and I need to choose the most important one for the moment. The complete change of playstyle in different phases of the game (Burner → research → mass production → trains → multibelt setups → construction robots → even bigger mass production → automated delivery → modules → multi platform stations → rocket) felt right. The overall feeling was, that we shouldn't add much to the game content anymore or it will become too complex and big for the newcomers. This means, that when we add nuclear power, dirty mining, and a few little things, that will be it for the vanilla part of the game. We can still do the expansion pack with additional stages of the game and space exploration later, but that is a different story. The additional complexity will have to be optionally available via modding, this is why we have the native mod support.
There are still a lot of things to be done even if we don't want to drown the player in features, like optimisations to make bigger factories run smoother, as a big part of the fun comes from organizing logistics of huge quantities.
Finding 2 - The effects of research changes
The higher tiers of the research were more expensive and slower (compared to the current 0.14) which I believe is a good thing. Choosing what to research felt more important and as things were unlocked slower. I had enough time to go through almost all the stages of the military options as the game progressed, which felt right.
Finding 3 - the most needed changes
The best way to improve the game as I see it, is to minimise the annoying parts of the gameplay.
This is the list of changes for 0.15 I decided to do based on this playthrough:
Decrease the bounding box of burner mining drills,chemical plants and pumpjacks so walking in between them is possible.
Increase stack sizes of belts,walls and pipes from 50 to 100, this is mainly for the later stage of the game with personal roboports, where making train stations and expansions meant having not enough of belts and walls way too often.
Figure some way to have low level personal construction robots earlier in the game.
Change the oil so the minimum yield is dependent on the starting yield so better fields are also better later on.
There are more oil fields (compared to 0.13) which is a good change, but setting them up is quite a chore for big ones, so having fewer of them with higher yield would be better.
MK2 personal roboport is a must, as the limit of 10 robots per roboport is not enough in later stages of the game when building bigger setups.
Concrete shouldn't be blue science (green only)
The electric furnace should be somewhat cheaper. (Especially when it is used in science packs now)
Shift click (ghost placement) should go through trees and rocks as blueprints with shift do.
Enhancement to the belt building mechanics, so building by dragging makes continuous belt.
Limit turret creep as it is way too powerful now (especially with personal roboport) with a turret activation time. As it makes the expansion harder, the resource growth from the center should be higher.
Merging items with different health. - We didn't do the item merging, as we didn't want the player lose his precious items as two 49% items would merge into one, which would prevent the player from repairing both for just a few repair. In reality, I feel that the annoyance of having 8 different stacks of laser turrets/walls in my inventory is not worth the rare possibility of losing an item or two.
MK2 version of boiler and steam engine. It is going to be a must with the nuclear power, but it should be usable with conventional coal power generation as well.
Finding 4 - The interactive tips and tricks is a must
There are many tricks and shortcuts in the game that make the gameplay so much easier. As we don't want to overwhelm the players with huge tutorials in the start, we need to teach them those as the game progresses. This would be done by the little interactive tutorials that would unlock only when it is relevant. Something like this:
You build the first locomotive → Tutorial to setup a train schedule unlocked.
You build a second locomotive → Tutorial of rail signals unlocked.
You build 50 rail signals → Tutorial of chain signals unlocked.
You build 10 requester chests → Tutorial that copy paste from assembler to requester chest does exactly what you need.
etc. etc.
As the tricks would be given to the player in small doses as he plays through the game and mainly when the player is probably just about to use it, we might add lots of these without the fear of overwhelming the player.
As always, if you have any comments or otherwise, please let us know on our forums.
As the 0.15 work started, the first thing I wanted to do was to rebalance the science packs. We feel that the science pack 1 and 2 balance is just right, but the level 3 (blue) is quite a large jump in complexity, while the alien science pack is trivial. Then I checked that the last time we changed something about the science packs was 2.5 years ago, so it might be the time to try to be more creative.
After some discussions, we decided to make the science packs not so linear and more iterative, the current working version looks something like this:
The prices of the science packs are subject to change as we need to playtest it, but the first version is this:
To make the work of reassigning the science packs to technologies easier, I decided to finally implement the so long postponed feature of showing the needed science packs on the technology icon. We also sort the technologies by the highest science pack needed:
The icons might change, but a late game science setup might look something like this.
On top of that, I would like to implement the infinite research. It would give smaller and smaller gains, but people could spend the resources on something after finishing the regular research if they wanted to.
PvP scenario
This paragraph is brought to you by Klonan.
The concept of a player versus player experience in factorio has been around since we introduced multiplayer in version 0.11. Initially there was a small mod which places players alternately on the player and enemy force, the players would then fight it out, with the addition of some craftable biter capsules.
With 0.12 we expanded the forces system, to allow creating and assigning forces to players, allowing the possibility of up to 254 different teams in a single game.
However PvP attempts quickly fell at the first hurdle: multiple players were needed. With the issues of the peer-to-peer multiplayer, the actual experience was not ideal. With the recent success of the team production challenge and the MMO server tests, we decided the conditions were right to create an official PvP mode.
This last week I have been working on the foundation for this new scenario, along with ideas about how specifically it will work, this is what we have so far:
The first player to create the scenario will be the gamemaster. He will set some configuration options, such as how many teams, the starting tech level etc.
The original starting area will be copied to the new teams spawn positions, each identical to the other.
Each starting area will contain a rocket silo.
If your rocket silo is destroyed, your team has lost.
If you launch a rocket, your team wins.
If all other teams silos have been destroyed, you win.
When you destroy another team's silo, all their base are belong to you.
For other specifics we don't have a good idea, such as what to do with the players of defeated teams. The two main ideas were to allow them to spectate players, or allow them to join another team (which didn't defeat them).
Another issue is that copying the starting area directly would obviously look odd:
I had some discussion with Cube about possible solutions, but these would be some large changes to the internal map generator code, so will have to wait for 0.15.
Custom maps could be nice and simple solution, especially if someone from the community would come up with proposals.
In the end these small issues aside, we think it will be quite an enjoyable gameplay mode, and something for the more competitive players to sink their teeth into.
Liquid wagon
Look:
As always, if you have any comments or otherwise, please let us know on our forums.
As the 0.15 work started, the first thing I wanted to do was to rebalance the science packs. We feel that the science pack 1 and 2 balance is just right, but the level 3 (blue) is quite a large jump in complexity, while the alien science pack is trivial. Then I checked that the last time we changed something about the science packs was 2.5 years ago, so it might be the time to try to be more creative.
After some discussions, we decided to make the science packs not so linear and more iterative, the current working version looks something like this:
The prices of the science packs are subject to change as we need to playtest it, but the first version is this:
To make the work of reassigning the science packs to technologies easier, I decided to finally implement the so long postponed feature of showing the needed science packs on the technology icon. We also sort the technologies by the highest science pack needed:
The icons might change, but a late game science setup might look something like this.
On top of that, I would like to implement the infinite research. It would give smaller and smaller gains, but people could spend the resources on something after finishing the regular research if they wanted to.
PvP scenario
This paragraph is brought to you by Klonan.
The concept of a player versus player experience in factorio has been around since we introduced multiplayer in version 0.11. Initially there was a small mod which places players alternately on the player and enemy force, the players would then fight it out, with the addition of some craftable biter capsules.
With 0.12 we expanded the forces system, to allow creating and assigning forces to players, allowing the possibility of up to 254 different teams in a single game.
However PvP attempts quickly fell at the first hurdle: multiple players were needed. With the issues of the peer-to-peer multiplayer, the actual experience was not ideal. With the recent success of the team production challenge and the MMO server tests, we decided the conditions were right to create an official PvP mode.
This last week I have been working on the foundation for this new scenario, along with ideas about how specifically it will work, this is what we have so far:
The first player to create the scenario will be the gamemaster. He will set some configuration options, such as how many teams, the starting tech level etc.
The original starting area will be copied to the new teams spawn positions, each identical to the other.
Each starting area will contain a rocket silo.
If your rocket silo is destroyed, your team has lost.
If you launch a rocket, your team wins.
If all other teams silos have been destroyed, you win.
When you destroy another team's silo, all their base are belong to you.
For other specifics we don't have a good idea, such as what to do with the players of defeated teams. The two main ideas were to allow them to spectate players, or allow them to join another team (which didn't defeat them).
Another issue is that copying the starting area directly would obviously look odd:
I had some discussion with Cube about possible solutions, but these would be some large changes to the internal map generator code, so will have to wait for 0.15.
Custom maps could be nice and simple solution, especially if someone from the community would come up with proposals.
In the end these small issues aside, we think it will be quite an enjoyable gameplay mode, and something for the more competitive players to sink their teeth into.
Liquid wagon
Look:
As always, if you have any comments or otherwise, please let us know on our forums.
The /config command now operates through /config get and /config set.
Added additional options to the /config comand: allow-commands, max-upload-speed, autosave-interval, afk-auto-kick, verify-user-identity, only-admins-can-pause, ignore-player-limit-for-returning-players.
Added tab-complete parameters logic to the commands: config, color, and help.
Updated Team production challenge with 2 new challenge modes and a new map set.
Reconnecting to multiplayer game that the player already is in (being dropped probably) instantly closes the previous connection and connects the player.
Fixed that /command would warn about disabling achievements even in situations where achievements weren't possible. (https://forums.factorio.com/33597)
Fixed that error messages of wrong zip files in the mod folder weren't giving error message that would be informative enough. (https://forums.factorio.com/33790)
Scripting
Added read property LuaEntity::has_direction.
Added LuaTile::hidden_tile.
Added the ability to use LuaSurface::get_tile(0, 0) or LuaSurface::get_tile({0, 0}) when getting tiles.
Added LuaGameScript::connected_players read and LuaForce::connected_players read.
Modding
Added check that the selection box contains the [0, 0] point.
The /config command now operates through /config get and /config set.
Added additional options to the /config comand: allow-commands, max-upload-speed, autosave-interval, afk-auto-kick, verify-user-identity, only-admins-can-pause, ignore-player-limit-for-returning-players.
Added tab-complete parameters logic to the commands: config, color, and help.
Updated Team production challenge with 2 new challenge modes and a new map set.
Reconnecting to multiplayer game that the player already is in (being dropped probably) instantly closes the previous connection and connects the player.
Fixed that /command would warn about disabling achievements even in situations where achievements weren't possible. (https://forums.factorio.com/33597)
Fixed that error messages of wrong zip files in the mod folder weren't giving error message that would be informative enough. (https://forums.factorio.com/33790)
Scripting
Added read property LuaEntity::has_direction.
Added LuaTile::hidden_tile.
Added the ability to use LuaSurface::get_tile(0, 0) or LuaSurface::get_tile({0, 0}) when getting tiles.
Added LuaGameScript::connected_players read and LuaForce::connected_players read.
Modding
Added check that the selection box contains the [0, 0] point.