PsRealVehicle, or Open Source-plugin of physics of tanks in Armored Warfare: Assault
A couple of years ago, our team was honored to start creating a mobile "Armata". Adhering to the rule
"We make a game, not a technology"
, we created the prototype on what is already in the engine. It was UE 4.? the physical model is based on PhysX Vehicles, and a lot of pain (both about and without).
Later, our team created an open source plug-in PsRealVehicle , available by
MIT license is
. This plug-in is sharpened to the physics of tanks and wheeled vehicles for highly loaded network shooters, and its work you can watch at any time in our project Armored Warfare: Assault .
The plugin repository is
Documentation for the main config
Used in the project: Armored Warfare: Assault
A bit of history, or Back to the origins of
We started the work on the project
on the Unreal Engine ???r3r3435. . At that time, the "physics" of the machines was supported only by four-wheeled cars, and for the six-wheeled "shops" (LAV-40? our first "combat" prototype machine) we had to immediately use the custom assembly of the engine. With the built-in physics of the tanks, it was even worse: the data on how everything works and tuned, had to be grabbed from the code bit by bit.
Following the rule "Prototype" , we have formulated the following requirements for ourselves:
Physics should simulate the movement of the tank (minimum program) and wheeled vehicles (it is highly desirable - this is a feature of the AW game series).
The dedicated server must withstand
up to 20 machines for the online session
, and the client must process them.
All wheels and caterpillars must follow surface irregularities,
the suspension should work
, the tank - to swing.
must be determined by the real values of
(machine weight, engine power) and lead to realistic behavior (the ability to overcome certain types of terrain).
The less we write the technical code, the better:
The engine should do Epic Games, not we
So, the requirements are approximately understandable, have started to work. Quite quickly we assembled the first prototype, the tanks went, the cars drove, but we had two troubles:
All this cheerfully burned the processor.
The created picture of the world did not want to fit into the framework of realistic behavior of heavy equipment. Thirty-ton tank with no settings
could not take a 15-degree rise
(and this is one of the easiest options). We spent a lot of time trying to adjust the simulation and friction of the terrain, but this led either to the bullying of power to cosmic values (20+ times the real values, and as a result, the machines behaved unstably and unpredictably), or to the toy masses of technology (PhysX works perfectly with the mass of the vehicle in the area of one and a half tons).
Game designers from such were far from delighted. Programmers cried, pricked, but continued to eat cactus (the party requires a working solution!). The prototype was approved by the management, and sent to create the alpha version (by the way, the video from the prototype is on Youtube
But time passed, and hopes for a bright future of such physics were getting smaller.Extensions were not enough, their behavior looked black magic, and the position of "game, not technology," in their own way, tied their hands, at least doubts whether we'll pull it. "
Quietly armed with Wikipedia, the residual school knowledge and experience in physics on the "pontoons" a la Assassin's Creed, for a couple of days I created a prototype of the new physics of the tank, which formed the basis of the plugin PsRealVehicle. Within a week, the proof-of-concept was put on its feet, the CTO team was shown and protected by stress testing.
The numbers said: your physics - to be.
-, and in the production of
The path from the prototype to the sale went much longer. If the conceptual check lasted for weeks, then
on an adequate beta version it took already a month and a half to
. The creation of a full-fledged "Prodovsky" release took about six months, constant debugging and correction - throughout the time of the project. In many ways, such a high speed of development and implementation of physics in the project we are obliged to come just at that time to our team technical game designer Igor, whose meticulousness in the aspects of the mathematical model and its subjective perception by the players and led to the current result. I must admit,
in the technological sense I am a barbarian
: my job is to make an ax to cut down the forest. After processing Igor and debugging the model with the other guys, we got a production-ready open solution, scalable and highly
optimized for the needs of multiplayer
. There is something to be proud of: among the many plug-ins available on the market (including the built-in PhysX Vehicles), our fastest and most transparent in the setup.
By the way, there were some funny cases. While we were working with PhysX Vehicle and our extremely slippery multi-wheeled cars could not climb the shallow hills, I often heard reproaches, they say, our team can not set up to make people like it. The decision to use its plug-in was made, including, under the influence of this frame:
The latest development of the Soviet army! Spider-tank, which is
It is able to climb the 89-degree walls of
. Such a cover was simply nothing: D
Features of our solution
Before I go on to describe the configuration of tanks and machines in PsRealVehicle using the example of our AW: Assault, I want to say more about a couple of things that formed the basis of the physical model used.
First, we clearly adhere to the fact that
we do not the tank physics simulator, but the game
, sufficiently arcade. It is sad, but very few people need a real tank in their behavior - it's cool only on presentation videos, not in management, and even more so shooter. The player needs a tank that behaves like a tank in the sense that other blockbusters have already created. And to work on a normal device, not Titan'e any.
The first point has a consequence: some things in the game work very feykovo.
If something looks like a tank and behaves like a tank - it's a
tank. , and it does not matter that he is a little frigate inside, or that some of the physics is tuned by the conventional magic of friction. One of such conventions is the regulation of the turning of the machine by changing the angular velocity, and not by forces applied to the wheels and suspension. Conditionally, the tank turns to X degrees per second, because we decided on the basis of gameplay considerations, and not because its caterpillars rotate at such and such a speed.
By the way, this does not cancel the fact that "under the hood" you can include "real" turn physics,
it was used in the first prototypes
. In an amicable way, it is necessary to screw the work of the angular suspension, the underbody of the wheel and so on. If we start to do racing simulators, we will definitely return to this, but for now this is one of the items on the list of possible improvements.
The structure of the tank in AW: Assault
The hierarchy of classes
AAwmVehicle- the main C ++ class, responsible for the machine in the game, split into a set of components. (movement -
UPsRealVehicleMovementComponent, sounds, VFX, statistics, armor and others). It inherits the bluprint
BP_DefaultVehicle, which is an additional
layer for the default settings
for all machines. All the others are private bluesprints for each unit of equipment in the game.
Each machine is a set of such dаta:
is prescribed. all external files
, given sounds, properties a-la "wheel /caterpillar technology", and set up physics.
Skeletal mesh and attached to it assets:
- Physical asset (there is no magic, everything is standard).
- Animation tree.
Textures (diffuse, normal map, RMM).
Material instances (body, caterpillars + destroyed state).
A set of armor mesh for the penetration system.
Cameras, water level checkers and other auxiliary collisions.
Animation of the tank
Customize one tank - a trifle, no matter how complicated the animation tree. Set up dozens of such tanks and keep them up to date, when changing bones, mesh and so on -
completely inadequate volume for handmade
. Fortunately, in our case we are talking about a fairly standardized "character": the tank can be dissected on the essence and call them a pattern. Speech, certainly, about naming of bones.
This approach made it possible to use essentially the same animation tree, which is
saints Ctrl + C /Ctrl + V multiplied by any number of tanks
and does not require any support, except for the original QA-check'a.
All magic takes place inside the custom sipi-nod. This allowed not only to standardize the tree, but also
greatly reduce the number of calculations
on the calculation of animations (standard nodes are very fond of chasing coordinate systems back and forth).
Materials of the tank
For all parts of the tank used
one master material is
, customized by the Switch-node pair.
Next we get the following tree:
- - MI_Vehicles_Clean_Body
- - - MI_Leopard2
- - - - MI_Leopard2_LOD
- - MI_Vehicles_Clean_Treads (it's ticked "Treads")
- - - MI_Leopard2_Treads
- - - - MI_Leopard2_Treads_LOD
The real "weight" here is only
, all other instances are just sets of parameters and consume a minimum of memory and disk space.
In general, a set of graphics for the tank is very standard for any game.
Several times when communicating with colleagues, the question arose, why each piece of armor is made by us in a separate mesh, and why do not we use the Anrilov collision system?
In fact, we use the usual Anril collisions, but
only to "catch" the bullet
. After the projectile stuck in the tank, the damage is counted polygonally on all sheets of armor, taking into account the properties of each piece, multilayer, re-reflections of the projectile, cumulative funnel and other interesting mechanics.
The most convenient for such a case is to read "bare" mesh data, which for a dedicated server we do not strip.
Network and extra-optimization
A couple of "okolotankovyh" moments, which I would also like to briefly mention.
All the movement of tanks
only on the server
, customers only interpolate the obtained values. No extrapolation is used. The synchronization frequency is
10 times per second
Depending on the ScreenSize of the tank, we skip this or that number of ticks of the mesh skeleton, which includes the calculation of all the animations and some physical interactions. If the tank is not visible on the screen - it is stupid
not an animated box floating in the space
. The built-in Update Rate Optimization, despite the good idea, has a very rough implementation, which does not give a significant increase in performance. Especially if it's about mobile phones.
For all tanks, except own, on the client all components are cut off, except for the most basic ones: chambers, checkers and other things, what the tank consists of. In fact,
they have nothing but the appearance of
On a dedicated server rides
The forced LOD1 of the tank
. Less vertices - less CPU consumption. Moreover, the update of the position of custom pieces of armor takes place only when the projector hits: there is no point in updating the state of the parts every tick.
Me, Myself & Tanks
We are at
We believe that the exchange of experience on the development ofchen is 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 introduce the technology to the community as
In my opinion, it is very important that we ourselves use all the plug-ins and utilities published by us daily. After all, the way, clearly demonstrated by Epic Games themselves, is that
the success of a good technology is the use of it by the developers themselves
in their own products. Now we are working already
on the UE version ???r3r3435. , our plugin has been with us all this way, and we are not going to stop!