Part 1: http://ftr.wot-news.com/2014/07/18/world-of-tanks-client-analysis/
Part 2: http://ftr.wot-news.com/2014/07/20/world-of-tanks-client-analysis-part-2/
Part 3: http://ftr.wot-news.com/2014/07/22/world-of-tanks-client-analysis-part-3/
Author: Thiemo Jung
Network and other community requests
This part will cover multiple topics, all from user requests of the WoT community.
Firstly I will cover the network traffic, I’ve recorded the network traffic with Wireshark. The network part is mostly reasoning about the frequency, the size, looking at undecoded content of the network packages and some guessing. The other user requests are, behavior if the process priority gets changes, behavior when minimized and rendering of the new maps (in this case Kharkiv).
Some people requested a analysis of the servers, unfortunately this is not possible, I have the same access to the servers as everyone else and can only use tools to view stuff from the client side and this allows only a very limited view of the server structure.
Network
On starup, the client goes to http://rss.worldoftanks.eu (and probably .asia for Asian, .com for us, .ru for Russian client), with added language sub path (eg /de for german). The requested rss feed contains only on entry, a link to the World of Tanks page. I assume this will contain some patchday related data, but that is just guessing.
After you click the login button, the client will DNS lookup all related login servers (each cluster seems to have its own) and pings them over UDP multiple times and then sends its login data to one of them (probably the with the lowest ping and/or lowest users count).
On success, the client receives a blob of data, probably the address of the server node where the client gets transferred to and some extra data, probably some transfer handshake data.
Immediately after that, the client sends data to its assigned cluster server node. This one UDP (UDP is used for speed instead of TCP) port handles all data transfers and stays open until the client gets closed.
After the transfer is complete the client receives again a blob of data, probably containing the entire account data set. On every tick (20Hz) data is send back and forth, between client and server, this seems to be a keep alive and/or ping mechanic. It seems that the client send this data set every time, regardless of being in hangar or battle mode.
At start of a battle, the client receives multiple blobs, containing every data it needs to set the initial state of the battle mode, which is the data about all participants, their tanks and spawn position. While the countdown ticks down, the client sends it standart keep alive packet, the server sends data back, with some parts always the same and other parts are different. I assume the part that is always the same, is some sort of delta compressed state of each tank, and the different data is info about the clock, the clients that have finished loading and some other data that needs to be kept in sync.
After the countdown reaches zero, the client starts to send an additional packet almost every tick, always with the same size. This is probably the processed user input in some form, probably the state (tank position, tank rotation, turret and gun direction) in which the client wants to be. The data send back from the server gets larger too, because every tank is now user controlled and changes its state every tick.
The average memory size of each packet sent from the server is about 7 to 10 Bytes per tank. This is surprisingly low, which indicate a good optimized (for size) net protocol. With this low number, I assume that only visible tanks are send to the client (this would make cheating in that regard impossible too).
It seems the network protocol is straightforward, without different variations for projectiles and other stuff, unlike in some other games (eg Halo: Reach has special protocols and prioritisation for grenades and projectiles), this is a very solid approach done since ages (see Quake 3 source code for an example).
But beware, some if this is deduced through some experience that i’ve gained through network programing and studying of other code bases (like quake 3 source code), so take this analysis with a grain of salt.
As an interesting fact, I’ve noticed during my rendering test sessions for the previous parts. When I took a frame snapshot, which took several seconds, my ping did go up to 999 and the game never recovered and I had to kill and restart it to continue the match (i did this during countdown, no worries :)). This indicates that the network is handled in the same thread as the rendering, which is a common design. They could move this to a separate thread, the question is, is it worth the trouble. Moving stuff from single threading to multi threading can cause many sync issues that eat all the possible gained performance and even can degrade performance.
Effects Of Process Priority
By changing the process priority from normal to height, I’ve gained less than 5% fps on both old and new rendering modes. This is probably very situational, it can help especially if your system is at nearly 100% cpu usage. It will also not help, if your system is capped by your graphics card.
Behavior When Minimized
When minimized, WoT stops rendering resulting in 0% graphics card usage, cpu usage drops to 1-2% only processing the network so that the client does not get disconnected, this is even less than fmod uses to mix the audio. So you can safely minimize it and it will not burn down your system.
Rendering Of New Maps (Kharkiv)
I’ve logged a replay of Kharkiv with the new renderer. I’ve noticed not any significant differences, but this is hard to spot in that kind of logs. I believe they make better use of Umbra (it seems on some maps it is used), because of the many buildings and other obstacles that cover many parts of the map when rendered.
Additional Comments On The New Rendering System
One thing that I thought about at first was, why they are using a deferred renderer method for the new rendering system? On battle mode, there are no real dynamic light sources, and if there are any you can count them with one hand, so there is no benefit to use a such expensive technique to render the image. It would probably simpler and faster to use a forward renderer.
Did he get his paycheque yet? Did he get the job? He is making too much sense with too much real usable infomation! Seriously though, well done
Yeap, another enjoyable read of tehnical aspects.
I’ve got contacted by one dev studio, but its not WG :)
WT? :))))
better not =O
is there anything 08/15-players can do to optimize game performance based on these findings?
Yes, buy better PC.
~Serious note: I would be interrested also. =)
Not much, put your windows temp folder on your fastest disc, to keep loading times low. Keep the game on a fast disc to avoid possible frame dips through data streaming while playing.
And as thewolfpack writes, better PC.
I highly doubt that a better PC increases performance by that much, sorry…my father’s PC is an absolute gaming machine, but he still has the same performance as WoT on my mediocre PC (maxed out settings ofc). There seems to be a limit.
By the way, I was always wondering which nationality you have SS ;) Can’t figure it out, no matter how many posts I read.
SS is Czech, I believe.
Ah, I knew it :D
Probably both PC have a common limit, like max vram bandwidth, many graphics cards with different chips on it, have the same memory bandwidth.
>> With this low number, I assume that only visible tanks are send to the client (this would make cheating in that regard impossible too)
Since you do read FTR ;) i will comment on this here. Check Receive Damage Announcer mod by Omegaice – clear proof that a lot of data is sent even for UNspotted tanks. I’d like to know what else is sent…
Is minimap position sent every tick like render position? Is minimap data essentially the same, and tank render distance is cut down only by client? Or, you can only get turret/gun position on minimap (cheat) only for rendered tanks?
Is shot origins coordinate sent, even for unspotted tanks too? So, would it be possible to make a cheat showing their positions…?
These are questions not for you specifically, just ideas to check.
I would suggest if you can find a tool to cap fps on low values (5/10fps?) – to simulate client lag spikes – and check how it affects all network traffic and if it affects tank movement (eg. slower accelerating/turret turning)?
Game has to calculate what effect/sound to play when hit by unspotted tank – so data is sent who shot (why not just only a gun?).
Minimap sends data more frequently only for who are close – you can obviously see a jerking movement for far away tanks. Render distance probably a gameplay decission – you want to shoot pixels?
Gun position is not a cheat. Yet :D
As for FPS – probably not. All calculus is done on server.
But I think other games have such BS – lower FPS = lower fire rate (guess what game).
I’d think it may be – if you send data less often – what gets in between, in missing data packets? If you often get lagspikes, your tank may accelerate slower indeed. It depends, what is sent… Would there be a difference between W key and cruise control?
As for minimap data – idk what really is sent and we both base on what was made public…
As i lined out in the article, the client probably sends the requested state of the client (or predicted state, which is when you had a ping of 0), if your ping geth higher or you have lags, this affects how responsive your tank gets, and lead some times to funny moments (360 anyone?:))
And i think there is no difference between direct movement and cruise control.
When my internet was dropping packets constantly, the game would just keep doing whatever it was told last. So if I was driving forward when the packets stopped getting to the server, the server kept my tank moving forward until things re-synced. Once new packets showed up, everything that happened during the lag spike happened all at once. I don’t know if that answers your question or not.
That’s a great idea to test! I always had the impression that low fps in wot made the tank respond slower, although triple-pressing R seems to work well (except when trying to stop you tank under low fps).
fps has nothing to do with lag, nor with tank driving. only in case ur system is so overloaded is over 100% used and cant keep, so input commands are not processed in real time.
data about shell being shoot, type, owner, speed, location, direction, is send to clients if they can spot that shell, even if vehicle firing is behind range, but that doesn’t mean u get info where tank is or how is positioned. thats tracer, and it can be exploited.
gun direction of tanks is send to you only if you can see them. no gun info for tanks out of range, unless arty or sth :)
I wasn’t talking necessarily about the input processing. Instead, if the rendering and the network are handled in the same thread, this might indicate that low fps could delay packets being sent/received.
Indeed that was on my mind too. And, that’s why separating thread may be worth it, more than Thiemo suggests.
PS: could you also trace memory leaks? How bad it gets after 1hour/8hours in raw garage (only pick time so you wont get kicked out because of server reset).
What happens after ~20battles? What useless crap stays in memory then? Is it worth restarting client and how often (methinks it is)?
Good idea, i will add this to my list for a followup part.
I can not say what data is transmitted, i’m not an expert when it comes to decipher binary formats. To get a clue for what is going on, i had to decompile the client, but this is forbidden.
But i can assume some things. Sending data about invisible tanks is a waste of bandwidth and enables cheating.
If you watch your minimap, tanks that are not visible to you stutter while moving, this indicate a clocked info about minimap only data for a tank. But what data is transmitted, i can not say.
I assume that for shots, the origin and the direction and speed is transmitted, without that data, display of shots is not possible. Alternative could be the current projectile position (this would cost a lot of bandwidth tough).
And if the fps is below 20, then it affects your network delay, because both rendering and network handled by one thread.
still, the client receives data about which tank has shot you and from where (at least the direction of the projectile), even if that tank is not spotted at the time – vanilla edition shows only critical hits, while some mods display every source of damage, except splash damage for some reason.
Even more, the same data gets sent to the client while in the spectator mode while watching other tanks, so I do believe it’s possible that the client actually might know more about tank positions than it might appear.
Yes its possible.
1. That’s why i suggested so low fps cap (5/10) – to simulate sever “lag” spikes – clientside, not net – if your hardware is not good in some way. And i think that in these conditons there may be a difference between cruise control and W-driving. And it may impair turret rotation too. I think there is no solution in the code that would somehow account for such problems.
2. I see that you are trying to be “good boy” but while decompiling may be against EULA, there are threads on forums openly mentioning it, with links to decompiled source code – that’s how mods are created. So, you should consider this in future ;) , i have no doubt that you are skilled enough. And worst you can get is forum ban if you annoy them enough (nobody cares on EU as for now, i’ve seen no punishment regarding source code) – and since you are already on FTR, it shouldn’t matter much :P .
3. I agree that sending data about unspotted tanks is a waste of bandwidth but WG made enough dumb things already, so nothing is set in stone.
4. Map ticks can be made client-side, SerB said sth. different, but again… (3)
5. Again – if tank render-box restriction could be lifted completely with some mod, it would be a great news. I think it may be possible, but i’m not skilled enough to tinker with code myself.
6. I wouldn’t be surprised if tracers were disabled client-side too and whole tracer data is sent, not only for artillery but all tanks – and thus could be cheat-modded to be enabled ;) again.
As far is i know, the decompiling is limited to compiled python files, but to know how it realy works, i have to decompile the client exe, which is illegal even without EULA.
Oh well, it depends where you live :P … But i can see your point.
Question for the author of these studies: How hard is to fix some of the stuff you posted here? i have no experience as a progrmmer.. i just want to know if those things can be fixed or they will stick with the game till the end of time ?!
Dont give up hope, every problem outlined by my analysis is fixable.
But is impossible to say how much work they need to put into it. Its highly dependant on their source code structure and a fairly simple problem can turn into a complex monster very fast.
As an example, on one part i suggested a ‘state shadow system’ for their rendering, this can be fairly simple if the code responsible for rendering has a good structure, but if it is scattered all over the place, they have to praticaly rewrite the renderer to implement such a thing.
Some problems are probably bugs with easy fixes (buggy file path concatenation and the shader unpacking), but thy probably still exists because they had no major impact of the gameplay.
Evil SS mistyped me (the h is to much) (and on the prev part too) :P
“One thing that I thought about at first was, why they are using a deferred renderer method for the new rendering system? On battle mode, there are no real dynamic light sources, and if there are any you can count them with one hand, so there is no benefit to use a such expensive technique to render the image.”
In 9.0 or so, firing the gun became a light source. When sitting right next to buildings or other tanks, you can see the flash illuminate the area briefly (though it can be hard to notice if you’re not in a shadow).
You are right, but per frame there are very few light sources to see and the static cost is always payed even with 0 lights. As a counter argument, drawing dynamic light sources with their approach is very simple.
They said they considered night time fighting and weather effects. Also… on Ruinberg on fire, it seems that the fires do have extra light sources.
1. That’s why i suggested so low fps cap (5/10) – to simulate sever “lag” spikes – clientside, not net – if your hardware is not good in some way. And i think that in these conditons there may be a difference between cruise control and W-driving. And it may impair turret rotation too. I think there is no solution in the code that would somehow account for such problems.
-as said before, i don’t think u will get anywhere with that. your system does prioritize tasks, and gfx is hardly on top of its list
2. I see that you are trying to be “good boy” but while decompiling may be against EULA, there are threads on forums openly mentioning it, with links to decompiled source code – that’s how mods are created. So, you should consider this in future ;) , i have no doubt that you are skilled enough. And worst you can get is forum ban if you annoy them enough (nobody cares on EU as for now, i’ve seen no punishment regarding source code) – and since you are already on FTR, it shouldn’t matter much :P .
- decompiled swf files or some python scripts is not game engine, and those are 2 different things…
3. I agree that sending data about unspotted tanks is a waste of bandwidth but WG made enough dumb things already, so nothing is set in stone.
- but they learn
4. Map ticks can be made client-side, SerB said sth. different, but again… (3)
- eeee, what? tank visible, possible map refreshes based on his read position in game not seperate info from server, tank out of range, pure server load.
5. Again – if tank render-box restriction could be lifted completely with some mod, it would be a great news. I think it may be possible, but i’m not skilled enough to tinker with code myself.
- nope, it can’t, thats server side, and u can’t tinker with what server sends you, no tank in range, no data, live with it
6. I wouldn’t be surprised if tracers were disabled client-side too and whole tracer data is sent, not only for artillery but all tanks – and thus could be cheat-modded to be enabled ;) again.
-nope, again, server side, u get info only about those tracers you can see. safer and easier that way, without decompiling, knowing anything how wg coders work, they just have no reason to make it any other way
btw, if you look for exploits for wot, there is one good site with most of them currently, there is quite a lot of modding websites, most in russian tho, go and hit them, and learn something, instead of just putting some stiupid theories like ‘wg wasted a lot of things, it would be nice if they ****** that one as well’
cheers.
That’s a lot of wishful thinking from you. Backed only by common sense – which is not so common in WG – so, unless proved by testing, not valid.
Give this man a job!!!!
Or several…
Or just throw money at him!!!
I want to see more articles like these :d
“One thing that I thought about at first was, why they are using a deferred renderer method for the new rendering system? On battle mode, there are no real dynamic light sources”
There are, they made it so that every shot (muzzle flash) is a dynamic light source, maybe that’s why.