New World of Tanks interface. Postletiz: Growth problems and paths of their solutions
Today we will spend a tour of the development history of Graphical User Interface (GUI) in game world. Of Tanks.
The game was held a long way to success, and her GUI changed and completely reworked several times in pursuit of the raising requirements of the army of tankers, which steadily grew.
Having worked in the Department of Gui Programming Two and a half years, I received an idea of \u200b\u200bhow the interface itself developed in the technological plan and how approaches and processes changed, this development was accompanying.
First steps: Using BigWorld tools
It all started with the fact that in December 2008 the idea of \u200b\u200bthe project was born. Everyone who played the tanks, I think, know that the initial idea was to make the game about the elves and orcs, but when they thought well, they decided to dwell on the tanks (see the title photo).The game began to do on the BigWorld engine, which provided its own set of tools for creating a GUI. We went along the way the smallest resistance and made the first interfaces on Bigworld GUI.
How it worked in terms of technical implementation:
- declaratively in XML described the structure and visual part of the GUI;
- general Layout for a large face - styles of the very recesses and a set of basic blocks, which made up, described in XML;
- each of the blocks is described in a separate XML indicating the styles used and components. For components, their settings were set (naming, localization messages, links to styles);
- styles were described in separate XML files where sizes, positions used textures, fonts, colors, Z-ORDER and God knows what else;
- when you start the client, all these XML files were loaded into Python and packed, after which the process of creating interfaces, their initialization and connecting to gaming logic began.
hangar.xml - Description of UI blocks in the hangar:
account.xml - a description of a block with account information:
sTYES / COMMON.XML - Description of styles for general components:
styles / hangar.xml - Description of styles for components in the hangar:
It seems everything is very structured and understandable. But, as it turned out, this approach had several minuses:
- working with multi-level XML is complex in understanding and led to a large number of errors that are hard to localize and correct (for example, the descriptions in the naming of components and ways to textures, a violation of the structure of the XML document);
- lack of visual development environment. The only way to get a visual result is to start the game client and recreate the necessary environment to view the desired interface. Imagine how all this will look like, looking at XML, it was simply unreal;
- bad performance when processing user input (especially this was noticeable in chat);
- a small set of components from the box and the complexity of adding new components;
- high involvement of programmers in the process of creating and making changes (even minimal) in the GUI;
- no tool for creating animation.
One of the first versions martial interface:
And a little later his version:
It became very quickly understood that such an approach is a dead end. An analysis of the Middleware-solutions market. As it turned out, mainstream in the development of GUI at that time was the solution from Scaleform: almost all AAA projects used it in development, and the results looked very attractive.
Preload period: Go to Scaleform
Scaleform offered to use Flash to develop a GUI. In fact, the solution consisted of three parts:- custom implementation of the Flash Player, which could be embedded in the game client;
- set tools for exporting SWF into a specialized format;
- cLIK component libraries - set of standard UI components and classes that allowed accelerate development.
For this reason, urgently learning Flash began the entire GUI department (before that they did PHP, Java and engaged in web development). We studied and started work on ActionScript 2, since Scaleform has not yet supported ActionScript at that time. This happened at first:
For six months, the entire interface of the hangar was converted to Flash. As I wrote, Pipeline development on Flash is a spent and logical process. Designers create sketches, and programmers embody them in the game.
Sales:
In February 2010, closed beta testing of the project with an already updated hangar began. But the battle interface was still on Python:
In the spring of 2010, it came and his turn to go to Scaleform. When it happened, the game community was divided into two camps. I liked everything everyone (or they simply did not notice a big difference) - and they silently continued to be cheerfully chopped into the tanks. The rest began to postpone the mountains of bricks to the "bloody potato", saying that new sights and elements of the interface do not correspond to the setting that there is not enough ribbon metal, bolts and rivets that sights should be historical, and not similar to the controls of space ship.
One of the working sketches of the new combat interface:
Implementation of the combat interface on Scaleform:
But over time, dissatisfaction passed, since the new interfaces brought a lot of new ones in the gameplay. The game became more dynamic, intuitively clearer and more informative.
In addition, the use of Scaleform has opened the ability to customize interfaces. Any schoolboy who can work minimally with Flash could decompile the SWF from the game distribution and at its discretion to change everything - from the images and fonts used, to the logic of the code. Fashion appeared, which replaced the sights to historical, "doll" tank on a more brutal or, on the contrary, minimalistic. It was possible to find mods for any part of the interface in battle. There were mods for hangar: hours, calculators, multi-level carousel, etc.
The wargaming manual changed its attitude towards mod several times. At first, since these were isolated cases, they were simply ignored. Over time and the increase in their number and popularity - began to look after and realized that some of the mods can give a gaming advantage using their player. Development began to lead on the principle of "client in the hands of the enemy". This, of course, does not mean that players are our enemies. Our task began to maximize the players from other people's attempts to get a game advantage.
The situation in the modogue market began to monitor carefully. Now in case of detection of dangerous or changing gaming balance Modov we promptly react and close the possibility of using them, changing the logic of the client's work. In recent years, the manufacture of honest mods is supported. In essence, it is User Generated Content - players make these modes for themselves and other players, which increases the value of our product.
But back to the story. Working with Scaleform very freshened GUI and gave impetus to its development in the project. The functionality has grown and complicated during the passage of closed and open beta And the project's release into the release in August 2010. New features were added, already existing ones were finalized. The design changed, had different approaches to the presentation of information in the game and the organization of interaction with the player.
Options for implementing the filter of equipment:
MINICART CHANGES:
Postletiz: Growth problems and paths of their solutions
With an increase in the number of code and assets, various shoals began to crawl.Scaleform Marketing overtook the real development of the product and, as it turned out, many of the stated features or worked not as much as I wanted, or were very bang in performance, or were generally in the infancy. A great work was done to improve the performance of the Scaleform player, and both on our part and from the developers of technology.
Increased code volume led to an interesting special effect. Each view (or window) lay in its Fla, contained its assesss and code and compiled into a separate SWF file. There were a lot of such SWF, and in runtime they drove into the client to show the desired window or control, and, that is characteristic, the loading order could change depending on what the user did in the game.
The problem was that if the code was changed, which was used in several SWF, and after the changes, not all of these SWF reassembled, then the following may occur on Rataryime. The first SWF was loaded with outdated code, and at best, everything worked according to the old one, and at worst - the client drops. To understand what exactly leads to such results, it was difficult. We had to invent tools and techniques that allowed you to track what exactly you need to rebuild 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 so happened because people who were not professional flash developers began to develop on Flash in the project. They taught Flash "in battle", and everyone had her own Bacground (C ++, PHP, Java). It turned out that when working in different parts The project was needed to switch from one approach to another.
Another pain was the interaction of Flash with Python. It was possible to transmit data to any side only in the form of primitive types, which, of course, did not satisfy our requests. The solution paths were two: use JSON or lay out all the complex types in long arrays at one end and collect objects from these arrays on the other.
The first approach worked well when objects were small. But with the increase in the size of objects, the volumes of the resulting strings grew, and it affected the speed of the code - it fell. The second approach quickly worked, but was complicated for understanding when reading the code and demanded titanic efforts when implementing changes in the data structure.
By the time, when all these problems began to slow down the development, Scaleform has already brought the support of ActionScript 3 to an acceptable level. We have a raised plan to translate the hangar interfaces on new version language and parallel to restructure the project and create your own framework that allows you to quickly and certain rules Add new functionality to the project.
Work on the preparation of the transition to ActionScript 3 began at the end of 2012. As we solved the problems facing us, and what tasks put.
Problem: Problems with various versions of the code in different SWF.
Decision: The entire application code is compiled into one SWF file, which is loaded at the start of the application.
Problem: Communication Flash.<-> Python.
Decision: Go to using Direct Access API. This mechanism allows you to transmit complex data objects using automatic serialization / deserialization of them at the C ++ level. Also, using this approach increases performance due to the fact that references to Flash objects can be transmitted to Python and make manipulations over them in Python directly, instead of finding the desired object in Flash on the full path to it, with each need for data transmission.
Problem: Standardization and unification of code.
Decision:we have implemented the service infrastructure and identified the sets of interfaces and basic classes, implementing which new functionality is added to the project.
Problem: Automation of the assembly and adding a new functional to the project.
Decision: For assembly, we use Maven. The project was restructured and divided into more logical subprojects and subsystems. To automate the addition of a new functionality, we used YAML as a language to describe Flash and Python interaction interfaces. On the YAML database, the code is automatically generated and the necessary entities are generated - both in Flash and Python. All that remains to do is write code and determine the entry point to start a new functionality.
So, in September 2013 with a version of version 8.8, the lobby game was completely redone on ActionScript 3.
That's all today. Details on the structure of the project and future plans read in the next article.
This is perhaps one of the largest categories of modes for WOT. If you download this mod, you can completely change the game interface, and add great amount Useful features. Below we present the main modifications, which are included in this category.
- Tree of development. It is possible to completely change the standard horizontal tree to the new - vertical, which is more compact.
- Fashion that change different objects in your hangar. Color messages, several variants of the interface color design, two rows of armored vehicles instead of one, as well as a completely new display of tank carousel.
- Attack markers. It should be noted that the standard attack marker is, but it is invisible, and using mods you can increase its visibility at times.
- Different modes that add an enlarged zoom. Such a mod will help you to explore the entire card or see where the enemy who stands behind the building turned his own gun.
- In addition, in addition to the mods of fashion, in the proposed category you will be able to find many other mods. Add to World of Interface Tanks useful functional.
Updated for patch world. Of Tanks 1.0.1 WOT.
All who are tired of the standard interface and really want to change it, you should use the modification stylish blue interface Games for world of tanks. After installing it, you will no longer know the game.
Runing the game, you will have a completely new boot window. It has another design and color decision. Especially many will like the silver skull in the middle of the monitor. But even more hangar will surprise you. The combination of blue and black tones was transformed by the hangar beyond recognition.
Classic elements of red are now purchased blue tint.
The menu and interface keys are whether the white edging is obtained, which adds a special flavor. In addition, the application of the stroke forms an increase in the effect.
The font of the tab has a purple illumination, which is perfectly combined with orange letters, which makes them more noticeable.
Another surprise awaits you after the appearance of the battle results. All classes of technology have their own tint:
- TT - red,
- LT - green,
- PT - blue,
- St - yellow.
Tankers who were destroyed in battle are celebrated by the picture skull on the bones.
If you really came the game and want new impressions, be sure to install this modification. Your will give you a lot of positive emotions.