War Thunder background
Vehicle Collision Physics in game - An explanation
Attention! Outdated news format. Content may not display correctly.
Attention! This news was published on the old version of the website. There may be some problems with news display in specific browser versions.


We have received some complaints and mis-understandings about how vehicles collide with other vehicles in the game environment, Anton (Gaijin CEO and War Thunder Lead Developer) took some time out to try and explain exactly how our game interprets real world physics virtually.


A small reminder of how net-code/physics in War Thunder works

  1. Client apply controls which simulate physics and send controls to the server. The server receives the controls and apply them in the past (due to ping, controls that have been sent happened somewhere in past time).
  2. Server then sends "authority state" to client - i.e. "real" position.
  3. Of course, when it gets to client it is already in past (outdated) due to ping. So, client, re-applies all controls that were applied/pressed since that time to this "old" (but actual, server-truth) position.
  4. This gives "new" position

Although hard to understand and very computationally expensive (compared to, say, Battlefield net code, which basically happens in past time) this gives a really good result on any reasonable latency ping when controlling a vehicle.



Offline game experience, online?

This gives a really good level of control, single player-offline-realtime quality, if three conditions are met:

Stable ping. As you can see from the algorithm, both the server and the client relies on getting certain information in time. And if a ping is very unstable - results will be jittering. So, a stable 100msec is sometimes better than "average" 50msec if it is actually 10..110ms.

Reasonable packet-loss. That's why it is better to play wired, than wireless. Of course, all data is sent with certain redundancy. But if all controls from the client to sever are lost in 700msec window, they basically become too outdated to be re-applied (remember, client is not alone in the world, there are other clients, and they need to "see" and interact with someones position, so we can't allow the reapplication of controls from the last, say, 10 seconds - it will result in significant "teleporting" on the server and thus on all other clients). However, if you have a reasonable packet loss (3-5%) it should be ok. Also, keep in mind that the packet loss that the game shows in stats is not the complete packet loss a client experiences, it is measured only based on "reliable" traffic, because for unreliable traffic we can't actually determine if the packet was lost. Also, even 5% on average doesn't mean that you haven't lost all (redundant) packets with, say, controls.

No interaction with other players. Of course, it is not true in game. However, most of the time, 99.9% there are no interactions, and 99% of all interactions are shooting. Shooting is really cool (for players immersion/net code) interaction, because most of the time it is either not doing anything at all (miss or ricochet) or doing real damage, so some kind of desync (small teleporting if you have moved 100msec when actually your track was damaged 200 msec ago) looks OK and does not spoil immersion.

Of course, because all net-code in WT works this way, you "see" the other player in extrapolated time - i.e. we know their old position, their speed and controls and we predict future position based on it since vehicles are highly predictive and inertial it is fine most of the time.



The War Thunder netcode

As far as I know this net-code was invented in War Thunder. The industrial standard for shooters is showing each client interpolated in past time (Battlefield, CS) - but that puts anyone with a greater ping in a better position (and doesn't work so well with physics collisions either, for obvious reasons - these movements have already happened) or no (extra) interpolation at all (Q3) where you need to predict your ping and shoot ahead of an enemy (which doesn't work well with collisions either, and also puts anyone with high ping in a really bad position). There is one obvious solution which is called "thin client" where we show only what the server sends and predict/compensate lag/latency by applying all controls in "future" (i.e. with certain delay). That is how many MMORPG's work (and some other games), but that is not acceptable for high-speed vehicles with critical unstable states, such as aircraft and sometimes even ground vehicles (high-speed movement on slope angle), as it makes controls "sluggish" and less responsive.

There is no ideal solution for an online game (of course, if we could "trust" clients, we could enhance collision for each client a lot), but our solution work extremely well for vehicles in most conditions. The main (and obvious) exception where it does not work so well is physical collisions between vehicles (especially player controlled).



Solving Collisions in game

Solving collisions in game physics are, generally, one of the hardest tasks, but it become especially hard, when you try to recreate events so, that it is not only solving collisions correctly but also try to "trust" users controls (and not user position!) in the past (i.e. reapplying them for last client's ping timeframe). Of course, when you observe said collision from the other client (replay) it becomes even stranger - not only because a client will reapply it's controls after actual a collision in past, but also because you are seeing extrapolated, future, position of enemy vehicle, which is doing the same thing (re-applying controls on the server).

In some examples given to us, the collision itself could very well happen. Tanks flip, even on flat ground without help of other tanks (you can google videos from Tank test drives/tank biathlon, etc). But the "observed behaviour" leading to natural results can look unnatural, partially because you never see what actually happened (on the server) and partially because the server itself has to re-create the events (controls) in very specific conditions.

In our game the server broadcast positions, not controls, so no one depends on the "slowest" client. Usually with a better ping  - you will have a better awareness and better aim. But controls of your own vehicle are not ping-dependent (only packet loss dependent), if you are not colliding with other vehicles. Since controlling is the norm, and colliding is rare (there is actually no good online solution for a colliding solution anyway, if not forcing "slow" (latency in controls) or the "thin client" one), this allows us to offer a good overall experience and permits players from all over the world to play together.

I would like to end with the recommendation to keep your spacing and try and not collide with teammates casually. After all, In reality this can cause serious injuries for the crew and damage to any vehicles and your beautiful paintwork.


The War Thunder Team

Read more:
Mobile Sniper: Boxer MGS
  • 3 October 2024
Following the Roadmap: Vehicle Research Bonuses
  • 24 September 2024
Following the Roadmap: Detailed Helicopter Damage Models
  • 16 September 2024
Join the Testing for the French Coastal Fleet!
  • 10 September 2024