• Fixed loading of electric network of pre 0.12 saves.
  
• Fixed blueprint building. Blueprints are migrated as long as you load the version 0.12.30 or earlier, existing bluepritns might be off if you resaved in 0.12.31 already.

• Lua interface to create blueprint now expects the entity positions to be relative to center exactly, so in rail-less blueprints, the position 0.0 translates to center of the tile when the blueprint is built.

Use the automatic updater if you can (check experimental updates in other settings) or download full installation at http://www.factorio.com/download/experimental.

• Fixed loading of electric network of pre 0.12 saves.
  
• Fixed blueprint building. Blueprints are migrated as long as you load the version 0.12.30 or earlier, existing bluepritns might be off if you resaved in 0.12.31 already.

• Lua interface to create blueprint now expects the entity positions to be relative to center exactly, so in rail-less blueprints, the position 0.0 translates to center of the tile when the blueprint is built.

Use the automatic updater if you can (check experimental updates in other settings) or download full installation at http://www.factorio.com/download/experimental.

This week's instance of FFF is brought to you by cube, your friendly neighbor
clueless network programmer. This post will be more technical than usual, so let us know if you found it interesting.


The week has been spent mostly on pushing forward in multiple of ongoing areas in the development for 0.13. Robert is working on Combinators, Posila and Vaclav on Fire and Flamethrower Turret, Martin is immersed in Factorio modportal and its integration and Tomas and Ondra have been tweaking some Multiplayer Matching server stuff. While Kovarex has spent most time on the 0.12 bugfixing. Albert is back home for a week so the full speed gfx work will happen from next week on.


Factorio has long had problems with map upload speed.
As usual the hard problems they always appear "out there" and never when you're looking for them,
so while we were getting a steady stream of bug reports about this problem, we
could never replicate it.

You might ask why do we even need to upload the whole map when the player might
end up seeing just a tiny part of the world anyway.
AAAAnd the answer is: That's just how it works :-).
Essentially it's because Factorio runs a lockstep simulation and every player needs
to have complete information about the whole map.
This has been discussed in slightly more detail in
an older blogpost.

Now that we know that we really must copy all the data, the question is how to do
it well.


As you probably already knew, the Internet works by passing small chunks of data
called packets
(or frames or segments or datagrams, depending on where exactly you look).
These are nothing special, just some bytes wrapped in an envelope made out of other bytes.
The network that these packets travel is a dangerous place, packet can get lost,
delayed, or even duplicated along the way.

To keep people sane and networks fast, someone came up with a way to hide all these
complications (because that's what programmers do) and invented the TCP protocol.
Instead of transferring unreliable packets, it provides a stream of bytes
and the machinery inside wraps pieces of the stream to packets and makes sure that
all bytes arrive as sent.

Which sounds suspiciously similar to moving files over the network, right?
Just pop the whole thing into the stream and let the elfs do their magic.


Unfortunately in Factorio nothing is ever easy :-).
Using TCP would have three important consequences: It would force players to open
TCP ports as well as UDP ports in firewalls and NAT servers, it would remove the
possibility of using NAT punching now or later with MP matching server and it would
cause problems with downloading from multiple players at the same time.

So we decided to have file transfers done over UDP, even though it means reimplementing
a significant part of TCP functionality.

To make downloading from several other players possible in peer to peer mode,
the file transfers work by requesting individual blocks from peers and waiting for
the data, instead of sending data and waiting for acknowledgements.
Also we don't really care about ordering of the data blocks as long as all of them
are eventually transmitted.


When we started implementing the file transfer all I had was a rough idea of
"we're sending some packets and waiting for confirmations, somehow we know how many unconfirmed
packets there should be at one time and that value is called cWnd".
So Wikipedia came to the rescue and told me that a prety decent algorithm to determine
cWnd is called CUBIC.
So I read an article or two, coded it up and ... it worked! Let's ship it!

A few releases, a few fixes, and a few desperate kludges later it worked very reliably
on my machine and the code got kind of forgotten.

About three weeks ago we decided to revisit the map transfers and I've spent two
fun weeks in TCP land.


The significant part of TCP functionality mentioned earlier is called congestion avoidance.

When you are sending some packets into the network you usually don't know in advance
how fast the network is or how long it will take to reach the other end and
if too many packets are stuffed into the connection not only some of them will be
dropped, but also packets belonging to other connections that go through the same
part of network will get dropped.
This situation is called network congestion and generally it's a thing we want to avoid,
because it slows the available transfer speed for everyone.

So the main idea behind congestion avoidance TCP is to send some amount data and
wait for acknowledgements before sending more.
If the acknowledgement arrives, we know that sending this amount of data is OK and
we try to send a little more next time, if on the other hand the packets start
disappearing we know we are sending too much and we should slow down.

Because of only a little complicated reasons, the increase of the window size
is a roughly linear function of time and the decrease is immediate halving, this
algorithm is called AIMD (additive increase, multiplicative decrease).
This way the amount of data in the network is oscillating between no congestion
at all and very minor congestion, slowly going up and then suddenly jumping down
to half speed.


Our first guess for the reasons of the slow transfer speeds was packet loss.
Both AIMD and CUBIC decrease the transfer speed drastically after a packet is lost
so when your microwave decides that the WiFi connection is its mortal enemy,
the congestion avoidance algorithm will slow down.

The measurements confirmed this, but compared to TCP, our file transfers were always
a little bit faster when packet loss was artificially added.

After an embarrassingly long period of experimentation I was left with two implementations.
AIMD, based mainly on RFC 5681 and
my own attempt slightly inspired by Sync-TCP and LEDBAT,
but other than that completely original.
And neither of them worked too well :-).

With my custom protocol that was not unexpected, it was mostly meant for experimenting
and to get a feeling for all the different behaviors the network can cause.

On the other hand why the AIMD implementation was not working was a mystery.
Finally after finding RFC 2525
(thank you, internet people from 1999), I figured out that all problems in my life
were caused by a missing fast retransmit / fast recovery mechanism.

Fast retransmit and fast recovery work by marking a packet as lost not when its
timeout expires, but when three packets sent later are confirmed instead of the
packet in question.
In this case the packet is retransmitted and fast recovery mode is entered instead of waiting
a whole second, overflowing the network with extra packets the whole time.

After these changes we've upgraded the algorithm to be very similar to
TCP Westwood which finally
gave us the improved behavior on lossy networks.

So TADAAA, here we are now.
The map transfer protocol is less tested than the previous one, but we feel more
certain about it, so let's hope that it's going to be the last change necessary
to this part of networking code.

Map download was slow, cube spent some time doing computer stuff, now it should be faster.

Let us know what you think at the forum.

This week's instance of FFF is brought to you by cube, your friendly neighbor
clueless network programmer. This post will be more technical than usual, so let us know if you found it interesting.


The week has been spent mostly on pushing forward in multiple of ongoing areas in the development for 0.13. Robert is working on Combinators, Posila and Vaclav on Fire and Flamethrower Turret, Martin is immersed in Factorio modportal and its integration and Tomas and Ondra have been tweaking some Multiplayer Matching server stuff. While Kovarex has spent most time on the 0.12 bugfixing. Albert is back home for a week so the full speed gfx work will happen from next week on.


Factorio has long had problems with map upload speed.
As usual the hard problems they always appear "out there" and never when you're looking for them,
so while we were getting a steady stream of bug reports about this problem, we
could never replicate it.

You might ask why do we even need to upload the whole map when the player might
end up seeing just a tiny part of the world anyway.
AAAAnd the answer is: That's just how it works :-).
Essentially it's because Factorio runs a lockstep simulation and every player needs
to have complete information about the whole map.
This has been discussed in slightly more detail in
an older blogpost.

Now that we know that we really must copy all the data, the question is how to do
it well.


As you probably already knew, the Internet works by passing small chunks of data
called packets
(or frames or segments or datagrams, depending on where exactly you look).
These are nothing special, just some bytes wrapped in an envelope made out of other bytes.
The network that these packets travel is a dangerous place, packet can get lost,
delayed, or even duplicated along the way.

To keep people sane and networks fast, someone came up with a way to hide all these
complications (because that's what programmers do) and invented the TCP protocol.
Instead of transferring unreliable packets, it provides a stream of bytes
and the machinery inside wraps pieces of the stream to packets and makes sure that
all bytes arrive as sent.

Which sounds suspiciously similar to moving files over the network, right?
Just pop the whole thing into the stream and let the elfs do their magic.


Unfortunately in Factorio nothing is ever easy :-).
Using TCP would have three important consequences: It would force players to open
TCP ports as well as UDP ports in firewalls and NAT servers, it would remove the
possibility of using NAT punching now or later with MP matching server and it would
cause problems with downloading from multiple players at the same time.

So we decided to have file transfers done over UDP, even though it means reimplementing
a significant part of TCP functionality.

To make downloading from several other players possible in peer to peer mode,
the file transfers work by requesting individual blocks from peers and waiting for
the data, instead of sending data and waiting for acknowledgements.
Also we don't really care about ordering of the data blocks as long as all of them
are eventually transmitted.


When we started implementing the file transfer all I had was a rough idea of
"we're sending some packets and waiting for confirmations, somehow we know how many unconfirmed
packets there should be at one time and that value is called cWnd".
So Wikipedia came to the rescue and told me that a prety decent algorithm to determine
cWnd is called CUBIC.
So I read an article or two, coded it up and ... it worked! Let's ship it!

A few releases, a few fixes, and a few desperate kludges later it worked very reliably
on my machine and the code got kind of forgotten.

About three weeks ago we decided to revisit the map transfers and I've spent two
fun weeks in TCP land.


The significant part of TCP functionality mentioned earlier is called congestion avoidance.

When you are sending some packets into the network you usually don't know in advance
how fast the network is or how long it will take to reach the other end and
if too many packets are stuffed into the connection not only some of them will be
dropped, but also packets belonging to other connections that go through the same
part of network will get dropped.
This situation is called network congestion and generally it's a thing we want to avoid,
because it slows the available transfer speed for everyone.

So the main idea behind congestion avoidance TCP is to send some amount data and
wait for acknowledgements before sending more.
If the acknowledgement arrives, we know that sending this amount of data is OK and
we try to send a little more next time, if on the other hand the packets start
disappearing we know we are sending too much and we should slow down.

Because of only a little complicated reasons, the increase of the window size
is a roughly linear function of time and the decrease is immediate halving, this
algorithm is called AIMD (additive increase, multiplicative decrease).
This way the amount of data in the network is oscillating between no congestion
at all and very minor congestion, slowly going up and then suddenly jumping down
to half speed.


Our first guess for the reasons of the slow transfer speeds was packet loss.
Both AIMD and CUBIC decrease the transfer speed drastically after a packet is lost
so when your microwave decides that the WiFi connection is its mortal enemy,
the congestion avoidance algorithm will slow down.

The measurements confirmed this, but compared to TCP, our file transfers were always
a little bit faster when packet loss was artificially added.

After an embarrassingly long period of experimentation I was left with two implementations.
AIMD, based mainly on RFC 5681 and
my own attempt slightly inspired by Sync-TCP and LEDBAT,
but other than that completely original.
And neither of them worked too well :-).

With my custom protocol that was not unexpected, it was mostly meant for experimenting
and to get a feeling for all the different behaviors the network can cause.

On the other hand why the AIMD implementation was not working was a mystery.
Finally after finding RFC 2525
(thank you, internet people from 1999), I figured out that all problems in my life
were caused by a missing fast retransmit / fast recovery mechanism.

Fast retransmit and fast recovery work by marking a packet as lost not when its
timeout expires, but when three packets sent later are confirmed instead of the
packet in question.
In this case the packet is retransmitted and fast recovery mode is entered instead of waiting
a whole second, overflowing the network with extra packets the whole time.

After these changes we've upgraded the algorithm to be very similar to
TCP Westwood which finally
gave us the improved behavior on lossy networks.

So TADAAA, here we are now.
The map transfer protocol is less tested than the previous one, but we feel more
certain about it, so let's hope that it's going to be the last change necessary
to this part of networking code.

Map download was slow, cube spent some time doing computer stuff, now it should be faster.

Let us know what you think at the forum.

• Bugfixes
  
  • Fixed crash when script errors occurs while loading game while in game. more
    
  • Fixed that attempting to connect to Factorio 0.12.30 with an old client wouldn't produce the correct error message. more
    
  • Fixed that modded roboports with no charging slots were still considering as charging candidates. more
    
  • Fixed that item icon variant for dark background was not used when showing cargo of logistic robots. more
    
  • Fixed crash with "Unblock sendto failed: The operation completed successfully." more
    
  • Human readable error notice when multiplayer connection wasn't successful. more
    
  • Fixed that headless server wouldn't save the map after Control-C. more
    
  • Fixed that attacking biters with a mining tool wouldn't aggro them.
    
  • Improved map download speed when connecting to multiplayer game. more
    
  • Fixed that assigning units to a unit group of a different force would corrupt the save. more
    
  • Fixed crash when using can_insert on the quickbar from the Lua APi.
    
  • Fixed tight spot scenario crash. more
    
  • Fixed sort order for recipes in the recipe display.
    
  • Fixed incorrect error message, when setting the number of filters on an inserter. more
    
  • Fixed flame from rafineries that are marked for deconstruction was frozen in mid air. more
    
  • Fixed that odd sized blueprints were shifted when rotated. more
    
  • Fixed crash when clearing modded blueprint that doesn't need item to be cleared. more
    
  • Fixed crash in arithmetic combinator when calculating -2147483648/-1. more
    
  • Fixed crash when assigning a character as a passenger of a vehicle when that character already is a passenger of another vehicle. more
    
  • Fixed dealing damage could sometimes corrupt game state and saves. more
    
  • Fixed modded save could not be loaded when a modded inserter gained abilities of smart inserter. more
    
  • Fixed unknown-key message on the third level of first-steps. more
    
  • Fixed cursor-split transfer (right click) not working when putting items into assembling machine stacks over normal stack size. more
    
  • Fixed remote.call() from within the same mod. more
    
  • Fixed inconsistent inserter behaviour when inserting into a splitter from the side. more
    
  • Fixed train trying to turn around on a single rail. more
    
  • Fixed internal electric network problems when mod specified irregular number as supply reach of power pole. more
    
  • Fixed crash when lua script appears in specific state in multiplayer. more
    
  • Fixed another crash than can happen when train destroys itself. more
    
  • Fixed rare multiplayer crash "server is missing in the crcs". more
    
  • Fixed several GUI problems on high DPI displays more
    
  
  
• Optimisations
  
  • Improved performance when using landmines. more
    
  
  
• Scripting
  
  • LuaUnitGroup::add_member now requires that the new member's force be the same as the UnitGroup's.
    
  • Added LuaUnitGroup::force read-only attribute.
    

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

• Bugfixes
  
  • Fixed crash when script errors occurs while loading game while in game. more
    
  • Fixed that attempting to connect to Factorio 0.12.30 with an old client wouldn't produce the correct error message. more
    
  • Fixed that modded roboports with no charging slots were still considering as charging candidates. more
    
  • Fixed that item icon variant for dark background was not used when showing cargo of logistic robots. more
    
  • Fixed crash with "Unblock sendto failed: The operation completed successfully." more
    
  • Human readable error notice when multiplayer connection wasn't successful. more
    
  • Fixed that headless server wouldn't save the map after Control-C. more
    
  • Fixed that attacking biters with a mining tool wouldn't aggro them.
    
  • Improved map download speed when connecting to multiplayer game. more
    
  • Fixed that assigning units to a unit group of a different force would corrupt the save. more
    
  • Fixed crash when using can_insert on the quickbar from the Lua APi.
    
  • Fixed tight spot scenario crash. more
    
  • Fixed sort order for recipes in the recipe display.
    
  • Fixed incorrect error message, when setting the number of filters on an inserter. more
    
  • Fixed flame from rafineries that are marked for deconstruction was frozen in mid air. more
    
  • Fixed that odd sized blueprints were shifted when rotated. more
    
  • Fixed crash when clearing modded blueprint that doesn't need item to be cleared. more
    
  • Fixed crash in arithmetic combinator when calculating -2147483648/-1. more
    
  • Fixed crash when assigning a character as a passenger of a vehicle when that character already is a passenger of another vehicle. more
    
  • Fixed dealing damage could sometimes corrupt game state and saves. more
    
  • Fixed modded save could not be loaded when a modded inserter gained abilities of smart inserter. more
    
  • Fixed unknown-key message on the third level of first-steps. more
    
  • Fixed cursor-split transfer (right click) not working when putting items into assembling machine stacks over normal stack size. more
    
  • Fixed remote.call() from within the same mod. more
    
  • Fixed inconsistent inserter behaviour when inserting into a splitter from the side. more
    
  • Fixed train trying to turn around on a single rail. more
    
  • Fixed internal electric network problems when mod specified irregular number as supply reach of power pole. more
    
  • Fixed crash when lua script appears in specific state in multiplayer. more
    
  • Fixed another crash than can happen when train destroys itself. more
    
  • Fixed rare multiplayer crash "server is missing in the crcs". more
    
  • Fixed several GUI problems on high DPI displays more
    
  
  
• Optimisations
  
  • Improved performance when using landmines. more
    
  
  
• Scripting
  
  • LuaUnitGroup::add_member now requires that the new member's force be the same as the UnitGroup's.
    
  • Added LuaUnitGroup::force read-only attribute.
    

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

Hello all,

Originally I intended to dedicate most of the post to the technical aspect of our new Multiplayer User Authorization mechanism that I have been working on in my programming time. Then I thought, hmm it would be nice to start with some project management changes that we are looking into and experimenting with. Then I pretty much ended up making a full blog post about that =) It might give you an interesting insight into issues that we are dealing with. The Multiplayer User Authorization mechanism will definitely be described in one of the future FFFs.


As mentioned in the previous FFF there is a new team member here with us. Her name is Michaela (or Mishka) and one of her main responsibilities is to get us a bit more organised=)

At the moment we are 11 people in the office with 2 external collaborators. Our short/midterm goal is to grow to about 15 people in the office (we are still looking for good C++ programmers ideally from Europe!).

Our approach to "project management" so far has been very loose and organic. Somehow we feel that we have reached a boundary here and need to start working a little bit on our methods of working together, sharing the results of work, etc. This especially holds true with our (moderate=)) growing ambitions.


So we spend quite some time brainstorming and figuring out what we believe is working well, what could be improved and where we want the things to go. We came up with 3 basic themes / areas for getting organised. In short these areas are: Transparency and knowledge sharing, Direction vs. management, Productivity. Let's have a look at the descriptions for all of these.

The next step was internally clarifying three aspects for every area:

• What is the current situation and why we want to change it.
• What is our goal.
• What tools and processes can we use to achieve the goal.

We are very aware that changes like these can be sensitive. Especially when we start using words like project management, goals, processes, etc. So our main criteria for the whole set of changes is to not overdo things. This means make small changes step by step and stop when we have achieved our goals. Also we are aware that processes and tools are here to serve us and not the other way around so we will try to keep our minds open and abandon things that won't work for us.


Till now, often a developer would work on a task for quite some time without too much interaction with others. Hence there was a lack of feedback on how he is doing, if he is stuck or not, if what he is working on might be related to what a different dev is doing, etc. So far our main tool of communication has been talking in the office / at lunch and Trello cards. Trello has worked really well for us, but it is getting full of cards, generally messy and often there is little information for particular cards and so on.

Ideally we are after a situation when people have a general overview of what others are working on. We are still small enough to do this for the team as the whole (imho it becomes harder for teams of 20 or more people). This should also improve productivity (people can help each other in case they know how to solve an issue someone else is stuck with).

We started by having a short stand-up meeting twice a week (currently Monday and Thursday at 1 p.m.). The meeting (ideally) takes about 15 minutes, requires all the team members to be present and standing (to keep the pace going). We start by announcements if there are any (this and this person is coming for probation, we have made this and this presentation, etc.). Afterwards we go in a round and everyone gives a brief status. This means: what he is working on, if he is doing ok or is stuck, if he needs to communicate with other people, etc. This takes (ideally) less than a minute for a person. In the near future we intend to have "minutes" (short transcript) from the meeting in the written form to inform (and gather feedback) from the members not present.
The main inspiration for stand-up meetings came from my pre-Factorio (so long ago :D) programming job in Amsterdam, where it really helped us as a team of about 12 developers.

Another potential change we are looking into here is become more verbose in our Trello cards. This would mean giving proper description to cards, links to forums or other related cards, using checkbox lists, etc.


So far the project direction and project management "roles" have been concentrated in the hands of the same people (kovarex, me and Albert). This makes sense for very small teams however it is also quite limiting. The basic issue here is that the direction is more like a vision (I imagine a person who knows where the ship should go) while management is more like an every day task making sure that the ship actually goes where the direction has been set.

So we want to split the direction of the project from its management. The three of us would still be giving the project direction however the part of the management would be given to Mishka and part to team members themselves. This should free up some of our time which we can dedicate to programming / art as well as allow us to be outside of the office more (summer is coming =)).

We imagine that this would be achieved partly by cleaning up the Trello a bit. We (product owners) will need to spend more dedicated time making sure that the cards, priorities and assigned devs / artists in the Trello are well defined. On the other hands this frees our hand because when a person is finished with a task he / she will know what to do next.

Another thing we intend to improve in this area (overlapping with the next area) is the code reviewing process. At the moment most of the code reviewing is done by Michal in a kind of random manner (he reads some commits but not all of them). The goal would be to have code reviewing across the team. We are still looking for a simple and efficient tool to achieve this (let us know if you have any recommendations).


We are not after moving forward as fast as possible at every cost. Balance is more important in our eyes - moving forward while still enjoying the work. However recently there has been quite a lot of distractions around the office and we feel it is time to start looking into this.

Haha, a good example from the real life. Just before I was about to write the next paragraph, in the room next doors there were two people programming and one shooting nerf gun bullets around (consistently hitting monitor of his college who was coding =))). This can be a good fun now and then, things like these decrease productivity not only of people involved but pretty much of all the people in the vicinity (most of the office). Again it is about finding balance.

So we are after decreasing distractions in the office a bit. We have started using Slack and encouraged people to use it to communicate to others when the face-to-face talking is not necessary. Besides that, it comes down to being mindful about whether my actions (i.e. sharing the latest news from the web by shouting them out in the room, having fun with colleague at his computer) are not disturbing others too much.

Another aspect would be the oblivious "fight against procrastination". However we don't feel this is such a big issue at the moment. Hopefully all of the people here have a strong internal motivation to work on the game and make it as good as possible which should take care of this on its own.


Ok so let's have a look at some progress at actually making Factorio and not only trying to get real making it. For quite some time Michal (posila) has been playing with fire and flamethrower turrets. Vaclav has been doing the art for these. This is quite a big subject which deservers a blog post (or substantial part of it) of its own and it will come in the near future. But to give you a bit of a sneak peek into the process you can checkout the hi-res render of a model of the flamethrower turret below:



Maybe more than usual, we are curious about what you think. If you have any comments or tips regarding the areas mentioned above please let us know on our forums.

Hello all,

Originally I intended to dedicate most of the post to the technical aspect of our new Multiplayer User Authorization mechanism that I have been working on in my programming time. Then I thought, hmm it would be nice to start with some project management changes that we are looking into and experimenting with. Then I pretty much ended up making a full blog post about that =) It might give you an interesting insight into issues that we are dealing with. The Multiplayer User Authorization mechanism will definitely be described in one of the future FFFs.


As mentioned in the previous FFF there is a new team member here with us. Her name is Michaela (or Mishka) and one of her main responsibilities is to get us a bit more organised=)

At the moment we are 11 people in the office with 2 external collaborators. Our short/midterm goal is to grow to about 15 people in the office (we are still looking for good C++ programmers ideally from Europe!).

Our approach to "project management" so far has been very loose and organic. Somehow we feel that we have reached a boundary here and need to start working a little bit on our methods of working together, sharing the results of work, etc. This especially holds true with our (moderate=)) growing ambitions.


So we spend quite some time brainstorming and figuring out what we believe is working well, what could be improved and where we want the things to go. We came up with 3 basic themes / areas for getting organised. In short these areas are: Transparency and knowledge sharing, Direction vs. management, Productivity. Let's have a look at the descriptions for all of these.

The next step was internally clarifying three aspects for every area:

• What is the current situation and why we want to change it.
• What is our goal.
• What tools and processes can we use to achieve the goal.

We are very aware that changes like these can be sensitive. Especially when we start using words like project management, goals, processes, etc. So our main criteria for the whole set of changes is to not overdo things. This means make small changes step by step and stop when we have achieved our goals. Also we are aware that processes and tools are here to serve us and not the other way around so we will try to keep our minds open and abandon things that won't work for us.


Till now, often a developer would work on a task for quite some time without too much interaction with others. Hence there was a lack of feedback on how he is doing, if he is stuck or not, if what he is working on might be related to what a different dev is doing, etc. So far our main tool of communication has been talking in the office / at lunch and Trello cards. Trello has worked really well for us, but it is getting full of cards, generally messy and often there is little information for particular cards and so on.

Ideally we are after a situation when people have a general overview of what others are working on. We are still small enough to do this for the team as the whole (imho it becomes harder for teams of 20 or more people). This should also improve productivity (people can help each other in case they know how to solve an issue someone else is stuck with).

We started by having a short stand-up meeting twice a week (currently Monday and Thursday at 1 p.m.). The meeting (ideally) takes about 15 minutes, requires all the team members to be present and standing (to keep the pace going). We start by announcements if there are any (this and this person is coming for probation, we have made this and this presentation, etc.). Afterwards we go in a round and everyone gives a brief status. This means: what he is working on, if he is doing ok or is stuck, if he needs to communicate with other people, etc. This takes (ideally) less than a minute for a person. In the near future we intend to have "minutes" (short transcript) from the meeting in the written form to inform (and gather feedback) from the members not present.
The main inspiration for stand-up meetings came from my pre-Factorio (so long ago :D) programming job in Amsterdam, where it really helped us as a team of about 12 developers.

Another potential change we are looking into here is become more verbose in our Trello cards. This would mean giving proper description to cards, links to forums or other related cards, using checkbox lists, etc.


So far the project direction and project management "roles" have been concentrated in the hands of the same people (kovarex, me and Albert). This makes sense for very small teams however it is also quite limiting. The basic issue here is that the direction is more like a vision (I imagine a person who knows where the ship should go) while management is more like an every day task making sure that the ship actually goes where the direction has been set.

So we want to split the direction of the project from its management. The three of us would still be giving the project direction however the part of the management would be given to Mishka and part to team members themselves. This should free up some of our time which we can dedicate to programming / art as well as allow us to be outside of the office more (summer is coming =)).

We imagine that this would be achieved partly by cleaning up the Trello a bit. We (product owners) will need to spend more dedicated time making sure that the cards, priorities and assigned devs / artists in the Trello are well defined. On the other hands this frees our hand because when a person is finished with a task he / she will know what to do next.

Another thing we intend to improve in this area (overlapping with the next area) is the code reviewing process. At the moment most of the code reviewing is done by Michal in a kind of random manner (he reads some commits but not all of them). The goal would be to have code reviewing across the team. We are still looking for a simple and efficient tool to achieve this (let us know if you have any recommendations).


We are not after moving forward as fast as possible at every cost. Balance is more important in our eyes - moving forward while still enjoying the work. However recently there has been quite a lot of distractions around the office and we feel it is time to start looking into this.

Haha, a good example from the real life. Just before I was about to write the next paragraph, in the room next doors there were two people programming and one shooting nerf gun bullets around (consistently hitting monitor of his college who was coding =))). This can be a good fun now and then, things like these decrease productivity not only of people involved but pretty much of all the people in the vicinity (most of the office). Again it is about finding balance.

So we are after decreasing distractions in the office a bit. We have started using Slack and encouraged people to use it to communicate to others when the face-to-face talking is not necessary. Besides that, it comes down to being mindful about whether my actions (i.e. sharing the latest news from the web by shouting them out in the room, having fun with colleague at his computer) are not disturbing others too much.

Another aspect would be the oblivious "fight against procrastination". However we don't feel this is such a big issue at the moment. Hopefully all of the people here have a strong internal motivation to work on the game and make it as good as possible which should take care of this on its own.


Ok so let's have a look at some progress at actually making Factorio and not only trying to get real making it. For quite some time Michal (posila) has been playing with fire and flamethrower turrets. Vaclav has been doing the art for these. This is quite a big subject which deservers a blog post (or substantial part of it) of its own and it will come in the near future. But to give you a bit of a sneak peek into the process you can checkout the hi-res render of a model of the flamethrower turret below:



Maybe more than usual, we are curious about what you think. If you have any comments or tips regarding the areas mentioned above please let us know on our forums.

Hello Factorio players!

Cube is working on the udp download rate with high packet loss. Michal and Vaclav are tweaking the flamethrower mechanics (You will like this one). Robert is working on the circuit network improvements. Tomas is working on the authentication service. Albert is preparing the new train graphics which will solve the horizontal/vertical inconsistency explained in the last Friday facts. Ondra is implementing control interface of the headless server and Martin is mainly cooperating on the integration of the mod portal.
Most of these topics will be described in detail in a future Friday facts once they are finished.

Miska is our now project manager on a testing period. We (Tomas and Me) decided to delegate some of our responsibilities to someone else, so we have more time for programming and game design. Her responsibilities will be to keep the track of the ongoing projects in Wube, help us to optimize our working processes, help with administrative and business tasks, possibly help us to optimize the bug fixing process and other similar tasks.

Let me explain the process of a small task I decided to do during Sunday afternoon for 0.13, which grew to a week of work.

The problem with signal building, is that it is not clear where can the signal be built, especially on turns like this:





So the first obvious step was to show the possible positions of the signal placement, to spare the player searching for those by moving the cursor around. The indicator shows only positions around the cursor (20 tiles radius) and it looks like this.




This is a nice improvement already, but once we have it, we can go further.
The typical misunderstanding, is that people don't understand why is this signal blinking:



Signals as well as junctions always divide rails into segments. A segment is a rail with one beginning and one end, with no junctions and these segments are grouped into blocks. Two distinct blocks need to have signals on the border with the other blocks, and can't have any collisions with rails of another block. This is to make sure that a train on one block can never collide with a train on another block.



The problem with the junction, is that the curved rail collides with both the left and right segments, so it merges all of the segments into one block. This renders the signal to be useless, as it is not dividing anything.



Placing signals on these positions makes no sense, so I extended the indication and building checks, to not allow the building of useless signals in junctions. This also makes it perfectly clear, what is the closest safe location after a junction to build the signal:



Once I was done with that, I remembered another annoying issue that arises when building signals. The direction problems. One small and often hard to find error can cause a lot of confusion. It is especially important with a one way rail system, which is used by most people in the late game stage.
Signals like this make no sense, as there is no exit point from the center segment:



So I decided, that it won't be possible to place a signal in the opposite direction as long as there is no exit from the block in that direction. The signal can be always upgraded to a 2-way signal, by building a signal on the opposite side (the grey marks). As long as it is not done, the indicator will only show the placement on the correct side of the rail and won't allow incorrect placements by accident. This is especially useful when signaling junctions like this:



From the little testing I did, this is going to be one of those changes that will make us wonder, how could we play without it before?

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

Hello Factorio players!

Cube is working on the udp download rate with high packet loss. Michal and Vaclav are tweaking the flamethrower mechanics (You will like this one). Robert is working on the circuit network improvements. Tomas is working on the authentication service. Albert is preparing the new train graphics which will solve the horizontal/vertical inconsistency explained in the last Friday facts. Ondra is implementing control interface of the headless server and Martin is mainly cooperating on the integration of the mod portal.
Most of these topics will be described in detail in a future Friday facts once they are finished.

Miska is our now project manager on a testing period. We (Tomas and Me) decided to delegate some of our responsibilities to someone else, so we have more time for programming and game design. Her responsibilities will be to keep the track of the ongoing projects in Wube, help us to optimize our working processes, help with administrative and business tasks, possibly help us to optimize the bug fixing process and other similar tasks.

Let me explain the process of a small task I decided to do during Sunday afternoon for 0.13, which grew to a week of work.

The problem with signal building, is that it is not clear where can the signal be built, especially on turns like this:





So the first obvious step was to show the possible positions of the signal placement, to spare the player searching for those by moving the cursor around. The indicator shows only positions around the cursor (20 tiles radius) and it looks like this.




This is a nice improvement already, but once we have it, we can go further.
The typical misunderstanding, is that people don't understand why is this signal blinking:



Signals as well as junctions always divide rails into segments. A segment is a rail with one beginning and one end, with no junctions and these segments are grouped into blocks. Two distinct blocks need to have signals on the border with the other blocks, and can't have any collisions with rails of another block. This is to make sure that a train on one block can never collide with a train on another block.



The problem with the junction, is that the curved rail collides with both the left and right segments, so it merges all of the segments into one block. This renders the signal to be useless, as it is not dividing anything.



Placing signals on these positions makes no sense, so I extended the indication and building checks, to not allow the building of useless signals in junctions. This also makes it perfectly clear, what is the closest safe location after a junction to build the signal:



Once I was done with that, I remembered another annoying issue that arises when building signals. The direction problems. One small and often hard to find error can cause a lot of confusion. It is especially important with a one way rail system, which is used by most people in the late game stage.
Signals like this make no sense, as there is no exit point from the center segment:



So I decided, that it won't be possible to place a signal in the opposite direction as long as there is no exit from the block in that direction. The signal can be always upgraded to a 2-way signal, by building a signal on the opposite side (the grey marks). As long as it is not done, the indicator will only show the placement on the correct side of the rail and won't allow incorrect placements by accident. This is especially useful when signaling junctions like this:



From the little testing I did, this is going to be one of those changes that will make us wonder, how could we play without it before?

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