3
\$\begingroup\$

Big game engines all have a physics engine whose job is to resolve forces, collisions and constraints efficiently. I think the majority of modern games use a physics engine to some extent. Nevertheless, I have noticed that it is not uncommon for developers to implement features using a "kinematic simulation" instead of a "physics simulation" especially in multiplayer environments. Using the example of a car simulation to clarify these terms a bit more (since I don't think there is standard terminology).

Kinematic Simulation: Collect all the forces (suspension force, gravity, engine force etc). Calculate (and store) the acceleration, velocity, new position etc. Set the location and rotation outside the physics engine (which still handles collisions and motion of objects not related to the car).

Physics Simulation: Collect all the forces add them to the car and let the physics engine resolve what happens.

Is there something that makes client prediction/corrections easier in the kinematic version than the physics version?

Unreals character movement component would be a specific, concrete and very common example. AFAIK while the physics engine is still used for checking for collisions the character itself doesn't simulate physics via the engine but forces are instead added to the movement component which runs its own simulation.

\$\endgroup\$
0

2 Answers 2

1
\$\begingroup\$

Is there something that makes client prediction/corrections easier in the kinematic version than the physics version?

This is a good example. If you want an authoritative server, you would run all of your physics on the server. There is no need to run it again on the client for important parts, such as the player. So when the server tells the client the updated positions, you not only save the client-side calculations of physics, but you also get deterministic results.

Another example is when you don't want to use the engine's physics. For example, your character can push through a bunch of enemies. Using standard physics, your character may get stuck. But by kinematically pushing your character forward, it still lets the enemies react to the collision with the player, but lets the player ignore the collision with the enemies.

\$\endgroup\$
3
  • \$\begingroup\$ Thanks! I had not considered your second point but that is a good one! On the first point, if I only run the physics on the server and pass through the results to the client then does it matter if this is done with the physics engine or with custom code? Couldn't I interpolate between the results using both methods? Or am I missing something that makes the second method better/easier? Also if I don't run the physics on the client will I be able to do proper client prediction?Otherwise they will desync. \$\endgroup\$
    – mbnul
    Oct 4, 2021 at 5:30
  • \$\begingroup\$ I saw a physics desync issue demonstrated vividly in a talk on vehicles in Watch Dogs once. A small difference in time of collision from two players' perspectives led to a car stopping on one side of a street lamp for one player, and juuust to the other side of it for the other player. If we try to apply the correction with client-side physics, then the car will be trying to push through the street lamp pole for one of the players, detecting a collision and pushing back out, making it hesitate or vibrate strangely instead of transitioning quickly to the authoritative position & orientation. \$\endgroup\$
    – DMGregory
    Oct 4, 2021 at 11:10
  • \$\begingroup\$ Good points...in my head, I wasn't turning off physics entirely on the client. Only on important things like the player. So when the player runs into that street lamp, the client-side physics are still run on the street lamp, but not the player. So the street lamp may be in a different location on each client, but the player is still the same place. As for interpolation, I send velocity from server to client, and kinematically set velocity. Networking is complicated. \$\endgroup\$
    – Evorlor
    Oct 4, 2021 at 12:04
1
\$\begingroup\$

One problem with many physics engines is that they are not deterministic. That means that two computers executing the same physics simulation with the same input parameters might end up with two different results. For example because one of them runs at a higher framerate leading to a more detailed resolution.

This is often not much of a problem in singleplayer games. But it can become a big problem in multiplayer games, because even slight differences between clients can often have a butterfly effect which result in the game becoming completely out of sync between players. This is in addition to the latency problem in multiplayer games which causes the game to never be really in sync between players. So not even the input parameters might be the same.

Which is why many multiplayer games roll their own physics engine. Having an own engine instead of a black box allows them to resync the clients regularly.

\$\endgroup\$
2
  • \$\begingroup\$ Determinism is important for multiplayer games, but both Bullet and PhysX are deterministic. (Of course, they probably require the same step to be used on all clients. And the game developer has to ensure that exactly the same inputs (including moving of kinematic bodies) are given to the physics engine on each machine.) \$\endgroup\$ Dec 10, 2021 at 19:18
  • \$\begingroup\$ PhysX is deterministic in the sense that if you run the same sequence of operations on the same machine, you'll get the same result. It does not guarantee determinism between different machines (eg. with different CPUs), in cases where other code might change the x87 FPU state, or in situations where one player has joined in progress, rather than building up the same physics scene through the same sequence of operations as all other players. So, for practical multiplayer purposes, that basically boils down to "not deterministic". \$\endgroup\$
    – DMGregory
    Jul 1, 2022 at 16:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .