Friday Facts #64 - The plans

Posted by kovarex on 2014-12-12


we have a nice anniversary of the friday facts today, as we have one friday facts for every bit in the 64bit architecture address size. I believe this is the best time to show some of the 64 pixels per tile graphics experiments as well.

The light at the end of the tunnel

The (multiplayer) bugs queue was reduced a lot, we are down from 122(last week) to 90, but mainly, it seems like most of the desync bugs, which were hardest to fix are mostly gone. People are reporting 50+ hours game in multiplayer without big problems (well at least two of them exist ^^) which makes me feel that the hard work was really worth it. They are certainly lot of fixes to be done for the multiplayer, but the list is not so scary now. Namely, Tomas is doing final fixes of the multiplayer friendly loading/saving of the map. The problem is, that when the player is saving the map (the typical problem with the autosave->desync), he is not sending any communication to the other players. The same when the player is loading the map he downloaded. This is especially problematic when the save file grows, as the saving/loading times can grow a lot. To solve this, the loading/saving is going to be done in different thread, so the player can inform other multiplayer peers about the progress of the saving/loading, so they will even see the progress bar of it. Also there are several corner cases we need to solve, like player dropout during some synchronisation processes (the game might get stopped forever). The conclusion is, that we believe we might be able to deliver the stable for 0.11 until the end of this year.

The savegame file reduction

We have been thinking about ways to reduce the save game file, but it became much more important with the multiplayer, as the reduction would fasten the download times. There are many things we can do to make the savegames smaller. The first step I'm currently experimenting with is using the fixed-point float numbers for in-game positions. Currently we use the double type for coordinates of the position, which takes 8 bytes per value, and doesn't really follow our needs as well, as it is very (wastefully) precise around the center of the map, and the precision gets smaller the further you are (double format). The solution is to use 4 byte number for the position coordinates, 3 bytes for the integral part and 1 byte for the fractional part. The precision is still good enough for any practical ingame use (8 values per pixel), and the span will be kept reasonable big -2^23 to 2^23 which is above 8 million tiles. I made special huge save for testing, and the size reduction using this technique was 27% of the zipped file. The good thing is, that this also reduced the memory requirements and enhances the cache locality, so the performance is increased (very slightly) as well. There are more quite simple tricks we would like to use to reduce the savegame to half of what it is now.

The plans for 0.12

Now, when the stable for 0.11 is starting to look possible, we can start to talk about our plans for the 0.12. The main thing planned for 0.12 is something we were referring as "The endgame content" that would replace the current cheap ending of the game. Once the player reaches the corresponding level of technology, he will be able to build rocket bases + rockets. But not those small rockets used for fighting enemies, but huge rockets used to get things into the orbit. Once he gets something on the orbit, he will use the material to build the spaceship there. The building will be similar as in normal game, but the player will first have to build the foundations (space platform) first. The platform will get the more expensive the bigger it gets. The player will then put all the needed machines, engines, and the valuable stuff on the ship. Once he is ready, he will start the ship. The ship will have to survive the trip on itself, it will have to contain small factory setup to process the energy and materials found on the way. It will have to provide the defense from all the asteroids and other dangerous stuff it can encounter. Once it reaches its destination, the valuable cargo can be sold at the local galaxy market. Once the player sells enough of the stuff, he won the game by becoming a rich bastard. No saving of the planet or the race, we decided to go for much more realistic storyline :) There are other plans for the 0.12 but let's keep it for the future friday facts :)

The Factorio next gen experiments :)

Once we took a look a the picture of the car from the last friday facts we were convinced about something we were also dreaming some time. Lets try to make higher resolution renders of some of the entities in the game. The main reason to not use it in the official release is, that the graphics card memory requirements are already quite high, but when someone already has 2GB or 4GB graphics card, why couldn't he enjoy something extra. So we decided to experiment with 2 entities for starters (the car and the steam engine) to see how it works in the game, and if it is worth it, we will make a high-resolution pack as official mod. It would be turned off by default with warnings about the graphical memory requirements, but people could run it if their hardware can handle it. Making the highres versions of the entities is quite easy, as we just have to render it again with higher resolution ... but lot of the models are not made with such attention to detail, as they were optimised for the normal resolution renders, so it would need some tweaks.

The comparison of the normal resolution render versus the double sized resolution speaks for itself.

The regular comment thread at our forums is ready.