World of Tanks Game User Interface Evolution – Part II

Part Ilink

Source: (via LJ user cadmi)

Pre-release Period – Transferring to Scaleform

Scaleform proposed to use Flash to develop the GUI. Basically, the solutio consisted of three parts:

- customized implementation of the Flash Player, possible to insert into the game client
- set of tools to export SWF into specialized format
- CLIK component library – a set of standard UI components and classes in order to accelerate the development

In the Fall of 2009, a license was purchased and a new phase of GUI development started. At first, everything looked very promising – the Flash development process was developed for years and there were many developers who knew and liked this process. However, it turned out that the job market situation in Belarus was such that the majority of the Flash developers already worked on interesting and “big” projects and to quickly find and hire good people was complicated.

Because of that, the entire staff of the GUI department started to quickly learn Flash (until that point, they worked with php, Java and were doing web development). They learned and started working with ActionScript 2, because at that point, Scaleform did not support ActionScript 3 yet. This is what we got as first results:


Within a half year, the entire interface of the garage was reworked to Flash. As I wrote before, the pipeline of development using Flash was a polished and logical process. Designers created sketches and the programmers implemented them in the game.

A sketch:


And its implementation:


In February 2010, closed beta testing began and it already had the new reworked hangar. But the combat interface was still written in Python:


In Spring 2010, it was its turn to be reworked to Scaleform. When it happened, the game community was split into two camps. One camp liked it (or simply didn’t notice the difference) and they continued to play tanks and have fun in silence. The other camp started shitting mountains of bricks and throwing them at “bloody potato” (1), saying that the new aim circles and interface elements do not match their setting, that there is not enough of torn metal, bolts and rivets, that the aim reticles are supposed to be historical and not similiar to something you could find on a space ship.

One of the sketches of the new combat interface:


Implementation of the combat interface using Scaleform:


But in time, the rage passed, as the new interface introduced a lot of new things in gameplay. The game became more dynamic, intuitive and more informative. Apart from that, the use of Scaleform opened the possibilities of interface customization. Any schoolkid with the minimal basics of Flash could decompile SWF from the game build and he could change any stuff he liked – from the used views and scripts to the code logic itself. Mods started to appear, including changing the aim reticles to “more historial ones” and others (2). It was possible to find mods for any part of the combat interface. There were mods for hangars as well: clocks, calculators, multi-layered tank carousel etc.

Wargaming management changed its attitude towards mods several times. First, when the mods were rare and far between, they simply ignored them. In time, when their number rose and they became more popular, they started paying attention to them and understood that some of the mods can give ingame advantages to the player, who uses them. They started to lead the developers in the direction of “the client is now in enemy hands”. That, of course, doesn’t mean that the players are our enemies. Our task was to secure the client as much as possible from players, who tried to gain ingame advantages.

The mod situation became carefully monitored. Now, in case a mod, that is dangerous or changes the game balance is detected, we react immediately and we disable the possibility of using them by changing the client process logic. In the last few years, we support the creation of honest mods. In fact, it’s a “user generated content” – the players make these mods for themselves and other players, by which the value of our product is increased.

But back to history. The work with Scaleform really refreshed the GUI and pushed its development in the project. Within the timeframe between closed beta, open beta and the game release in August 2010, the functions of the UI grew and became more complicated. We added new features and we polished and reworked the already existing ones. We changed the design, we tried various approaches to the ingame info presentation and to the organization of player-game interaction.

Variants of hangar vehicle filters:


Minimap changes:


Post-Release: Problems of growing up and Ways to deal with them

With the increase of the amount of code and assets, various issues came crawling out of the woodwork. Scaleform marketing took over the real development of the product and as it turned out, many of their declared features either did not work the way we wanted, or were very poor performance-wise, or were generally in their infancy. We did a huge amount of work on improving the Scaleform-player performance – by we I mean both us and the technology developers.

The increase of the code volume led to an interesting effect. Each view (or window) did lie in its own FLA, contained its own assets and code and was compiled into a separate SWF file. There were really a lot of such SWF files and they were loaded into the runtime client to display the needed window or control element and, what was characteristic, the loading order could be changed depending on what the user was doing in the game.

The problem was that if you changed the code, that was used in multiple SWF’s and after this change not all the SWF’s got reworked properly, following thing could happen on runtime: first, the SWF with the obsolete code got loaded and in best case scenario, everything worked as it did before, in worst case, the client crashed. It was hard to find out, what led to such results. We had to invent tools and methods, allowing us to track what exactly needs to be rebuilt after changes.

There was also a problem with the quality and consistency of code and the use of various patterns and styles of programming. This happened because the development the project using Flash was started by people, who were not professional Flash developers. They learned Flash “as they went” and each of them had their own background (C++, php, java). And so it happened that when working on various parts of the project, we had to switch from one approach to another.

One more issue was the interaction between Flash and Python. It was possible to transfer data from one side to another only in the form of “primitives” (3), which as you can imagine was not very sufficient to our needs. There were two ways of dealing with it: either to use JSON, or to decompose all the complex types into long arrays on one end and to create objects from these arrays on the other end.

The first approach worked well while the objects were small. But when the object volume got bigger, the volume of result rows grew and this affected the speed of code execution – it dropped. The second approach worked fast, but it was hard to understand when reading the code and required titanic efforts when implementing any changes in data structure.

At that point, when these issues started to significantly slow the development down, Scaleform implemented ActionScript 3 support to an acceptable level. We hatched a plan to transfer the garage interface to the new version of the programming language and while doing that to restructure the project and to create our own framework, allowing us to (using certain rules) quickly add new functions to the project.

The work on transfer to ActionScript3 started by the end of 2012. Here’s how we solved the issues with it and tasks we did set:

Problem: issues with various code versions in different SWF’s
Solution: all the application code was compiled into a single SWF file, which is loaded when the client starts up

Problem: Python and Flash communication
Solution: we started using Direct Access API. This mechanism allows the transfer of complex data objects while using their automated serialization/deserialization on C++ level. Using this approach increases performance due to the fact that it’s possible to transfer Flash-object links to Python and to handle them in Python directly instead of looking for the required object in Flash every time a data transfer is required.

Problem: Code standardization and unification
Solution: we created a service infrastructure and defined sets of interfaces and base classes and we use them when new functions are added to the project

Problem: Assembly automatization and adding new functions to the project
Solution: we use Maven for assembly. The project was restructured and split into more logical sub-projects and sub-systems. In order to automatize the process of adding new functions, we used YAML as the language describing the Flash-Python interaction interface. During the assembly, a YAML code is automatically generated, as well as the necessary accessories both in Flash and Python. All that we have to do is write the code and define the entry point in order to start the new function.

And so, in September 2013, with patch 8.8, the game lobby was completely reworked to Actionscript 3 and that’s how it is today.


(1) SS: “bloody potato” is a nickname the Russian players use for Wargaming – originally it was meant as an insult, but I think it’s cute in its own way – sounds better in Russian though
(2) SS: here, the author describes some other mods that were possible, using something called “kukla tanka” – I have no idea what the word means in this context so I ommitted that part
(3) SS: Here, the author used a phrase “primitive types”, not sure what that means

30 thoughts on “World of Tanks Game User Interface Evolution – Part II

  1. Is it me or did the graphics go downhill from 2010 at some point? I mean look at that particle effect on that T-34-85.

  2. Anyone noticed, that the sketch hangar shows MG ammunition for IS and does it have dynamic tank stats on the right?

  3. Primitive type = number, character, string of characters etc., no complex objects containing structure composing these primite types into one (lets stay a structure representing all tanks attributes in one object – a tank :D). In this context it meant that they were using interface that allowed transfer of only these basic types and they had to get their complex types through there and thus faced the problems of (de)serialization of these complex types. Quite shocked by the fact that a dev company of this scale found this challenging/a new pattern for them in year 2009+

    • Re-read it. They knew about it (and probably used it), but the Flash – Python interface wasn’t optimized for transmission of anything but PDOs, so they had to write it themselves.

      • Assuming they used something 3rd party for JSON as that has ready-to-use libraries all over the place, yes they had to write their serializers and deserializers for their own format. But for some reason didnt bother to use the inhouse deserializer to implement some sort of inspect tool to negate the disadvantage of incomprehensible data which hints it was a mess and most likely wasnt stream-processed even though they tried to achieve performance boost with this. Also the mention that it was superhard to make any changes in the transferred data structure makes it look like it was something that was rigidly coded without much analysis. They probably didnt know (de)serialization/(un)marshalling is a common pattern at that time because if they knew it, they’d go looking for ready-to-use solutions and would use something like the Direct Access API from the beginning, but it could be the case that AS2 is thrash and doesnt has much options. But either way, it looks like they started with a bunch of people that learned everything on the fly, which isnt uncommon but they could spend some extra moneys and hire one experienced software architect that would keep tabs on what the devs are cooking and helped them avoid these kinda pitfalls quick, but who knows how the job market looks in Belarus :)

    • Pretty much like any other development team that enters something that isn’t their primary field of interest for the first time. Actually doing quite well, considering that.

  4. @Silenstalker
    (1) SS: “bloody potato” is a nickname the Russian players use for Wargaming – originally it was meant as an insult, but I think it’s cute in its own way – sounds better in Russian though

    I have a hunch the word is connected with “burak” = red beet?

    • I don’t think so – it is my understanding that the “bloody potato” (sort of meme in RU communities) came from the fact that a potato is some sort of symbol of Belarus.

      • Funny, you’d think they’d use the term in reference to Poland (due to Vodka both being made from potatoes and originating in Poland), but then again I suppose the term ‘Siemka’ became the more obvious choice for certain reasons I won’t elaborate on.

  5. “Кукла” translates as “doll” or “dummy”. My guess is that it might mean tank representation in damage panel or, less likely, in-game skin.

  6. “Now, in case a mod, that is dangerous or changes the game balance is detected, we react immediately and we disable the possibility of using them by changing the client process logic. ”

    As they have done to counter all the agent orange mods, weakspot autoaim bots, enemy reload timer display, current tracer color mods, laserpointers, red ball, enemy viewdirection on minimap, xray enemy silouhette….wait….those are all still working. -.-

    Bwahahahaa! Good one WG!

  7. The interface on the T-34-85 picture looks really good , like the mod im using but even slightly better , its nice when you have all the information in one space like that compact , i would really like to see that in-game !

    • And the good old beta-time garage interface… When you could set ammo, consumables, repair tank instantly from there… not from an unnecessary pop-up window…
      Still can’t understand why did they change it… It was perfect back then, simple, and fast…

      (anyway; is there a mod what can bring back that interface scheme?)