A couple of years ago, our team was honored to start creating a mobile “Almaty”. Adhering to the rule “make the game, not the technology” , we created a prototype on what is already in the engine. It was UE 4.9, at the heart of the physical model - PhysX Vehicles, and a lot of pain (both with and without).

In the future, our team created the open source PsRealVehicle plugin, available under the MIT license . This plugin is designed for the physics of tanks and wheeled machines for high-loaded network shooters, and you can watch its work at any time in our project Armored Warfare: Assault .

Names, appearances, passwords.

Clearly. Clear. And only in the case.

Plugin repository

Documentation for main configs

Used in project: Armored Warfare: Assault

A bit of history, or Back to basics

We started work on the project on the Unreal Engine 4.9 . At that time, out of the box, the physics of the machines supported only four-wheeled machines, and for six-wheeled “benches” (LAV-400, our first “combat” prototype machine), we had to immediately use the custom engine assembly. With the built-in physics of tanks it was even worse: the data on how everything works and is configured, it was necessary to get it bit by bit from the code.

Following the rule of “prototyping” , we formed the following requirements for ourselves:

• Physics should simulate the movement of a tank (minimum program) and wheeled vehicles (it is highly desirable - this is a feature of the AW series of games).
• A dedicated server must be able to withstand up to 20 machines per online session , and the client must process them.
• All wheels and tracks should follow uneven surfaces, the suspension should work , the tank should swing.
• Setting up physics should be determined by real values (mass of the machine, engine power) and lead to realistic behavior (the ability to overcome certain types of landscape).
• The less we write the technical code, the better: the engine should do Epic Games, and not us .

So, the requirements are approximately clear, got down to business. Quickly enough, we collected the first prototype, the tanks drove, the cars drove around, but we had two evils:

1. All this is very cheerfully guzzled processor.
2. The created picture of the world did not want to fit into the framework of realistic behavior of heavy equipment. Under any settings, a thirty-ton tank could not take a 15-degree climb (and this is one of the easiest options). We spent a lot of time fiddling with the settings of the simulation and friction of the landscape, but this led either to the detonation of power to cosmic values ​​(20+ times more than the real values, and as a result, the machines behaved unstable and unpredictable) or to toy masses of equipment (PhysX works fine with a vehicle mass in the region of one and a half tons).

Game designers from this were not happy. Programmers cried, pricked, but continued to eat cactus (the party requires a working decision!). The prototype was approved by the leadership, and sent to create an alpha version (by the way, the video from the prototype is on Youtube . But as time went on, hopes for a brighter future of such physics became less and less. The settings were not enough, their behavior looked black magic. And the position “The game, not the technology” has tied its hands in its own way, even if it is doubtful whether we will draw.

Having quietly armed with Wikipedia, residual school knowledge and experience in physics on “pontoons” a la Assassin's Creed, in a couple of days I created a prototype of a new tank physics, which formed the basis of the PsRealVehicle plugin. During the week, the proof-of-concept was put on its feet, the team showed CTO and is protected by load testing. The numbers said: its physics - to be.

...-..., and in production

The path from the prototype to the sales went much longer. If the conceptual test was enough for a week, then it took a month and a half to get an adequate beta version . Creating a full-fledged "prodovskogo" release took about six months, constant refinement and correction - throughout the entire time of work on the project. In many ways, we owe such high speed of development and implementation of physics to the project to the technical game designer Igor, who came to our team just at that time, whose meticulousness in the aspects of the mathematical model and its subjective perception by the players led to the current result. I must admit, in a technological sense, I am a barbarian : my job is to make an ax in order to bring down the forest. After Igor processed and refined the model by other guys, we got a production-ready open solution, scalable and highly optimized for the needs of multiplayer . There is much to be proud of: from the variety of plug-ins available on the market (including the built-in PhysX Vehicles), our fastest and most transparent in customization.

By the way, it was not without funny cases. While we were working with PhysX Vehicle and our extremely slippery multi-wheeled machines could not climb small hills, I repeatedly heard reproaches, they say, our team cannot adjust to make people like it. The decision to use your plugin was made, including under the influence of this frame:

The latest development of the Soviet army! Spider Tank that is able to climb 89-degree walls . Such a cover was simply nothing: D

Features of our solution

Before I proceed to the description of setting up tanks and vehicles in PsRealVehicle using the example of our AW: Assault, I want to say a few more things that formed the basis of the physical model used.

Firstly, we clearly adhere to what we are doing, not a tank physics simulator, but a game that is sufficiently arcade. Sadly, very few people need a real tank in their behavior - this is cool only on presentation video clips, not in control, much less a shooter. The player needs a tank that behaves like a tank in the sense that other blockbusters have already created. And to work on an ordinary device, and not Titan'e any.

The first point has a consequence: some things in the game work quite fakely. If something looks like a tank and behaves like a tank, then this is a tank , and it doesn’t matter that inside it is a bit of a frigate, or that part of physics is set up by conditional friction magic. One of these conventions is the regulation of the rotation of the machine by changing the angular velocity, and not the forces applied to the wheels and suspension. Conventionally, the tank turns at X degrees per second, because we decided so based on gameplay considerations, and not because of its caterpillars rotate at such and that speed.

By the way, this does not negate the fact that "under the hood" you can turn on the "real" physics of rotation, it was she who was used in the first prototypes . In an amicable way, it is worthwhile to fasten the work of an angular suspension, a mean wheel and so on. If we start making racing simulators, we will definitely return to this, but for now this is one of the items on the list of possible improvements.

AW tank structure: Assault

Class hierarchy

AAwmVehicle - the main C ++ class, responsible for the typewriter in the game, divided into many components (movement - UPsRealVehicleMovementComponent , sounds, VFX, statistics, armor and others). BP_DefaultVehicle inherited from it, which is an additional layer for default settings for all machines. All the others are private blueprints of settings for each unit of equipment in the game.

Each machine is a set of such data:

• Blueprint, where all external assets are registered, sounds, a la “wheeled / tracked vehicles” properties, and physics are set.
• Skeleton mesh and its associated assets:
  - Physical asset (no magic here, everything is standard).
  - Animation tree.
• Textures (diffuse, normal map, RMM).
• Material instansy (body, tracks + destroyed state).
• Set of armor meshes for the penetration system.
• Cameras, water level checkers and other auxiliary collisions.

Tank animation

Customize one tank - a trifle, no matter how difficult the animation tree. To adjust dozens of such tanks and keep them up to date, with changes in bones, meshes, and so on, is a completely inadequate volume for manual work . Fortunately, in our case we are talking about a fairly standardized “character”: a tank can be dissected into entities and call them patterned. This, of course, is about naming bones.

This approach made it possible to use essentially the same animated tree, which, with the holy Ctrl + C / Ctrl + V, multiplies by any number of tanks and does not require any support, except for the original QA-check.

All the magic happens inside the custom sipipi-nod. This allowed not only to standardize the tree, but also greatly reduce the number of calculations on the calculation of animations (standard nodes love to drive coordinate systems back and forth).

Tank materials

For all parts of the tank, one master material is used , customized by the Switch-node pair.

Next we get this tree:

  - M_Vehicles
  - - MI_Vehicles_Clean_Body
  - - - MI_Leopard2
  - - - - MI_Leopard2_LOD
  - - MI_Vehicles_Clean_Treads ("Treads" is checked)
  - - - MI_Leopard2_Treads
  - - - - MI_Leopard2_Treads_LOD 

Only M_Vehicles and MI_Vehicles_Clean_Treads have real “weight” here, all other instances are just parameter sets and consume a minimum of memory and disk space.

In general, a set of graphic assets for a tank is quite standard for any games.

Job armor

Several times when communicating with colleagues, the question arose why we made each piece of armor a separate mesh, and why we do not use the Anril system of collisions?

In fact, we use the usual Anrilov collisions, but only to “catch” the bullet . After a projector is stuck in a tank, damage is calculated polygonally over all sheets of armor, taking into account the properties of each piece, layering, projectile reflections, a cumulative funnel and other interesting mechanics.

The most convenient for such a case is to read the “bare” data of the mesh, which we do not strip for a dedicated server.

Network and extra-optimization

A couple of "okolotankovyh" moments, which I also would like to briefly mention.

• All movement of tanks is carried out only on the server , clients only interpolate the values ​​obtained. No extrapolation is used. Synchronization frequency - 10 times per second .

  
  

• Depending on the ScreenSize of the tank, we skip a certain number of ticks of the skeleton mesh, which includes counting all the animations and some physical interactions. If the tank is not visible on the screen - it is a stupid non-animated box floating in space . Built-in Update Rate Optimization, despite the good idea, has a very rough implementation, which does not give a noticeable performance boost. Especially when talking about mobile phones.

  
  

• For all tanks, except your own, on the client all components except the most basic ones are cut off: cameras, checkers and other things that the tank consists of. In fact, they have nothing but appearance .

  
  

• On a dedicated server goes forced LOD1 tank . Less vertices - less CPU consumption. Moreover, the update of the position of the custom pieces of armor occurs only at the moment of hitting the projector: there is no sense in updating the state of the parts with every tick.

Me, Myself & Tanks

We at Pushkin Studio believe that the exchange of development experience is very important, including for the growth of the professional level within the team. Open source projects are a significant component of this approach, and I am glad that I can present such technology to the community as PsRealVehicle .

In my opinion, it is very important that we ourselves use every day all the plugins and utilities we publish. After all, the way, clearly demonstrated by Epic Games themselves, is that the success of a good technology is its use by the developers themselves in their own products. Now we are working on the UE version 4.20 , our plugin has passed with us all this way, and we are not going to stop!