Source: http://m.habrahabr.ru/company/wargaming/blog/241083/
Part 1 can be found here.
Part 2 can be found here.
x64 Support
Not so long ago, our artists transferred en-masse from 32-bit Maya 2012 to 64-bit Maya 2014. Since the exporter is almost completely based on Python, there was practically no problem with x64 support. Only the library (.pyd), built on C++, needed some fixing. Currently, the exporter can be used both in x32 and x64 processes, as it itself performs and loads the assembly of the C++ library.
Map Verification
When we were developing the exporter, we couldn’t imagine in advance, in what tools and automatic processes will it find its secondary uses. The automatic verification of maps is a good example of how the “correct” architecture of the exporter found its use in other tools.
The map verification process builds and verifies the dependency of the map on other objects, placed on it. In particular, visual landscape models are used on the map (rocks, icebergs) as well as buildings (houses, hangars, marinas) and vehicles (boats, planes) etc.
The main feature of the map verification process lies in the fact that it doesn’t have to verify only the existence of files of those visual models, but the models themselves, using the exporter framework. This allowed us to remove the human factor, when the map development department had to “trust” the 3D-model department that they are using technically correct models.
Build Assembly
The exporter framework found its use in the process of content pack creation for the builds. The respective build should now have models in it, that:
- are not used anymore
- are still in development
- are intended for future versions of the project
Based on the root game object list, you have to create a dependency graph, according to which you assembly a full list of required content. It’s very simple to deserialize a model using the exporter framework and to “find out”, what other models you require (content references).
Results
The history of the development of our tool has shown, how from a simple tool with narrow uses it evolved into a powerful system capable of solving tasks it was not intentionally designed for, finding use in other parts of content creation process. The main basis of its successful development was the modular architecture, allowing the use of its separate parts in other systems.
In near future, the exporter will be tested again with the transfer of the files to a newer BigWorld version. We are sure that there will be no problems with the architecture and it will work both with current and future version of file format.
1st!!!!!
..to get ban….
So for the most part it is an exporter they made from their modelling software to BigWorld…
Which is fine i guess, especially since exporters are had by…..well, every other game engine ever. Difference is theirs is tweaked a little.
Anyway, the whole dev thing makes me sad that WG shot themselves in the foot when they went for BigWorld, maybe they did not expect for WoT to grow as it did, or were just doing it on the cheap. Shame, the game would have played and ran better if it had a better base package. But too late now, they cant change engines, and they can only do so much to BigWorld. They can only upgrade it so far, until its pointless. I’m drawing parallels between WoT and CoD at this point. Both use old engines(CoD used version of Quake 3 engine, not sure about the last 2 games). Both have grown exceptionally large and both have competitors that try to be the giant killer, but not really succeeding at all. And CoD eventually started dying out on its own, as people lost interest and the title gradually started to simply fade away in players minds. Same will happen toWoT soon enough, as for most popular/leading titles in their genre. Except for WoW…that’s an undying freak of nature.
I think i went a little off topic :D
That’s mostly because CoD is clone after clone after clone – and for each new one you have to pay. Not much to do with sales there, if it were free, it wouldn’t have such problems. There are still large communities playing the older titles after all.
And it was mentioned numerous times why WG chose BigWorld – it had the best network communication for them at the time and everything else could’ve been altered. If you have team of people who are great programmers for offline game, but lack the knowledge to develop a proper MMO networking, it’s the fastest and safest way, easier than writing your networking on a superb graphic engine.
So they’ve finally moved to x64 animation tools yet they can’t even give us a ICC compiled 64-bit game client.
What a point to have 64-bit client? It’s like to have 64bit internet broweser.
It would make a lot of sense, considering that WoT is heavily reliant on the processor rather than on the GPU. Having all the 64-bit register banks used as well as the additional vendor specific registers sets (such as SSE and AVX) would benefit the game if the developers knew how to harness the resources available at their disposal. What’s the point of having software that doesn’t take advantage of the underlying hardware?
This whole WoWs saga is like listening to a narrative on drying paint… in monotone no less.
All of these trivial little details that only a programmer can appreciate, random screen shots, etc, are beginning to wear thin. I used to click on every link related to WoWs, hoping to find some actual game play, only to find more deep in the weeds technical mumbo-jumbo.
When WoWs gets to the point where its near ready for public viewing, THEN tell use. Right now, it looks like this game is waaaay behind schedule. I think that WG is so afraid of another WoW Planes fiasco that they are now too cautious.