Part I – link

Source: http://habrahabr.ru/company/wargaming/blog/228309/ (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.

Note:

(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