World of tanks game interface. Postrelease: problems of growth and ways to solve them

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

The game has come a long way to success, and its GUI has been changed and completely redesigned several times in pursuit of the ever-increasing demands of the ever-growing tank army.

Having worked in the GUI Programming department for two and a half years, I got an idea of ​​how the interface itself developed technologically and how the approaches and processes that accompanied this development changed.

Getting Started: Using the 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 after thinking everything through, we decided to stop at tanks (see header photo).

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

How it worked in terms of technical implementation:

• the structure and visual part of the GUI were declaratively described in XML;
• general layout for a large view - the styles of the view itself and the set of main blocks that made it up, described in XML;
• each of the blocks is described in a separate XML, indicating the styles and components used. For components, their settings were set (naming, localization messages, links to styles);
• styles were described in separate XML files, where sizes, positions, textures used, fonts, colors, z-order and god knows what else were set;
• at the start of the client, all these XML files were loaded into Python and parsed, after which the process of creating interfaces, initializing them and connecting to the game logic began.

Here's an example pulled from the depths of an SVN project:

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

account_info components/account fitting components/fitting ...
account.xml - description of the block with account information:

account_name ElideRight #tips:hangar/account_name account_exp #menu:hangar/account_info/experience #tips:hangar/account_exp ...
styles/common.xml - description of styles for common components:

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

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

• working with multi-level XML is difficult to understand and led to a large number of errors that are difficult to localize and fix (for example, misspellings in the naming of components and paths to textures, violation of the structure of the XML document);
• lack of a 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. To imagine how all this would look like by looking at XML was simply unrealistic;
• 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 ones) to the GUI;
• no tool for creating animation.

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

One of the first versions of the combat interface:

And a slightly later version:

It quickly became clear that this approach was a dead end. An analysis of the market for middleware solutions was carried out. As it turned out, the solution from Scaleform was the mainstream in GUI development at that time: 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. Essentially, the solution consisted of three parts:

• a custom implementation of Flash Player that could be built into 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 made it possible 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 had been worked out for 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 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 began to urgently teach Flash (before that they did php, Java and were engaged in web development). We learned and started working on ActionScript 2, since 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 redesigned in Flash. As I already wrote, the Flash development pipeline is a well-established and logical process. Designers create sketches, and programmers bring them to life in the game.

Implementation:

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

In the spring of 2010, it was his turn to switch to 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 cheerfully cut into tanks. The rest began to lay mountains of bricks at the address of the "bloody potato", saying that the new sights and interface elements do not match the setting, that there is not enough torn metal, bolts and rivets, that the sights should be historical, and not similar to space controls. ship.

One of the working sketches of the new combat interface:

Implementation of the combat interface on Scaleform:

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

In addition, the use of Scaleform opened up opportunities for customizing interfaces. Any student who knows how to minimally work with Flash could decompile SWF from the distribution kit of the game and change everything at his own discretion - from the images and fonts used, to the logic of the code. Mods appeared that replaced the sights with historical ones, the "doll" of the tank with a more brutal or, conversely, minimalistic one. You could find mods for any part of the interface in combat. There were also mods for the hangar: clocks, calculators, a multi-level carousel, etc.

Wargaming management has changed its attitude towards mods several times. At first, since these were isolated cases, they were simply ignored. Over time and with the increase in their number and popularity, they began to look closely and realized that some of the mods can give a game advantage to the player using them. The development began to be carried out according to the principle "the client is in the hands of the enemy." This, of course, does not mean that the players are our enemies. Our task was to protect the players as much as possible from other people's attempts to gain a gaming advantage.

The situation on the mod market began to be carefully monitored. Now, if mods that are dangerous or change the game balance are detected, we quickly respond and close the possibility of using them, changing the logic of the client. In the last few years, making honest mods has been supported. In fact, this is user generated content - players make these mods for themselves and other players, which increases the value of our product.

But back to history. Working with Scaleform really 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 in August 2010. New features were added, the existing ones were improved and improved. The design changed, different approaches to presenting information in the game and organizing interaction with the player were tried.

Technique filter implementation options:

Minimap changes:

Postrelease: problems of growth and ways to solve them

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

Scaleform marketing overtook the actual development of the product and, as it turned out, many of the announced features either did not work as expected, or hit performance hard, or were in their infancy. A lot of work has been done to improve the performance of the Scaleform player, both on our part and on the part of the technology developers.

The increased amount of code led to an interesting special effect. Each view (or window) lay in its own FLA, contained its assets and code, and was compiled into a separate SWF file. There were a lot of such SWFs, and at runtime they were loaded into the client to display the desired window or control, and, characteristically, the loading order 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 after the changes, not all of these SWFs were rebuilt, then the following could happen at runtime. The SWF with legacy code was loaded first, and at best everything worked as before, and at worst, the client crashed. It was difficult to understand what exactly leads to such results. We had to come up with tools and techniques to keep track of exactly what needed to be rebuilt after 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 taught Flash “in combat”, and each had their 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 solutions: use JSON or decompose all complex types into 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 as the size of the objects grew, the volumes of the resulting strings 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 Herculean efforts to implement changes in the data structure.

By the time all these problems began to seriously slow down development, Scaleform had already brought ActionScript 3 support to an acceptable level. We had a plan to translate the hangar interfaces to a new version of the language and in parallel 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 migration to ActionScript 3 began in late 2012. How did we solve the problems facing us, and what tasks did we set.

Problem: problems with different code versions in different SWFs.
Solution: All application code is compiled into a single SWF file that is loaded when the application starts.

Problem: Flash communication<->Python.
Solution: transition to use of Direct Access API. This mechanism allows you to transfer complex data objects by automatically serializing/deserializing them at the C++ level. Also, using this approach improves performance by the fact that references to Flash objects can be passed to Python and manipulated in Python directly, instead of searching for the required object in Flash by the full path to it each time data is transferred.

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

Problem: automation of assembly and adding new functionality to the project.
Solution: We use Maven to build. The project was restructured and broken down into more logical subprojects and subsystems. To automate the addition of new functionality, we used YAML as a language for describing the interfaces between Flash and Python. On the basis of YAML, code is automatically generated during assembly and the necessary entities are created - both in Flash and in Python. All that's left to do is write the code and define an entry point to run the new functionality.

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

That's all for today. Details about the structure of the project and plans for the future, read the following article.

This is perhaps one of the largest categories of mods for WOT. If you download this mod, you can completely change the interface of the game, as well as add a huge number of useful features. Below are the main modifications that fall into this category.
- Development tree. It is possible to completely change the standard horizontal tree to a new one - vertical, which is many times more compact.
– Mods that change different objects in your hangar. Colored messages, several interface color options, two rows of armored vehicles instead of one, and a completely new display of the tank carousel.
- Attack markers. Note that there is a standard attack marker, but it is invisible, and using mods you can increase its visibility at times.
- A variety of mods that add increased zoom. Such a mod will help you inspect the entire map or see where the enemy, who is behind the building, turned his own gun.
- In addition, in addition to the mentioned mods, in the proposed category you will be able to find many other mods. Add useful functionality to the World of Tanks interface.

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

The game has come a long way to success, and its GUI has been changed and completely redesigned several times in pursuit of the ever-increasing demands of the ever-growing tank army.

Having worked in the GUI Programming department for two and a half years, I got an idea of ​​how the interface itself developed technologically and how the approaches and processes that accompanied this development changed.

Getting Started: Using the 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 after thinking everything through, we decided to stop at tanks (see header photo).

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

How it worked in terms of technical implementation:

• the structure and visual part of the GUI were declaratively described in XML;
• general layout for a large view - the styles of the view itself and the set of main blocks that made it up, described in XML;
• each of the blocks is described in a separate XML, indicating the styles and components used. For components, their settings were set (naming, localization messages, links to styles);
• styles were described in separate XML files, where sizes, positions, textures used, fonts, colors, z-order and god knows what else were set;
• at the start of the client, all these XML files were loaded into Python and parsed, after which the process of creating interfaces, initializing them and connecting to the game logic began.

Here's an example pulled from the depths of an SVN project:

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

account_info components/account fitting components/fitting ...
account.xml - description of the block with account information:

account_name ElideRight #tips:hangar/account_name account_exp #menu:hangar/account_info/experience #tips:hangar/account_exp ...
styles/common.xml - description of styles for common components:

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

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

• working with multi-level XML is difficult to understand and led to a large number of errors that are difficult to localize and fix (for example, misspellings in the naming of components and paths to textures, violation of the structure of the XML document);
• lack of a 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. To imagine how all this would look like by looking at XML was simply unrealistic;
• 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 ones) to the GUI;
• no tool for creating animation.

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

One of the first versions of the combat interface:

And a slightly later version:

It quickly became clear that this approach was a dead end. An analysis of the market for middleware solutions was carried out. As it turned out, the solution from Scaleform was the mainstream in GUI development at that time: 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. Essentially, the solution consisted of three parts:

• a custom implementation of Flash Player that could be built into 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 made it possible 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 had been worked out for 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 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 began to urgently teach Flash (before that they did php, Java and were engaged in web development). We learned and started working on ActionScript 2, since 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 redesigned in Flash. As I already wrote, the Flash development pipeline is a well-established and logical process. Designers create sketches, and programmers bring them to life in the game.

Implementation:

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

In the spring of 2010, it was his turn to switch to 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 cheerfully cut into tanks. The rest began to lay mountains of bricks at the address of the "bloody potato", saying that the new sights and interface elements do not match the setting, that there is not enough torn metal, bolts and rivets, that the sights should be historical, and not similar to space controls. ship.

One of the working sketches of the new combat interface:

Implementation of the combat interface on Scaleform:

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

In addition, the use of Scaleform opened up opportunities for customizing interfaces. Any student who knows how to minimally work with Flash could decompile SWF from the distribution kit of the game and change everything at his own discretion - from the images and fonts used, to the logic of the code. Mods appeared that replaced the sights with historical ones, the "doll" of the tank with a more brutal or, conversely, minimalistic one. You could find mods for any part of the interface in combat. There were also mods for the hangar: clocks, calculators, a multi-level carousel, etc.

Wargaming management has changed its attitude towards mods several times. At first, since these were isolated cases, they were simply ignored. Over time and with the increase in their number and popularity, they began to look closely and realized that some of the mods can give a game advantage to the player using them. The development began to be carried out according to the principle "the client is in the hands of the enemy." This, of course, does not mean that the players are our enemies. Our task was to protect the players as much as possible from other people's attempts to gain a gaming advantage.

The situation on the mod market began to be carefully monitored. Now, if mods that are dangerous or change the game balance are detected, we quickly respond and close the possibility of using them, changing the logic of the client. In the last few years, making honest mods has been supported. In fact, this is user generated content - players make these mods for themselves and other players, which increases the value of our product.

But back to history. Working with Scaleform really 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 in August 2010. New features were added, the existing ones were improved and improved. The design changed, different approaches to presenting information in the game and organizing interaction with the player were tried.

Technique filter implementation options:

Minimap changes:

Postrelease: problems of growth and ways to solve them

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

Scaleform marketing overtook the actual development of the product and, as it turned out, many of the announced features either did not work as expected, or hit performance hard, or were in their infancy. A lot of work has been done to improve the performance of the Scaleform player, both on our part and on the part of the technology developers.

The increased amount of code led to an interesting special effect. Each view (or window) lay in its own FLA, contained its assets and code, and was compiled into a separate SWF file. There were a lot of such SWFs, and at runtime they were loaded into the client to display the desired window or control, and, characteristically, the loading order 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 after the changes, not all of these SWFs were rebuilt, then the following could happen at runtime. The SWF with legacy code was loaded first, and at best everything worked as before, and at worst, the client crashed. It was difficult to understand what exactly leads to such results. We had to come up with tools and techniques to keep track of exactly what needed to be rebuilt after 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 taught Flash “in combat”, and each had their 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 solutions: use JSON or decompose all complex types into 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 as the size of the objects grew, the volumes of the resulting strings 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 Herculean efforts to implement changes in the data structure.

By the time all these problems began to seriously slow down development, Scaleform had already brought ActionScript 3 support to an acceptable level. We had a plan to translate the hangar interfaces to a new version of the language and in parallel 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 migration to ActionScript 3 began in late 2012. How did we solve the problems facing us, and what tasks did we set.

Problem: problems with different code versions in different SWFs.
Solution: All application code is compiled into a single SWF file that is loaded when the application starts.

Problem: Flash communication<->Python.
Solution: transition to use of Direct Access API. This mechanism allows you to transfer complex data objects by automatically serializing/deserializing them at the C++ level. Also, using this approach improves performance by the fact that references to Flash objects can be passed to Python and manipulated in Python directly, instead of searching for the required object in Flash by the full path to it each time data is transferred.

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

Problem: automation of assembly and adding new functionality to the project.
Solution: We use Maven to build. The project was restructured and broken down into more logical subprojects and subsystems. To automate the addition of new functionality, we used YAML as a language for describing the interfaces between Flash and Python. On the basis of YAML, code is automatically generated during assembly and the necessary entities are created - both in Flash and in Python. All that's left to do is write the code and define an entry point to run the new functionality.

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

That's all for today. Details about the structure of the project and plans for the future, read the following article.