World of Tanks Client Analysis

Posted on by

Hello everyone,

a couple of people sent me the links to this article yesterday, thank you for that – one Mr.Tiemo Jung made an analysis of the World of Tanks client on his website and it’s quite interesting. I have contacted him on EU forums and he gave me a permission to repost his analysis here, so here goes. The text is his, it is written from his perspective, I did not edit it apart from formatting it a bit (I did cut down the intro description a bit though). Enjoy.

Introduction

Finally i’ve got some time to work on a Project that i’ve wanted to do for quite some time, analyze the World of Tanks client, to find out how it ticks.

System Configuration:

Intel core i5 2400 (4 cores 3.1GHz)
16 GB Ram
Nvidia GeForce 660 Ti w/ 3 GB Ram
Samsung SSD 840 Series (240 GB): OS and Temp
Western Digital WD20EARX (2 TB): Game
Windows 8.1 Pro

And please excuse my not so perfect english, its not my native language, thanks.

Part 1 – Processes

The log that is used as base of this analysis can be downloaded here. If you want to see the log for your self, just get Process Explorer and open the WotLog.PML contained in the wotlog.7z with it.

This analysis is structured in multiple section, for each game state. First initialisation, this is from starting wot.exe until the login screen is displayed. Next is the login, this is from the display of the login screen until the the engine loads the hangar. Next parts are the hangar, match loading, the match it self and the hangar afterwards and the shutdown. There are also some sections covering some special behavior that are present during multiple phases, like shader loading, config storage and bugs.

Initialization

The init is straightforward, but has some small surprises to offer.

The list of 3rd party libraries and interfaces that gets loaded:

  • The devs didn’t bother to keep the dev code separated from the release code, on launch the first non-os dll is ‘BugTrapU.dll’ its a debug library from IntelleSoft. It is shipped with the CT release but not with the live release.
  • Engine tries to load a steam_api.dll, this dll provides the connection to the steam overlay. So a steam support is incoming? Or was it considered but the code was not removed? If you put a copy of steam_api.dll into the root folder of wot, you get a error message, that wot was unable to find steam and you should try to run it through steam.
  • Fmod, which handles audio processing, it creates 3 threads, inspects the games root path for possible extensions and then scans the /audio sub path for possible audio data. It also looks into the audio files, to probably build a dictionary of audio data.
  • umbra OB 3 gets loaded, umbra itself creates 2 worker threads. As far as i know, wot does not use umbra 3 yet, so this is again an indicator for bad programming practices, you do not ship software with unfinished code and stuff that eats resources and have no benefit, especially if you target low end systems.
  • ‘Uberwoorf’ interface, force feedback for your back and arse, i just had to lol hard when i found out about that :)
  • lightFX, probably part of Alienware computers, i don’t have one, so i can’t test what it does.
  • Logitech API get loaded, i have a Logitech mouse (G700) so the module gets loaded, but it does nothing, because the target of the interface are the keyboards with a lcd display attached to it. Nevertheless the Logitech driver create 2 threads, they do nothing (bad design from Logitech).
  • vivox, used by some well known publishers and developers to provide ingame VOIP.

Strange behaviors:

  • /res, /res_bw and /res_mods/[client version] gets scanned and enumerated more than one time, which indicates that they do not record their findings for later use.
  • .pkg files get scanned multiple times to.
  • user configuration gets loaded multiple times and in probably at least 2 different ways, which indicates code duplication with possible bugs.

Other observations:

  • large amount of compiled python files, indicate that vast portions of the engine are written in python.
  • flash is used for ui logic / display.

Login

Login is short, if you enable auto login, it loads the login key/handle and transmits the data, if everything is okay, the hangar gets loaded.

Hangar

On first enter of the hangar, the voip system starts multiple threads. The engine loads more python files, it also loads a bunch of def files about the tanks. The strange thing here is, the net traffic of the client to the server is somewhat clustered, probably the net system has some sync problems and delays the keep alive messages that are send to the server. The server sends multiple large packets back, probably the user state in some incremental form (first the current tank with some basic data, later other stuff) but this is pure speculation.

In the log you can see that the game is streaming the music (and the ambient sound of the hangar), but i set the music volume to zero, they should stop streaming music if the volume is set to zero.

You can also see, that the engine tries to load the user config from huge amount of combinations of game path + path to user config, and they are all malformed, this indicates that there is a bug in their file system.

the final stuff that gets loaded is the texture and model of the selected tank.

After that the hangar is ready for user interaction.

What you can not see at this log, model and texture data of each tank gets streamed as they are needed (user selects a other tank -> wheel appears).

Match Loading

Only one special thing happens here, a icons.dat get written, probably downloaded from a wargaming server. Other than that, normal graphics and ui data loading and the bugy loading of the user preferences.

Match

While the match is running, audio data gets streamed and some data gets loaded especially as spectator later when i switched to other tanks. Some audio banks are opened and not kept open while the game is running, this results sometimes into frame drops. The replay is also written into temp.wotreplay.

music gest streamed, even if its volume is zero. For the section where the game plays no music, there is a no_music bank used, so the play constantly music.

Post Match Hangar

temp.wotreplay gets renamed to the proper file name, and a new temp.wotreplay gets created. Some cache data files gets updated.

Hangar gets loaded, nothing special, same way as initial hangar loading.

Exit

Nothing special really, the paging loaded lots of code segments that are related to shutdown of the modules.

Net

If you look at the timings of the network traffic, the frequency for up and down stream is about 20hz, this is ok for that type of game. if you consider, Battlefield 4 used until recently a 10/30hz stream frequency, and this rate was too low for its type of game, an caused numerous bugs.

As a result of that, for every action you perform, there is a average of ping + 50ms (up) + 50ms (down) delay.

Packages

.pkg files are renamed .zip files created with ‘store’ mode, meaning there is no compression applied to each file when the package is created. This is done to avoid paying the cost of decompression of the contained data, while loading and background streaming. The cost of decompression can be severe, because the zlib library, which is used to open the .pkg files, is known to be slow, compared to other compression libs and formats.

Shader Loading

Shader loading is something ‘special’. Shader definitions are a combination of dependencies, hash value and compiled d3d9 hlsl code, stored in a .fxo file. The fxo file it self is a renamed .zip file too. The problem is, extracting a zip file within a .zip file is complicated or its too memory intensive for their memory budged (less likely, this .fxo files are small, the larges .fxo file is around 40kb) with zlib. So wargaming/bigworld found a workaround for that. The create a tmp file in your system temp directory and copy the .fxo into it and then opens this temp with zlib to read it. If they are finished, they throw the tmp file away. This procedure is repeated for each shader that is extracted from shader.pkg. This is a very bad behavior, abusing the filesystem of windows to work around a limitation of a bad file structure design. Shader loading is done on almost any stage of the game and can have a huge impact on loading times.

This behavior can have a negative impact on the disc where the temp directory resides, especially if its a ssd, it might reduces its lifetime. But i’m not an expert of the behavior of the os regarding ssds. But this behavior is alarming.

Config Storage

As the log shows, the loading of the configuration is done an almost any point were the engine transit into a ‘loading’ state (init, enter hangar, loading screen). This is somewhat okay, but after each loading of the config, the config gets written back to the disc, which is not needed. Also the writing back is done in a very inefficient manner, the file it self is a xml file, each node gets written separately, resulting in a huge number of system calls to the os, they are expensive.

Bugs

The malformed path bug should be fixed, nothing severe can be observed. You can count the repeated scanning and enumerating of the content directories classify as performance bugs. A second performance bug is the handling of music playback, music is played even if the volume is set to zero and if no music is played during a match.

Conclusion

The shipped zlib version is outdated, they should update to the newest version to assure best performance and security. Or replaces zlib with a more modern and compact de-compression library.

The shader loading behavior is a nogo, and they should changed this, to reduce the stress on the system while loading, resulting in better loading times, especially if the temp disc is slow and/or the system has to write the tmp files to disc.

As for the configuration file, they should only write it back if needed. And then they should buffer the xml data and write them with one write operation, to keep syscall time as small as possible.

Also they should keep released builds clean of experimental code, as you can see, some operations are a result of old or experimental code (steam, umbra etc).

Part 2 – Process Explorer

Process Explorer is a Task Manager on steroids, i will use it to observer cpu, ram, gpu and vram usage.

Game Setup, everything is set to max, except motion blur, i can’t stand this effect. Resolution is std 1080p. 60 FPS are rarely hit, the average is about 35 to 45 FPS.

CPU

Init / Login

Not more than 10% from time to time, but mostly about 1%. This is not surprising, most of the time the program is waiting for data read from disc.

Hangar

10 to 20%, it is okay, but not very good, for a static hangar and a tank, where you only can move the camera.

Battle

Around 25 to 40% and the main thread is hovering at 23% ( 4 core system, so 25% is per thread limit ), so very close to full cpu core saturation. The other threads are the video driver with about 5% and fmod, mixing audio about 2%. The missing portion is filled by the various loading and streaming threads.

Ram

Init / Login

600 Megabytes, a bit much at first, but if you consider there is a huge python library running in the background, no surprise.

Hangar

About 1 Gigabyte, for a hangar view may be a bit much.

Battle

1 Gigabyte to 1.2, this is surprisingly low, in contrast to the usage of the hangar view.

GPU

Init / Login

Very low, 1% may be, not surprising, there is not much to do for the graphics card while the cpu is processing data from disc.

Hangar

70 to 80%, this is really extreme for what is shown. And as far as i know, there were multiple complaints abut that already.

Battle

Also 70 to 80%, this is relative height for what is shown on the screen, especially if you compare it to the direct competitor ( only graphically wise, not gameplay wise)’Warthunder Ground Forces’.

VRam

Init / Login

600 Megabytes, a bit much for about 100 shaders, and some ui elements.

Hangar

1 Gigabyte, way too much for the hangar with one tank and the ui elements. May be some memory is reserved for later use in battle mode.

Battle

1.2 Gigabyte, this is surprisingly low, compared to both previous sections, probably allocate some texture space at startup that is filled while loading and used in battle mode.

Performance

If you hide the UI, the gpu usage goes up, this may sounds strange at first, but if you consider how each frame is created, this is a very clear indicator, that the rendering thread ( the thread that issues the commands to d3d9 to draw each frame ) is saturated. This is a well known limiting factor for current game engines (thre some talks about that on last gdc’s and other game / graphics programmer conferences), which resulted in mantle (AMD hawai+ graphics API), metal (Apple A7? graphics API) and dx12 (Microsoft), to solve that problem.

As they won’t change the underlying graphics api, they have to somehow decrease the number of commands that are issued to d3d9 to increase performance, or they do more with each command ( more polygons, more complex shaders ).

Conclusion

The game performance is mostly hindered by the main thread, that is unable to pump out more rendering commands. This can be a hard nut to crack, but without insight into their rendering pipeline, it is impossible to say what is the real limiting factor there, it is also possible that some stuff that is executed on the main thread, eats too many cpu cycles, that has nothing to do with rendering.

The high gpu usage is alarming too, the graphics are barely state of the art and this hints to sub optimal rendering techniques and shaders. But currently i can only speculate. More in depth analysis of the d3d9 interaction, including shaders, will come with part four.

Part 3 – PIX analysis

I will use PIX to analize the rendering of Word of Tanks.

This part covers only the hangar, because its massive amount of data to dig through. This part includes more explanations than the other, because graphic rendering is a complex topic.

Rendering Technique

WoT uses a technique known as deferred shading. The difference to forward rendering(the ‘default’ technique), the entire scene is rendered once, with some extra information. And each light and shadow gets projected into the image afterwards. On forward rendering, each object is rendered the amount of times it receives a light. The advantage of deferred shading is, that lights (if they not cast any shadows) are very cheap (scene complexity plus each light), in contrast to forward rendering (scene complexity times each light). The drawback of deferred shading is, its extremely bandwidth hungry and is less suited for scenes with view lights, because the static cost for the extra data, that are required to project the lights and shadows correctly, is higher than the cost of re rendering all objects of a scene a couple of times. Most modern rendering engines use deferred shading, because of the inflationary use of lights in scenes and with deferred shading it is almost free.

As for shadow rendering, the engine seems to use 2 different approaches at the same time. First for the sunlight it uses a derivative of a cascading shadow map, this technique has a great shadow qualty on objects near the camera, in thier implementation they render the view of the light 4 times. The other technique for local light sources that cast shadows, there are 4 in the hangar, the light of the inspection trench (i don’t know the special name of that, if it has one) below the tank, the directional light stand on the right, some lights directly above the tank and some lights in the left of the tank (below the pin board). For each light view, the scene is rendered on a very small texture (256×256) and later used to calculate the shadowing effect when the light gets projected into the scene. It seems they use also Screen Space Ambient Occlusion, to further enhance image quality, this is a very expensive technique to calculate light and shadows of light that bounces of surfaces and illuminate surfaces that are nearby.

These techniques are state of the art, used in some form by the unreal engine 3/4, cryengine 2/3, frostbite 1/2, unity and probably other engines. So the hangar rendering is state of the art, and it looks good.

Implementation

The downfall of the hangar rendering is not the techniques used, it is how they are implemented, they did some fundamental mistakes, that cost a lot of performance.

At the start of each frame, the cascading shadow map gets rendered, this is their first fault, the sunlight is always the same, so the cascading shadow map is always the same (until you change the visible tank), why not render it once and use it all the time? Same goes for the 4 shadow casting lights in the hangar. These optimisations are done by many engines, they only render shadow maps if they need to, and if they have to, they do this not every frame (you won’t notice a difference if a shadow map gets updated with a rate of 15fps or with 120fps).

The next mistake is, they try not to reduce redundant state changes, for each draw call you have to change some state. Switch the shaders, use other texture, different blending mode and so on. But they set every state for every draw call, regardless of the current state. This puts a lot of stress onto the driver, each state change has to be validated by the driver and this can be very taxing for the cpu. On top of that, there are a lot of places where state changes has no effect, because they get overwritten before any draw command is issued, resulting in wasted power. A simple solution is to implement a ‘state shadowing’ system, it stores the current state of the rendering system and only passes true state changes along. With that, thy could reduce the number of calls to d3d by 70% and probably cut the cpu overhead in half.

They also use the effect library of the direct3d 9 extension library, it is good for demos, but for serious game engines, where each cpu cycle count, don’t use it. Almost any serious engine uses its own effect system, to gain usability, flexibility and performance in comparison to the direct3d 9 extensions library.

The next bummer, is the way how they are streaming vertex data (vertex data contains the position of each corner of each triangle and more data to correctly display textures and other effects) to the graphics card. The best way is, you allocate a big chunk and fill it with your streamed data, when your finished with streaming, you tell d3d that and start using the data do draw stuff. WoT streams the data that it needs to draw next, commit them and draw, in some cases this is done to draw 2 triangles. A good chunk of the calls to d3d is related to this behavior and is definitely impacting performance.

WoT also wastes a lot of memory, it is astounding how many resources wot loads and holds alive for the time its running. 500 to 900 shaders, 600 textures, 20 render targets, this is just insane. And the textures of the tanks have a 4k by 4k resolution. most of the stuff just lies dormant and is probably reserved or preloaded for battle mode, even if you take this into account, is still massive. It also looks like some textures and other resources get leaked on initialization phase (at least 2, 4k by 4k textures), so they sit there and waste space, not so good.

Ive also notices some strange behavior, the game requests midframe the device capabilities, this is really unusual, such things are done at startup to decide how to behave for best performance.

Another subpar behavior, is to create and destroy textures, vertex and index buffers mid frame. Sometimes it is not avoidable and you need to create resources, but the frequency should be really low, but WoT does this regularly, which is bad. Each time you allocate space at the graphics card, d3d, the os, the driver and the memory manager on you cpu and gpu gets involved. If the system is already stressed, on low memory situations, this will be really slow, the os, driver and both memory managers have to find space for the newly requested memory block. This behavior can also lead to memory fragmentation, which renders some memory regions unusable, because they are too small to use, and reduces the available memory space even further.

The UI rendering is also not optimal, they put every image of each UI element in its own texture, this makes certain optimisations impossible. The most common and simplest optimisation, is to put all images of your UI, into one big texture, this is also known as texture atlasing, then you no longer need to switch textures for each element, which allows you to batch them together. This can reduce the number of draw commands from a couple hundred to thousand, down to a handful draw commands.

Conclusion

They have lots of opportunities to improve performance, adding a state shadow system should help them with cpu perf, and they should rethink some of their resource management and streaming to free up dormant power. Also batching is very important and since years the most common way to address performance problems.

To be continued….

85 thoughts on “World of Tanks Client Analysis”

      • this is pre-tetris programming. and when trying to connect to steam, WG probably could not manage to attach the required pipes and turbines to their gaming-calculators. your computer’s GPU heating up is a leftover of this development, where the heat of your CPU and graphics card was supposed to be used to heat up the water to produce the steam to power these turbines.

  3. Big thanks to Mr. Tiemo Jung (and SS) for this article, very interesting even while I can be considered only half-nerd here.

    The conclusions backed very well with data (and sometimes some guesswork) should really be made available for certain WOT-devs. Whoever has some connections should ping them to this article, as it has some truly valuable info on how to decrease cpu and gpu stress and thus make the game more playable with mediocre or low end computers.

    Thanks a lot!

    • problem is WG devs can’t speak/read english and they can’t hire the very skilled/professionals due to all their documentation written in Russian. (this was reported by SS)

      they are very primitive folks.

      • When you say “primitive folks”, so
        а можешь ли ты писать/читать по-русски (can you write/read russian)?

        My opinion still is that it’s all connected to big companies like AMD, Intel a.s.o
        e.g. it wouldn’t be interesting if game would run same FPS as on standard computer setup (so called “calculator”) as also on gamer setup.

          • no, i’m saying that in this day&age programmers and people working in IT needs to understand and work also in English oriented workplaces.

            English is not my first language
            and i’m half Russian so.. i can say these things and get a free racist pass…

            i closely work with Russians all the time, but they can speak & write English extremely well moron.

            it’s WG devs and culture im speaking off

        • I’d rather suggest, that he means “primitive” in a non-connected, insular way. WarGaming is an international company and should act and produce that way. Limiting their entire software specs to a region of the world, which tends to be somewhat behind compared to other regions of the world in terms of State of the Art techs, is flat out dumb. If the best programmers only speak whatever language they have as a mother-tounge and, most likely today, english and you can only provide in russian, there’s a fundamental problem. You are artificially and without reason limiting your pool of minds.

        • They might a well speak Klingon for all the good it does them if they are unable outsource to English speakers(35%? humans of the planet).

  4. Does that really come as a surprise to anyone?
    Even if half the the stuff he mentioned is really a problem one can see only from playing the game that it is poorly optimized and a mosaik of code. ( No offense to the chap that did this outstanding work, but without a deeper look into the code I’d say one cannot know why some things are the way they are)
    But if the interpretation of the process analysis is correct it explains what we see in the game. Lags and freezes when audio gets loaded ( not as much a problem now as last patch for me) and when HD tanks get rendered (also a bit better since the last patch). All indicates a very poor memory handling as mentioned a month back or so when someone figured that some data gets loaded directly from the hard drive during the game session.
    I’d say they were better off with an overhaul of their code than patching it up over and over again.

  5. They have lots of opportunities to improve performance, adding a state shadow system

    I thought of this too, calculating shadow angles and transpatency doesnt look like hard job for processor. But it is and shadows turned on really influences performande of the game. But if u turn shadows off, it looks like te tank is flying…
    What they can do is add something black oval under the tank, or add seting to calculate shadows like it was before grafic update(stander graphics)

  8. This is a lot of hard work, but can we get a tl;dr version? Also I think Mr. Tiemo should be given with a whip and shipped to Minsk to work in charge of quality control.

  9. My feeling is that WG know exactly what is wrong (if not how to fix it), but choose not to do much of anything because:

    1. Profits
    2. Maybe there is a secret new engine in the works
    3. Maybe WoT is planned to be rolled into another game (World of WG?) and its engine
    4. Profits

    WG could easily afford to redevelop the code from scratch and remain profitable, to head off more shiny competitors like WT and AW, but that means less gold plating on Kislyi’s Lamborghinis. Probably a lot of the head honchos have post-Soviet disease (aka Wall Street disease): compulsion to obtain maximum immediate wealth at all costs.

    • I am not too sure about this, that would be pretty time consuming and they already struggle with new content.
      Sure, it would be much better to rewrite/optimize the code (I think a lot can be done by smoothing a couple of rough edges) and they said they would provide menpower for optimization. (Yes I believe they will do because it is in their best interests)
      However, it is hard to make major changes while the game is running at this scale and they have to add content to keep the long time players involved.
      They need to solve these issues to stay compatative, so it will happen sooner or later.

    • >WG could easily afford to redevelop the code from scratch and remain profitable, to head off more shiny competitors like WT and AW, but that means less gold plating on Kislyi’s Lamborghinis.

      My feeling is you’re deciding a major redesign of a large scale program is ridiculously easy when it’s entirely not. Otherwise Microsoft would be releasing a new OS every 6 months. I don’t even think you think of ‘afford’ as nothing more than a question of money, not time, labor, energy, or resources, which is as bad logic as the wall street bankers you abhor possess.

      1. It takes an incredible amount of time to completely tear out an entire section of the game, rewrite it, then stick it back in without the rest of the game shitting the bed. Trying to say it’s as easy as 9.3 is insane.
      2. Players will start getting stir crazy when you have to reallocate half the team to squashing bugs in the new dev build and they’re not getting new tanks in 6 months.
      3. Players will get furious if/when the new build gets released into production and the production team finds that they missed a major concern that turns out to be a magnificent gamestopping snafu. “OMG WTF WG I NEVER HAD PROBLEMS WITH … BEFORE I HATE YOU!”!!”!”!”#@#$’ Why would you redevelop half the game in a single 6 month period when that carries major risks to the playability of the entire game?
      4. If it breaks on deployment, you have no clue why AND you have half the game where it could be the problem. And you may find it is a compound bug. Fix one thing, the other half of it is still broken. Your player base is still stopped for another several months, AND you completely stop the production of new material to put into the game, squashing previous bugs, and optimizing the game. Not to mention the lost of sleep and productivity when the entire staff is on crunch week trying to put world of tanks back online. Because that’s where their money is in.

      • Sorry, but tank modellers and map modellers and even game ballancers are diffrent people from coders.
        They lack enogh of the latter – and competent too.

        • That still doesn’t make my argument that tearing out half the game just to optimize it a simple proposition. If anything, mediocre coders would make this undertaking that much harder.

          I also have had a hunch for a while that they’re not talented with code. The work they do is enough to make a living of it, not excite anyone.

        • I would also imagine that with 70 people, the chances that some of them can multitask is definitely there, but I could be wrong.

    • I think that the main problem is that the guys that are in quality control and looking at everything look at it as it should be, not as it is, they’re probably not doing it on purpose, but because they don’t think about what they’re looking at

    • That doesn’t really make any sort of sense. They repeatedly stated, that their primary audience tends to have kind of backwards performing hardware. They’d cater to their alleged audience, if they corrected the listed errors, *which will make the client run smoother not only on state-of-the-art, but especially on old equipment*.

  10. Great work but nothing unexpected – WG staff is crap, we all know and now it’s proven by an outside analysis. I don’t want to know what you will see if you get the code in your hands.

    • reminds me the time i worked as outside consultant programmer in a stock exchange, the horrors of first seeing that project C code i almost jumped from the window.

  11. I think the biggest problem WG have (and they have mentioned this in dev posts) is that they only employ russian literate devs as every thing is writen in russian (hardly a surprise).
    They have mentioned recently that they have a great deal of trouble recuiting as there are no more experienced devs available in russia, probably the reason they annouced opening up offices else where in the area (Riga?.

    So I think their existing staff are probably at the limit of what they can actually do, in terms of time available and maybe knowledge.
    Even when you have the money available employing more staff (ie experienced knowledgeable capable) is never as easy as it sounds, and the russian language restriction must be causing them huge problems in that regard.

    Thats my 2 pennies worth anyways.

    • They should move to English-literate programmers… And if current ones aren’t, teach them English, this language is more primitive than some programming languages.

      PS: half of the code is English anyway.

    • Bullshit, a very weak one. Just open Steam and you will see dozens of games made by russian/ukrainian/…. people who are very talented and speak russian…

    • well said

      Ppl underestimate the overall challenge. Lack of english documentation, possibly source code comments, language speaking barrier – those are not minor issiues. Hiring foreign (not fluent in Russian language) coders won’t help.

      WG is in very difficult spot here, because there are quite a few sucessfull game developers in the region, sucking out all the talented guys from market. The competition must be stiff and the only solution would be offering much better terms and salaries ;)
      This isn’t something that companies like to do.

  13. >…the frequency for up and down stream is about 20hz…
    >As a result of that, for every action you perform, there is a average of ping + 50ms (up) + 50ms (down) delay.

    Shouldn’t that be ping + 25ms + 25ms on average? If it polls your every 50 ms, on average you’ll be between the pollings.

    • No. 20hz is 20 time in 1 sec. It is 1000ms/20 = 50ms so you get 50ms for up and then again for down.
      So you get ping +50+ 50+ping (not to sure for this) for action you do till you see it. If we try with ping 50 ms you will get 200ms delay in response.

      • 50ms is not an additional delay, it’s a period during which the actions to be sent are collected. If you send a command during that period, it will be sent after any time between 0-50ms, hence 25ms on average. Same goes for receiving a command.

      • Also, ping shouldn’t be added a second time, it’s already a combined value measured by your computer.

  14. This is like buying the cheapest car in the market (BigWorld engine), put it brand new aftermarket wheels and tires (patch 8.0 physics), a full body artistic paintjob (HD tanks), bi-xenon lights (“new” shaders) and then expect it to run at 10s in 400m. As I wrote previously, WG bit off more than it can chew.

  15. Fantastic post by that guy. Really shows how unoptimised and crappy programmers that are working at WG maybe they should hire this guy.

    Edit:Maybe WG should think about a new game engine it would be a lot of work though to re write everything on a new engine.

  16. good article

    i said it numerous times and I will say it again: WG programmers are shit, BigWorld Engine (the client) is total shit and should’ve been dumped day 1

    you do not use python on a demanding game, python doesn’t work like a compiled code, most of it is interpreted

    BigWorld is beyond saving, WG should’ve recognize this a long time ago and should’ve started re-writing the engine from scratch

    do you know what CryEngine, Unreal Engine and Unity have in common? they’re written in C++
    you just don’t write game engines in Python and expect them to behave

  17. Very interesting article. I do wonder how many of these problems were inherited through the Bigworld engine when WG got it, and how many were implemented by WG trying to fit the engine to their needs.

    I do agree with zMeul above, C++ is used by most games and there is a very good reason for that. However what can they realistically do with WoT at this stage. The game has outgrown the engine. To port over to a new engine or completely create a new engine will give little/no financial gain for them for a very large expenditure and effort. The other alternatives are to create a new version of WoT (2.0) and let the current one phase out after the new one is ready (again huge cost for little gain); or to keep trying to improve what they currently have and milk it for all its worth.

    The only option is the last one, the others could be disastrous for WG and could cause the company to collapse completely.

  18. One of best article at this site :D And this site is known of good articles ;)

    And I wonder… what will happen when someone make his own .dll, rename it to steam_api.dll and copy it into the game root folder… This can be an excellent idea for new MODS :)

    • I think that this door is somewhat barred. The author tried copying a legit steam_api.dll and got an error call. The program is looking for the api, but does not expect to find it. If it is found then it cannot use it and exits via error.

  19. What this show is that the current version of WoT is beyond salvage. It seems that they are using the latest technologies but they are not well implemented because as it has been told earlier, their developers are learning on the job. This smorgasbord of old, new and redundant code is the hallmark of people who do not know how to implement and are learning as they go. I salute them, because this is the real hard way to do things.

    The best solution is for Viktor to sell a Lamborghini or two and hire an entirely new development team with the knowledge they need even if they do not speak Russian, with Russian speaking team leaders, to create a brand new Wot implementation (WoT 2.0). They can keep using Bigworld, since the problem is not the engine itself but how it is implemented. This team will work from scratch while the current one keeps WoT working via patches. At some point they migrate and let WoT 0.x sink under the waters and Viktor will be able to buy back new Lamborghinis and also get a big yacht for his vacations on Cyprus, and we will have a better working game.

  20. The “Shader Loading”-paragraph… Something like that happening became apparent, when people experienced better FPS in match when using SSDs, but geez… Whoever made that design-decission deserves to get flogged.

  22. They need 3 patches to fix friends online/offline status, so akk that above is not really a shock.
    Their bugs, problems and bad coding is snowballing. Their game from technical side looks like it’s made by group of few people who decided to try to make their own game.
    Tht’s unexceptable for company with such a big budget and it should hurt their image.

  23. Looks like they have a lot of optimization to go, guessing another 6-8 months to iron out the more problematic parts?

    Debugging and optimizing IIRC takes longer than it takes to write the code by far.

  24. Hi,
    i’m the author of this articles and i would like to thank ss for posting them here, making more people aware of the situation of the client and hopefully put some pressure on wg to address at least some issues.

    And more is coming, i’m currently working on the battle mode rendering analysis, which is even more complicated than the hangar mode (almost 8gb of rendering log for 3 minutes of a replay rendered with less than 1fps).

    • Hi,
      this is really good article. I have one question: why did you decided to make this analysis?

      • I did this for multiple reasons.

        Firstly no one did such thing before on wot, and i liked to know why wot behaves like it does.
        Secondly to sharpen my skills on software analysis.
        And finally, its fun (but sometimes i want to pull my hair out, because of some horrors buried in the logs).

          • Yes, but not in that scale.

            Some years ago i did a rendering analysis of Word of Warcraft, i never published it. And for some games a analysis similar to part one and two, but i never wrote them down.

            • I’d like to see such analysis for other games too ) Interesting, how optimized other games, may be they also have such problems, like WG.

    • Nice work on this. Have you sent this data directly to someone at WG? Storm maybe? I doubt that the people at WG who need to see this will find it on their own. :\

  26. Hmm, it would be interesting to see how other games, like Eve Online and/or WoW that have been updated quite a lot since their initial release, would hold up to the same analysis.

  27. Conclusion, this guy doesn’t know much about programming.

    The game engine is NOT written in bloody Python. It’s a C++ and uses Python as a scripting language for client-side logic.

    Very sloppy analysis.

    • i never concluded that the core engine it is written in python, i assumption that large parts of the client is written in python, as a result in the vast amount of loaded python files.

      And i do know a bit about coding, over 15 years of exp in various programming languages

      • Can you make an analysis about the other games on the market (WT, MWO…), to see how they work compared to WoT?

        • Possibly, but not in that depth, just may be to compare them in some way.

          But on august my vacation is over and i don’t know how much time i can afford to do such things.

  28. Wow that was a very insightful analysis, I look forward to more of the same.

    This pretty much verifies the feelings I’ve been having, that WG programmers are not very good.

  29. I know nothing about computers and feel as dumb as a box of rocks reading this!

  30. Pingback: World of Tanks Client Analysis (Part 2) | For The Record

  31. Pingback: [Sammelthread] World of Tanks - Seite 1734