Hello,
we have only 2 weeks left before the 0.11.0 release date. It is scheduled to 31. october. All the things in progress are starting approach the finish line, but as always before the release, it will be tight.There are quite a lot of things we want to deliver and multiplayer (mainly for lan and low ping games until 0.12 don't forget!) is one of those, not even mentioning the backlog of bugfixes we need to go through before the release.
My week was dedicated to the implementation of the gates. It would be shame if we forgot so useful addition in the hassle of the multiplayer stabilisation. The gates are almost finished now, and they make me very happy, so the preview picture of those is the rough visualisation of our new office.
We noticed soon , that we also need the gates for the trains, because that would be the biggest hole of the fortification. So here is the preview (not integrated in the game yet) of the graphics plan for the train gate.
| Opened: |
|
Closed: |
|
The rail gate opens for the trains owned by the same force. There were some complications (as always) that needed to be solved. When the train runs in automatic mode, it is quite simple. As the train runs, it looks ahead along the path and activates all the gates far enough so they can be opened in time. The problem is, when the player is riding the train manually.Take this situation as example (note that I'm using the normal gate graphics ingame as provisional):
Until the last moment, the gates don't know which way you want to go. So to make sure you don't crash the unopened gate, all gates on all possible paths are opened. You can see few of the gates already opening on the picture, and all of them will open eventually even when the player decides to go straight.
One of the problems I had when implementing the gates was, that when the shadows overlap, they make ugly "double shadow" areas. This is best visible on the picture of the tank. The turret needs to be drawn separately, as it can rotate independently, the resulting shadow shows the overlap of those two objects.
So I had to make a method, where the shadows of some objects can be drawn separately into one picture as 100% black shapes. Once the shadows are merged in the picture, they are drawn on the screen with 50% transparency and tadaaaa ... all the overlaps are gone.
It was quite annoying to see the visualisation of roboport connections when there were a lot of them on the screen.Mira finished his task of making the connection visualisation as triangulation, instead of drawing a line between every two neighbours. Here is the comparison of the results (you can imagine, that the difference is even much higher in more roboport crowded areas).
We tried to play our ongoing multiplayer game for a while, and we found and fixed 3 different synchronisation bugs. One of those was the typical problem (related to enemy expansion planning): When you call method foo(random(), random()), the C++ standard doesn't define the order of evaluation of the parameters, so on different platforms the result values given to the function can be switched. The other desynchronisation was actually quite serious bug that is in our current stable version as well. When you load a save with assembling machine emptying a oil barrel, the fluid accumulated in the assembling machine is lost in the process of loading the game. We hope to finish the ongoing game during next week, so we know that getting through all of the phases of the game in multiplayer is possible. Lets hope it will not work only for us :)
The regular comment thread at our forums is ready.
