[ALL] How We Do Stuff: Building a Bigger Better World

With this post, I'm starting (hopefully) a series of more in-depth materials dedicated to how we actually developing our games, what technologies and techniques we use.

I will try to sum up the state of the game, things we’re working on, our thoughts on current issues, and a lot more about what goes on behind the scenes. We’ll tell you about some fairly unusual ideas and solutions we came up with over the course of development on World of Warplanes, and I hope they'll be as interesting to you as they were for us to invent and implement.

Let’s start from the very beginning.

From the concept of the game. (Were we talking in the real life I would surely hear a somewhat bored sigh right now.)

Most likely, you’ve watched our Video Dev Diaries, and are quite familiar with our passion for all ‘war’ thing – air warfare included. That’s why I won’t write a long story on how most of the World of Tanks dev teams are also flight sim veterans; how the WWII time frame brings WoT and WoWP together, allows for a great variety of vehicle models and dynamic, fun gameplay. Instead, I’ll talk you through what defined the choice of middleware for the title.

When we cleared up the draft concept for our next game would be after World of Tanks, we still had a lot of questions floating on how and what. What technology should we choose for this game? Should we create our own game engine or use an existing one? What programming languages, etc. 

We soon found our answers in our requirements and constraints. Although the decision was easy for us to make, I think it worthwhile and interesting to analyze.

During the development of World of Tanks, we learned how the requirements and limitations put on an MMO engine differ from the engines used by single player games. 

An MMO game is literally the most complicated piece of software one can make. Take every single problem that exists in software engineering, and you’ll face it in an MMO. Plus, there are some unique problems apply specifically to the genre, including cross server object replication, PvP architecture, in-game mail, online account verification, hacking countermeasures, and hundreds of other elements which MMOs need to handle and single player games don't. And keep in mind all of those extra elements are inter-dependent, which adds yet another level of complexity rarely ever found in a single player game.

Developing, integrating and maintaining the clients, the servers, and all the "glue" that makes an MMO work is expensive and requires a lot of time. And it's risky—you're making a bet that your team can solve numerous problems in regards to security, privacy, scale, and exploit protection in the face of the growing number and sophistication of attacks, and providing the appropriate level of service to users. That’s why we decided to license middleware instead of building the game from scratch.

Our work with the BigWorld technology on World of Tanks helped make our decision easier. They offered up a complete technology solution (which is still a rarity when it comes to game engines) that featured significant scalability over the CPU.

With BigWorld Tech you get an integrated set of high performance server apps and tools together with a 3D client and APIs. This engine is made specifically for MMOs, which allows us to focus more on the game and less on the core tech.

Robust and Adaptable Server Infrastructure

 

Another major benefit of BigWorld Tech is that its servers can support hundreds of thousands of players simultaneously up to 200+k PCCU per single cluster (proved in WoT RU).

We fell in love with BigWorld long before we started developing World of Warplanes. We had a chance to battle-test the engine’s performance in World of Tanks and it has proven to be remarkably flexible and efficient. Here I refer to network component of BW, not graphic render. 

The team was already comfortable with the BigWorld technology; our programmers knew the engine and its framework quite well. This familiarity inevitably gave us a head start in production time, since they didn’t have to discover the engine from scratch, which is usually a very time consuming process.

In the end, we decided to use the World of Tanks platform, but to also go about our development intelligently.

You won’t find an engine that will do everything you need out of the box—every piece of software has to be customized, tweaked, and extended to suit the needs of your game. That’s why we did not think of the World of Tanks game engine as the final representation of what we could achieve. Rather, we looked at it as the starting point for further improvement.

Working on World of Tanks we added a lot of tweaks to server components and introduced a multicluster technology, unified authorization, etc. But we didn’t stop there. In reality we had just opened the door into something that brought a lot more potential for us than simply solving server capacity issues. Our improvements meant we could gain a better understanding of how to even further optimize the technology.

With its state-of-the-art server component, the BigWorld tech was only half of an amazing engine since it had a rather modest rendering system. The renderer component was perfectly fine for ground combat, but absolutely not ideal for 3D aerial gameplay.

There are several software solutions in the market that offer decent rendering systems, and we first considered buying the graphical component elsewhere and building it into the BigWorld framework. However, after careful thought, we decided against doing so. Combining different coding languages is extremely challenging from a technology perspective. Besides, long-term investment in a third party technology is economically unreasonable. Building our own renderer from scratch would be time-consuming and, ultimately, expensive.

It soon became clear that the wisest path would be to evolve the BigWorld middleware to meet the needs of World of Warplanes and combine it with a third party tech when appropriate.

We have, of course, done many bright and stupid things along the way that deserve to be mentioned, but I won’t—at least not now— bore you with the details on all of that. Still, I’d like to illustrate the most significant graphical enhancements we’ve created to help you better understand our work so far, as well as realize the potential of the technology we’re using.

In this entry I’ll tell you more about the challenges connected with creating low-level terrain in World of Warplanes.

We somewhat decreased the altitude limit (map ceiling) in the game to provide more intense tactical gameplay that calls for more interaction with the scenery and environment in ground attacks. The actual combat in World of Warplanes takes place at middle and lower altitudes. So, we needed to make detailed low-level terrain that would make flying over it and through it not only visually pleasing, but also offer legitimate tactical options for shaking enemy aircraft and planning stealth missions. We aimed at carving out detailed and contoured landscapes with extra focus on low-level terrain elements like grass, bushes, tree shadows and hi-res textures.

We want players to feel like they have thrilling, continuously occurring action all around them. Naval maps, for example, will feature warships, with some already smoldering in flames and others able to fire up at you, posing a significant threat to your plane. Conversely, there will be land-based maps with surface-based elements like tanks battling on the ground. Ground targets will come in a variety of types, each with their own unique vulnerabilities and defensive capabilities. Ground and surface objects will not be static and will also have several levels of damage suffered (a ground or a surface object can be damaged, half-destroyed, and completely destroyed).

The World Machine terrain generator allows us to create realistic terrain with more detailed shadowing on textures, advanced generation of geologic formation screens, aerated layers, water erosion streams, oceans and seas that are affected with borderline shaping, slope angling, and many other options. Besides providing the game with an impressive visual overhaul, the middleware solution helped us speed up the design of basic textures.

The use of the World Machine tech: before & after

 

We also managed to increase the tessellation density (a process of dividing polygons into smaller parts in 3D graphics) of our rendering system by about 30% compared to the default values right out of the box. It made the spines and apexes of hills and mountains look much sharper. 

The tessellation density: before & after

 

The terrain render optimization let us pick out all relevant texture combinations and integrate them into batches, which resulted in a significant render productivity increase. 

We’ve also added a light map for trees and other static objects. Thus, trees in the shade do not glow and give no flecks—they only get indirect lighting; objects placed in the sunlight are lit by the direct and indirect light.

Continue reading.