Hello,
we have written a lot about multiplayer in the past weeks, it started by the reports at the beginning of the rewrite, and now it finishes with our reports of mega games being played. But as most of our time still goes to bug hunting to achieve 0.14 stable as soon as possible, I just can't help myself:
As we watched the stream of big multiplayer we mentioned in the last fff, we decided to participate and help organize another big multiplayer event. Even though the server provider we rented from for the event was DDoS'd at that time, it was still a success. During the event, we did profiling as the game was running, and we learned a lot of valuable information.
The Factorio internals always have to be programmed with knowledge of quantities. Transport belts need to be optimised a lot, as there are tons of those on the map and they eat a lot of the CPU time. On the other hand, the time to simulate the players was never really a problem, since there were always at most a few players on the map at the same time. This paradigm was changed a lot when we profiled a replay with 300 players and found out that big part of the CPU time is spent on things like searching for gates to be opened or searching for items to be looted etc. These things are not hard to optimise, but we just didn't know we should do it until now, so it is work in progress.
Several other needs emerged, like changing the server settings (password/max upload rate/max players) on the fly as the game is played. Postponement of the map saving for incoming players, so the server saves once in a while for more people at the same time, instead of saving every 3 seconds when someone wants to join a crowded game. The admin options also had to be improved etc. etc.
Then it comes to further and further optimisations of the network traffic so more and more people can play at the same time. The problem with this is, that we could do it forever, we wanted 20 or at most 50 players to be able to play in the new multiplayer, but we reached 350 and now we are optimising it so more than 400 could join, and if we achieved that, we would go for 1000. But are we still doing something that improves the gameplay, or just trying to win the race with ourselves at this point? We need to realize that our goal is not to make some MMO, but to have a good single player game, that also have a decent multiplayer. So the conclusion is, that if the game supports 200 players with a good connection it is more than enough. It can go higher but we won't aim to increase it much anymore.
After hour or two, the main bottleneck is not the players or the network traffic. The factory grows at a cosmic speed in these megagames, so the CPU time needed to simulate it becomes the problem. By changing our focus to general factory simulation optimisations, we not only make it possible to play massive multiplayer games better, but we also allow to build much bigger bases in singleplayer as well. The belts optimisations and multithreading are worked on, but far from being finished.
As we have been asked many times, I probably need to answer again: Yes, we will add the liquid wagons in 0.15, but it won't be that simple. As we want to have the pump and wagon connection to be organic, we need the pump to connect to the wagon. But as the geometry of our trains is wicked the connection points on the wagon won't be regular in vertical directions. We are making a 2d game so we have to prepare 6 different animations for every relative position of the pump. Albert had doubts if it is worth it as we always have to try to keep our video memory bill reasonable, but I believe it will add a nice touch to the game.
|
|
One of the 0.13 changes was change of the map generation. As part of it, it happened that the game is suddenly generating a lot of more of the decorative entities. It often looks like this:
It looks nicer, but the problem is that there could be tens of millions of these on big maps, which can multiply the size of the save and ram required to hold it.There is even a mod that removes them completely to solve the issue. We were discussing solutions of this, and we will probably just change decoratives so they are not regular entities anymore. They would be a special type of an object that is not saved in the map, but generated on the fly when the player walks around. They would be saved per chunk in a very compressed format so it only takes 3 bytes of memory per decorative instead of approximately 300 bytes when it exists as an entity. This will also improve performance, as when some code is checking entities in some perimeter, it wouldn't have to iterate through tons of these decoratives uselessly. As these changes are too big to be added into the 0.14, we will probably just reduce decorative generation in 0.14 and do this change for 0.15.
As always, if you have any comments or otherwise, please let us know on our forums.
