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 Continue reading →

More...