“How we make WoWs: Export Automatization and Content Verification” – Part 2

Source: http://m.habrahabr.ru/company/wargaming/blog/241083/

Part 1 can be found here.

Looking under the hood

In our game studio, we actively use Python scripts. We tried to make the entire exporter using them. Naturally, Python is not suitable to work with large sets of binary data, such as vertex buffers, index buffers etc. The data model and serializers of such buffers were implemented using C++ in the form of a library (.pyd), which in a way “wrote into” the data model under Python. The entire business-logic was made in Python.

The exporter framework was planned to be used not only during “manual” export from Maya, but for any tasks where its functions could be re-used, such as the automatic verification of content. When it comes to any developer tool, we need to have it interfaces (API) for Python, a command line and UI tools.


The architecture of the exporter framework is modular and layered. There are physical and logical layers and also a domain layer. Each layer contains separate modules: data model, business-logic, serializers and converters, capable of converting the data model of one layer to data model of another layer. Physical and logical layers practically form an analogue of ORM-architecture.

Domain layer architecture is designed to easily handle the data models by business logic. It is completely isolated and has no ties to the way it will be serialized to physical storage.

Full exporter architecture:


Export process

The layered architecture introduces some specific elements to the export process. We actually deserialize two (or more) models from various sources (Maya and Bigworld engine). After that, we perform a merge of these models into a new one. New model is then serialized into the Bigworld engine format.

Export process:


Flexibility of the content creation process

The architecture we made allows us easily enough to create complex processes of content production. For example, pripary ship model technically consists of three separate Maya scenes, each of which is developed at the same time by different departments:

- first scene is the visual model and collision model
- second scene is the ballistic model
- third scene contains effect ports

In addition to that, engine redactors add their own data into the working model in engine format (fourth scene). The exporter easily solves the uneasy task of unifying all four scenes into one resulting ship model.

Content verification

Content verification system allows us to look for errors in the content either in each layer (source) separately, or in the resulting content. By now, the number of verifiers reaches several dozen. Automatic content verification is implemented in the build creation, which allows us to exclude human element and to guarantee the integrity and technical purity of the content as much as possible.

This is how verification of ship model in Maya looks:


Content budgets

An important part of the content verification process is the budgets check, for example a polygon count. On the picture below, the information about the number of polygons for each LoD on a visual model is displayed.


The need for such a check is illustrated by a story from the development of another Wargaming project, where there was a space on the map, covered by undestructable houses. Whenever the camera turned towards this spot, the FPS dropped terribly. After exporing the issue, it was found out that inside one of the houses, there was a model of a bathtub and inside, there was a little plastic duck. All that would be considered a small joke by the artists, were it not for the fact that the duck model had around one million polygons.

In reality, it is very difficult to comply to budget limitations. Many models are exceptions to the rule. Setting the value of the budget to a range also does not solve the issue, as over time, the polygon count of the models simply begins to reach the upper value of the range set. In our case, we plan to change the specific budgets of those models, which do not fit the standard budget of the given model type.

Content processing

During each stage of the export, you have to do pre-/post-processing. For example, before the conversion of the logical data model in the Maya layer into the data model of the AA guns domain, you have to do preliminary gun skeleton rotation by 45 degrees and the removal of the skeleton. Our architecture allowed us to smoothly implement various processes during each stage of the export.

Example of a model before and after pre-processing



To be continued…

14 thoughts on ““How we make WoWs: Export Automatization and Content Verification” – Part 2

      • @Nya-chan: Not anybody, but everybody working as professional developer in a similar area sees, that WG employees are just the crap of the industry.

        It’s like in other areas – what for you might look like a miracle is for somebody else daily business. And just because for you game/software developement seems to be a mircacle you should not make the mistake to believe WG employees would be hired by a serious company.

        Have a look at the CV’s, most of them ended at Wargaming – Wargaming is not a company you start a career, it’s where it ends.

      • Yes, any programmer who is at all compotent could do this.

        WG really is known for having the worst Programmers in the industry.

        IMO they made a great game and stumbled into it, WOWP is evidence of that.

        WOWP isa flop because there are other flight sims, where as Tanks was literally the first of its kind.

        Thinkl how much better anfd faster WOT would be with competent guys. We would have multithreading, HAVOK would have been a fast transition and all the XVM style HUD stuff they stole would have been in gamne2 years ago.

        Most companies that start in a garage get massively higher talent as it goes bigger but WG hasnt. Hell Google`s number 5-15 employees wouldnt even be considered for a job at there company now, where as WG has the same head guys who are very limited in there knowledge.

        If they were good WOWP would have been a epic victory, instead its evidence they dont know what they are doing or why WOT blew up so big.

        Lastly think if they added modelers to there team…How many times have we read that X Y Z vehicle is delayed because they need to “Contract out” the work. You would think a company worth 500 mil could afford 140k a year for 2 full time model guys. But in reality they like using excuses when they need them.

    • It’s simple… they just put Aix into Bix using Cix-over-Dix which requires Eix when Fix is active and Gix when Hix is active. Then they put everything into Iix just to make sure Jix is made in accordance with Kix which makes a whole proces of conversion form Aix to Lix very straightforward.

  1. I work closely with technical colleagues in the oil industry. I have no idea what they do either. Clever things, I presume.

  2. How the hell did they end up with a 1 million polygon duck?
    Dev either had loads of time on his hands, the duck was huge or he is completely incompetent.
    A main character in a game is usually 30-50k polygons, the higher you go, the harder it is to process.

  3. Pingback: “How we make WoWs: Export Automatization and Content Verification” – Part 3 | For the Record