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

Hello everyone,

what follows is an article from Wargaming technical developer blog. I hope you will find it interesting. I did not translate some of the parts literally to express what the author means better, I hope you can forgive that :)

With the private preview of Wows at Gamescom and Igromir, the game release draws ever closer. Currently, we are in the middle of alpha-testing stage and us, developers from the Wargaming studio at St.Petersburg, called Lesta, have a whole bunch of questions to decide. Given that, we already managed to pass a whole lot of obstacles. Below is the account of how we managed to adapt the exporter of our engine to the needs of Wows and how we created the process of content verification.

Standard engine set of tools

Any engine has in its set of tools an exporter of 3D models from various 3D editors to its own data format. Our BigWorld, using which the World of Tanks is made, is no exception. It supports export from 3D Max and Maya. Practically any project does need the adaptation of standard exporters to match the project specifics. In our projects, the specific part are the models of ships.

The first adapted version from Maya was simply “taught” to recognize the more complex structure of the ship scene. A bit of Python control programming was added to the existing C++ code, as well as Maya plugin with wxWidget-based UI. It looks roughly like this:

The resulting tool had lot to be desired for.

It was possible to export only with the participation of the user, who had to “tell” the exporter the contents of the scene. To use this tool in automated processes (for example automatic content verification during the distributive assembly stage) was out of the question. The exporter needed the user to input data about not-so-obvious parameters, it was slow, it practically did not support scene verification and needed a huge amount of resources to work.

Its architecture was the main issue, when it came to extending its functions in the future. The export was practically an elementary operation (set of spaghetti-functions), which translated data from one structure (loaded Maya scene) to another structure (BigWorld) directly into the physical files. When the serializers and business-logic are implemented “as a monolith” and the data model is simply missing, it’s impossible to add the data processing (pre-/post-processing) and it’s also impossible to code-reuse serializers and data model in other instruments, using their own business-logic. It was impossible to create more complex processes of content production. In time, it became practically impossible to add new functions to the existing code. It was decided to rewrite the exporter “from scratch”, based on new architecture.

Daily Bread

The level of our project increased the needs for quality, complexity and amount of the content. In last couple of years, our studio grew a lot. We now had the option to allocate sufficient resources to tasks, tied to content production. We hired professionals with solid background of architecture development and C++/C# technologies. At the same time, this was the first experience for the exporter developers with using Python and Maya API. That introduced additional risks, that had to be taken into account. We estimated the exporter refactoring to take 2-3 man-months. You can’t be a game designer without being an optimist.

In risks, we included:
- lack of formal requirements
- skill with Python
- complexity of Maya API
- refactoring of the primitives processing algorithm

Much of the actual time was spent on gathering the requirements from informal sources, such as the old developers, who became managers in the meanwhile, acted very “oldschool” about the torsion fields and the code of the existing exporter. These nuggets of knowledge were formalized and put into a set of requirements, specifications and into an UML-diagram in Confluence.

First prototypes have shown the need to use the namespaces concept and Python modules (__init__.py). A mechanism was also developed, allowing the “transparent” use of C++ libraries functions (.pyd).

It’s possible to write an entire book about the complexity and details of Maya API. Every function required a prototype, consulting with 3D-artists and with engine developers (rendering). The standart exporter had its own implementation of large amount of algorithms, for example the polygon triangulation, tansformations of embedded nodes matrix calculation etc. We decided not to use them in favor of Maya API, which sharply increased the exporter performance.

It’s about time to add one new law to Murphy’s laws: Any project you come up with will be ready in no less three times the time you intend for it. But the result was worth it. After all, even our lead artist, responsible for the export of models, found after a few months of work our exporter to be “almost ideal”.

To be continued…