You would expect that we wouldn't have anything new during christmas, but you couldn't be more wrong, as the Factorio development never stops.
For 0.11.7, Tomas prepared the parallel saving/loading which is needed to be able to notify other multiplayer peers about the progress of saving/loading the map. Until this was done the long saving/loading times for larger saves could cause the other multiplayer peers to think, that the player was disconnected. This practically prevented people from playing larger maps. But, there was an error, that caused that in multiplayer, the game wasn't stopped for saving the game. You can imagine, that practically anything can happen when you simulate the game in one thread and save it in another at the same time: crashes, corrupted save games, freezes etc. I created several new bugs as well by moving to the fixed point representation of position.
Generally speaking, the 0.11.7 was a disaster, so we had to work during weekend to make a fix release on monday. 0.11.8 fixed the saving problem in multiplayer as well as several other problems, so we were able to connect 8 players in a single game in our office using a 60Mb big savegame and everything worked correctly.
The multiplayer still can't be marked as stable, but we are going to climb the wall soon :)
We were talking about our plans for the next big release two weeks ago. We received a lot of reactions, that having an ending where the player just becomes a rich bastard isn't enough for Factorio. That Factorio deserves better. We learned that listening to opinions of our players, mainly when they have strong arguments is a good idea. So we decided that the endgame will have a different motivation and ending. But we are quite sure that the ship building concept is a good thing, so it will definitely stay. Other thing we are planning for 0.12 is the extension of the circuit network. The extension of the network usability is based on 3 things. a) More sensors b) More recievers. c) more options to manipulate the signal.
I started with some basic steps two weeks ago and I managed to do a lot of other tricks to reduce the size of the save files. One of the trick is based on the fact, most of the time, the currently saved position in the world is nearby the last position saved. So the position is saved as relative vector from the last saved position and only 2 bytes instead of 4 bytes are used for one coordinate. We use 8 bits for fractional part, so it covers area of 256X256 tiles. If the last position doesn't fit into this area, special value is used as a sign, that the absolute value of the position needs to be specified, but 99.99% of positions are in the relative area of the last saved position, so this basically halved the data representation of position in savegame again.
I also experimented with bit-buffers, as it allows to save individual bits. It is possible then to save one bit instead of whole byte to save a boolean value for example, but it confuses the zip compression logic so much, that even though the uncompressed file size can be diminished, the compressed rate is so bad, that it is not worth it overall.
We are using palette when saving minimap data (1 byte instead of 3 byte rgb) and we are also specifying the count of repeated pixels of the same color. Several other things like that were done and the file size was reduced significantly, the zipped size of the save dropped by 53% in our testing saves, but it can vary and it depends on the contents of the save. The experience is, that using these context based compressions is much more time effective that the contextless zip algorithm. It is still worth to use the zip compression for the saves, but as the level data is so much smaller, the compression takes less time so the savegame time is reduced, which is important mainly for reduction of the autosave hiccups.
The first sketches of the space technology.
The regular comment thread at our forums is ready.