Hello captains, it’s been a while since the last official post of NavalArt, despite the last public update released in the last year. the game is getting regular updates in the test branch during these months, (If you don’t know how to enable the test version, just use code “navalarttest” in the property option of the game library)
For those who have already entered the test version, you may have noticed it has stopped getting update for several weeks, this is due to I am currently working on the multiplayer framework of the game, which basically changed the deepest structure of the game.
[why multiplayer?]
At first, I was working on the cv for sometimes and meanwhile I was trying to build the structure for the multiplayer function, I found the game’s currently structure is not very suitable to introduce multiplayer on it, this means I may need to rewrite the whole anti-air, missile and aircraft system to match the requirements of multiplayer, which will be described more detailed in the content below.
That should also be the same reason that why some great sandbox games like Kerbal Space program, Simple Planes doesn’t have official multiplayer with them, that a game with multiplayer should be a multiplayer game at the beginning of development, as the running logic it required is very different from a single player game. It could be a very difficult problem even for a whole indie game team, while there is only one person works for our game, but since I have promised you guys about it and have multiplayer on our roadmap, so I won’t regret it but rather to take the challenge.
The thing turned to be if I add aircraft carrier systems to the game first, I need to rework it again when the game needs to add multiplayer in the future, so I decided to put multiplayer on a higher priority in the development. The good news is, if nothing goes wrong, we are able to get a multiplayer with turrets and torpedos working in the next test version since missiles and aircraft system should be reworked for the multiplayer), at the beginning of February.
By then I will release a new test branch without code requirement, finally we will be able to fight with our friends with our ships.
[Chanllenges]
In fact NavalArt is a sandbox game, players are able to design ships freely with a lot of ordnances on one battleship, like turrets, torpedo launchers, missiles, aircrafts, for example.
You could think about the multiplayer war games you have played, there will be not many units per round, otherwise it will need a strong dedicated server to work in the background. NavalArt is aimed at using Steam P2P network for multiplayer, so the bandwidth is even more limited, it’s just impossible to synchronize all the units between players in the current state.
[Let’s do some math]
For example, if there are 200 planes exists in the battle, the game synchronizes them at 10Hz, which is 10 times per second.
Assume that we need to transmit the rotation and position of each aircraft:
Position: 12 Bytes
Rotation 12 Bytes (For a quaternion, it’s 16 bytes)
So each aircraft costs 24 Byte for its current state in total, when we put it into the formula, it will be :
(12+12)*10*200 = 48000 Bytes/S = 46.875 KByte/s
Although it seems small when comparing to the bandwidth when we streaming videos, this is a very large bandwidth for a game, to name a few, Cs:go will costs 60 KB/s when running a 10 vs 10 casual game, a typical bandwidth usage of a Steam P2P game should be around 30 KB/s for smooth gameplay, and in NavalArt players could even add more than 200 planes on their ships.
[Solutions]
For turrets and torpedo launchers, there won’t be much problems, since their movement is deterministic, as it will have an initial speed and direction at launch, under the same circumstances it will have a same error on all clients, so the server will only need to tell every client, ok, generate a bullet/ torpedo at there, and all the clients simulate them simultaneously. When the bullet/torpedo hits something, the server tells the client to destroy the weapon, that’s all, they don’t need to be synchronized all the time.
For missiles or aircrafts, the situation is distinct from above. You might have played some RTS games, in which a lot of units could be controlled by one player over the internet, even thousands of troops. You might wonder how that is possible after we have done the math. There indeed exists some magic.
So the answer is these RTS games are all using the same technique which is named deterministic lockstep, that means no matter which pc it runs on, it will give the same result with the same user input. Only user inputs are getting transferred over the network rather than the status of all units, hence it could run well with a little bandwidth, doesn’t it sound like magic? (One famous game on Steam which is “Factorio” also has used this technology to synchronize thousands of units)
You might think we could add this to NavalArt, however, it is not very practical to do it.
Firstly, NavalArt uses float points to do all the math, which might have some error as the number goes larger, so it will not be deterministic with the same user input, meanwhile deterministic lockstep requires the game to run at the same speed as the other player’s game you are playing with, which will produce many fatal cons, if you have played networked RTS game before, you might encountered the situation that the game gets laggy with a tip: “some player is slowing the game down” or you get disconnected with the error : “You have been desynchronized” . There is also many other reasons that NavalArt couldn’t using this method for multiplayer.
To solve the network problem, we need to reduce the usage of the precious network bandwidth, which means to introduce multiplier with the current missile and aircraft system is nearly impossible, they will need to be reworked, but it won’t take very long since some code like animations could be reused, that’s the reason we are only getting basic functions for multiplayer weeks later and it’s in a test branch, since it will produce a lot of errors if we use single player code directly in a multiplayer game.
You may have noticed that planes in the current version will go through mountains, it could also be solved under the rework of aircraft systems, as the map will be quantized into grids, and it will be easier to add a path finding or an obstacle avoidance into the game, planes will also be able to fly in formation since the grid could occupied by one plane and other planes could detect it.
Using a grid based system will also reduce the network usage dramatically since only the grid coordinate needs to be synchronized, which is obviously smaller than a 3-dimension vector when using the power of two to represent it, as the latter vector is 12*8 = 96 bits, the movement of the plane could also be performed by using interpolate between girds.
There are also a lot of other technologies like delta synchronization, data compression that could be used for the multiplayer system, so please be patient, the game won’t be given up, it will get better and better gradually, as it was during the past years.
[In the End]
I hope you like the post which described the general problems and solutions for the game in the current stage. We will meet again at the release of the multiplayer test version soon.
(Credit: Photo by Julius_Tetsuo, 肄业遮目)
