Friday Facts #61 - Into India

Posted by Tomas on 2014-11-21

Hi there,

we spent quite some time at the GDSession last weekend. The conference was fun, but a bit tiring. I think we are not used to meet many new people at the same time anymore. And there were tons of new people:) The talks were unsurprising but we enjoyed chatting to small indie studios sharing similar challenges we do. And they had great cakes for refreshement:)

Factorio going to Mysore

So I am going to India. Next Thursday. For two months.

I haven't had proper holidays since I started working on the game. Therefore I decided to take some time off this winter. Incidentally, I have started practicing yoga in the beginning of this year and it helped me a lot to stay fit, sane and productive. Therefore, when looking for travelling destination, the cradle of Yoga (India) has been an obvious choice. I will be staying in one place all the time, namely the city of Mysore. I will participate in a Yoga course there. Two sessions every day. It will be pretty intense, still the schedule should allow me to spend couple of hours a day working on the project. We will see how it goes. It will be another experiment in remote working. Stay tuned for news from the Asia:)

Step by step

The development in the past week has been focused mainly on extending our testing suite. Kovarex spent quite some time with a concept called heavy test mode. This basically means following for all our testing scenarios:

  • Copy of the map is made (so we have identical maps map1 and map2).
  • The copy (map2) is then saved and loaded again.
  • It is checked whether map1 and map2 are still identical (they have same CRCs).
  • One update run is simulated for both map1 and map2 and then CRCs are compared again.
We have rather high hopes for this mechanism in finding determinism bugs. It should catch any bugs related to unitialized variables or logically corrupted game state. It will not find the cross architecture / operating system issues, but we have other mechanisms for this in place. So now we "just" need to write enough tests to cover problematic scenarios:) Already this mechanism lead us to find an error in Boost Binomial Heap implementation which we use in our Path Finder.

I have been spending time making our multiplayer management code (connecting, synchronizing, map sharing logic, etc.) testable as well. This is great because now we can just fire up 3 virtual clients in the test, simulate their behavior and see what the results are. Before, this has been done manually (running multiple game instances) and it was slow, error prone and not easily reproducible. Also some of the edge cases were virtually impossible to simulate. Multiplayer tests led us already to finding and fixing the issue with desync / crash when multiple people would connect to the game at the same time.

Hunting for developers

Despite our hiring efforts we are still only three developers (me, kovarex and blue cube). Which is painfullly little considering the code complexity and amount of work to be done. Also all of us have additional (but Factorio related) tasks which makes things even harder. That is why we have been looking for developers for a while. Maybe we are too picky, but we really want to make sure that our core team is a well-knit and efficient code-spitting gang:)

The good news is that we had a guy from Romania called Robert here with us last week to work on the game. We were really happy with what he has done and he seemed to enjoy working on the game with us. The result is that we made him an offer and he agreed to come to Prague to work on Factorio full time starting February 2015.

During our hiring "process" we would often spent quite a bit of time in skype interviews leading nowhere. As a result we started using codility recently to let people show off their code-crafting skills on our selected c++ coding test.

Diving into Blender

Moving into the new office has had a great advantage of reconciling our "graphical department". Our artists Albert and Pavel are now sitting in the same room which makes their communication and working process overall way smoother.

Albert has been using Blender to create all the 3D assets (which are then rendered into sprites used by the game). It is a great tool but it is a bit tricky to find artists with active Blender working experience. Pavel has most experience with Cinema4D but he agreed to switch to Blender in order to keep the project assets consistent. It makes the workflow much easier if those guys can easily share the models, textures and also the know-how. So Pavel is diving into the depths of Blender these days. One of the things he has been doing is migrating the tank (which has been done in Cinema4D originally) to Blender. The tank will probably get a cooler color mask in the process. Below you can see the screenshot from the process.

As always the thread for comments is ready.