GUI in the game World of Tanks. Part One: The Evolution of Game Interfaces

Today we will take a look at the history of the Graphical User Interface (GUI) development in World of Tanks.

The game went a long way to success, and its GUI was changed and completely reworked several times in pursuit of the increasing demands of the army of tankers, which grew steadily.
')
Having worked in the GUI Programming department for two and a half years, I got an idea of ​​how the interface itself developed in terms of technology and how the approaches and processes changed, this development was accompanied.

First Steps: Using BigWorld Tools

It all started with the fact that in December 2008 the idea of ​​the project was born. Everyone who played tanks, I think, knows that the original idea was to make a game about elves and orcs, but when everything was thought out well, we decided to stop with tanks (see the title photo).

The game began to make the engine BigWorld, which provided its own set of tools for creating GUI. We took the path of least resistance and did the first interfaces on the BigWorld GUI.

How it worked in terms of technical implementation:

• the structure and the visual part of the GUI were described declaratively in XML;
• The overall layout for a large view is the styles of the view itself and the set of basic blocks that make it up, described in XML;
• Each block is described in a separate XML with an indication of the styles and components used. For components, their settings were specified (naming, localization messages, style references);
• The styles were described in separate XML files, where the dimensions, positions, used textures, fonts, colors, z-order and God knows what else were set;
• when the client started, all these XML files were loaded in Python and parsed, after which the process of creating interfaces, initializing them and connecting to the game logic began.

Here is an example, torn from the depths of the SVN project:

hangar.xml - description of UI blocks in the hangar:

<hangar> <styles> <style>window</style> <style>hangar:window</style> </styles> <childs> <AccountBlock> <name>account_info</name> <import> components/account </import> </AccountBlock> <Fitting> <name>fitting</name> <import> components/fitting </import> </Fitting> ... </childs> </hangar> 

account.xml - description of the account information block:

 <account> <styles> <style>hangar:account_info</style> </styles> <childs> <TextLabel> <name>account_name</name> <text></text> <textElideMode>ElideRight</textElideMode> <styles> <style>hangar:account_name</style> </styles> <toolTip> <format>#tips:hangar/account_name</format> </toolTip> </TextLabel> <TextLabel> <name>account_exp</name> <text>#menu:hangar/account_info/experience</text> <styles> <style>hangar:account_exp</style> </styles> <toolTip> <format>#tips:hangar/account_exp</format> </toolTip> </TextLabel> ... </childs> </account> 

styles / common.xml - style description for common components:

 <style> <window> <bgcolor> 200 200 200 255</bgcolor> <overlaycolor> 255 255 255 255 </overlaycolor> <border> <texture>gui/maps/window_border.tga</texture> <size> 5 </size> </border> <focus> <bgcolor> 255 255 255 255</bgcolor> </focus> </window> … </style> 

styles / hangar.xml - style description for components in the hangar:

 <style> <window> <color>0 0 0 255</color> <bgcolor>255 255 255 255</bgcolor> </window> <account_info> <position><x>10</x><y>10</y><z>0.9</z></position> <height>32</height> <bgcolor>100 100 100 255</bgcolor> <color>200 200 200 255</color> </account_info> <account_name> <height>100%</height> <textAlign>LEFT</textAlign> <position><x>10</x></position> </account_name> <account_exp> <height>100%</height> <horizontalAnchor>RIGHT</horizontalAnchor> <font>default_smaller.font</font> </account_exp> … </style> 

Everything seems to be very structured and understandable. But, as it turned out, this approach had several drawbacks:

• Working with multi-level XML is difficult to understand and led to a large number of errors that are difficult to locate and correct (for example, miswritings in the naming of components and paths to textures, violation of the structure of an XML document);
• lack of visual development environment. The only way to get a visual result is to launch the game client and recreate the necessary environment to view the desired interface. Imagine what it would all look like by looking at XML, it was just unreal;
• poor performance when processing user input (this was especially noticeable in the chat);
• a small set of components out of the box and the difficulty of adding new components;
• high involvement of programmers in the process of creating and making changes (even minimal) in the GUI;
• no tool to create animation.

All these disadvantages led to the creation of interfaces in the style of Programmer Art. According to a schematic sketch, programmers made layouts in XML, and only then artists created the necessary textures and passed everything back to programmers for final customization and loading. Here is an example of such an interface (in the photo - the workplace of project manager Alexander Shilyaev with a tank client launched at the stage of a closed alpha test):



One of the first versions of the combat interface:



And a little later version:



It quickly became clear that this approach was a dead end. An analysis of the market for middleware solutions was conducted. As it turned out, the mainstream GUI development at the time was a solution from Scaleform: almost all AAA projects used it in development, and the results looked very attractive.

Pre-release period: transition to Scaleform

Scaleform suggested using Flash for GUI development. In essence, the solution consisted of three parts:

• custom implementation of Flash Player, which could be embedded in the game client;
• a set of tools for exporting SWF to a specialized format;
• CLIK component libraries - a set of standard UI components and classes that allowed to speed up development.

In the fall of 2009, a license was purchased, and a new stage of GUI development in the project began. At first, everything looked promising: the Flash development process was worked out over the years, and there were a lot of developers who knew and loved this process. However, it turned out that the situation on the labor market in Belarus at that time was such that the majority of Flash developers were already sitting on interesting and “fat” projects, and it was difficult to quickly find and attract high-quality personnel from outside.

For this reason, the entire GUI department started to learn Flash urgently (before that, they did php, Java, and were engaged in web development). We studied and started working on ActionScript 2, because Scaleform did not yet support ActionScript 3 at that time. Here’s what happened at first:



For six months, the entire interface of the hangar was converted to Flash. As I already wrote, the Flash development pipeline is a proven and logical process. Designers create sketches, and programmers embody them in the game.

Sketch:



Implementation:



In February 2010, a closed beta testing of the project began with the already updated hangar. But the combat interface was still in Python:



In the spring of 2010, his turn came to move on to the Scaleform. When this happened, the gaming community was divided into two camps. One liked everything (or they simply did not notice a big difference) - and they silently continued to chop their tanks vigorously. The rest began to lay mountains of bricks against the "bloody potato", saying that new sights and interface elements do not match the setting, that there is not enough torn metal, bolts and rivets, that sights should be historical, and not similar to space control elements. by ship.

One of the working sketches of the new combat interface:



The implementation of the combat interface on Scaleform:



But over time, dissatisfaction has passed, since the new interfaces have brought a lot of new things to the gameplay. The game has become more dynamic, more intuitive and informative.

In addition, the use of Scaleform has opened up possibilities for customizing interfaces. Any schoolchild who knows how to work with Flash to a minimum could decompile SWF from the game’s distribution kit and change everything from the images and fonts used to the logic of the code at its discretion. Fashions appeared, replacing the sights on the historical ones, the tank “doll” with a more brutal or, on the contrary, minimalist one. It was possible to find mods for any part of the interface in battle. There were fashion and for the hangar: watches, calculators, multi-level carousel, etc.

Wargaming has changed its attitude towards mods several times. At first, since these were isolated cases, they were simply ignored. With time and an increase in their number and popularity, they began to look closely and realized that some of the mods could give a game advantage to the player using them. Development began to lead on the principle of "client in the hands of the enemy." This, of course, does not mean that the players are our enemies. Our task was to protect players from other attempts to gain a gaming advantage.

The situation on the mod market has become closely monitored. Now in case of detection of dangerous mods or modifying the game balance, we promptly react and close the possibility of using them, changing the logic of the client’s work. In the last few years, making honest mods is supported. In essence, this is user generated content - players make these mods for themselves and other players, which increases the value of our product.

But back to the story. Working with Scaleform greatly refreshed the GUI and gave impetus to its development in the project. The functionality grew and became more complicated during the passage of the closed and open beta and the release of the project to release in August 2010. New features were added, existing ones were refined and drew. The design changed, different approaches were tried to present information in the game and organize interaction with the player.

Options for the implementation of filter technology:



Minimap changes:

Post-release: growth problems and their solutions

With the increase in the amount of code and assets, various jambs began to creep out.

Scaleform marketing overtook the actual product development and, as it turned out, many of the declared features either did not work the way they wanted, or were severely beaten in performance, or even were in their infancy. A lot of work has been done to improve the performance of the Scaleform player, both from our side and from the developers of the technology.

The increased amount of code led to an interesting special effect. Each view (or window) was in its FLA, contained its assets and code, and compiled into a separate SWF file. There were a lot of such SWFs, and on runtime they were loaded into the client to display the desired window or control, and, characteristically, the order of loading could change depending on what the user was doing in the game.

The problem was that if the code that was used in several SWFs changed, and not all of these SWFs were reassembled after the changes, the following could happen on runtime. SWF was first loaded with obsolete code, and at best everything worked the old way, and at worst, the client crashed. It was difficult to understand exactly what leads to such results. We had to invent tools and techniques that allowed us to track what exactly needs to be rebuilt after the changes.

There was also a problem with the quality and consistency of the code and the use of various patterns and programming styles. It happened because Flash development in the project was started by people who were not professional Flash developers. They learned Flash "in battle", and each had its own background (C ++, php, Java). It turned out that when working in different parts of the project, it was necessary to switch from one approach to another.

Another pain was the interaction of Flash with Python. It was possible to transfer data in any direction only in the form of primitive types, which, of course, did not satisfy our requests. There were two ways to solve it: use JSON or lay out all complex types in long arrays at one end and collect objects from these arrays at the other.

The first approach worked well when the objects were small. But with an increase in the size of objects, the volumes of the resulting lines grew, and this affected the speed of code execution — it fell. The second approach worked quickly, but was difficult to understand when reading the code and required titanic efforts when implementing changes in the data structure.

By the time all these problems began to slow down the development, Scaleform had already brought ActionScript 3 support to an acceptable level. We had a plan to transfer the hangar interfaces to a new version of the language and at the same time to restructure the project and create our own framework, which allows us to quickly and according to certain rules add new functionality to the project.

Work on preparing the transition to ActionScript 3 began in late 2012. How we solved the problems we faced, and what tasks we set.

Problem: problems with different versions of code in different SWF.
Solution: all application code is compiled into one SWF file, which is loaded when the application starts.

Problem: Flash communication <-> Python.
Solution: switch to using Direct Access API. This mechanism allows you to transfer complex data objects using automatic serialization / deserialization of them at the C ++ level. Also, using this approach increases performance by linking to Flash objects in Python and manipulating them in Python directly, instead of searching for the desired object in Flash along the full path to it each time data is required.

Problem: standardization and code unification.
Solution: we implemented the service infrastructure and defined sets of interfaces and base classes, implementing which new functionality is added to the project.

Problem: automating the assembly and adding new functionality to the project.
Solution: for the assembly we use Maven. The project was restructured and divided into more logical subprojects and subsystems. To automate the addition of new functionality, we used YAML as a language to describe the interfaces between Flash and Python. On the basis of YAML, automatically when building, code is generated and the necessary entities are created, both in Flash and in Python. All that remains is to write the code and define the entry point for launching the new functionality.

So, in September 2013, with the release of version 8.8, the game lobby was completely redone for ActionScript 3.

That's all for today. Details about the project structure and future plans are in the next article.