Client side prediction with nondeterministic physics

Hi, I'm currently working on a fast-paced multiplayer FPS, with deterministic locksteps and server authoritative player movements.

I've recently read that Unity's built-in physics system (pre DOTS physics) isn't fully deterministic, which I believe means that the same input applied for the same state, could theoretically end up in different results based on the system the client is running.
Currently the player control relies on pretty complicated physics (players bouncing off of static objects, etc), so any small mispredictions could lead up to a big desync in ~100ms.

This gave me a concern that these combined could create a very unpleasing experience for some players, invoking noticeable reconciliation every few ticks, in the worst case scenario.
I don't want this happening (especially for a game with "satisfying movement" as its sales point), but I also really don't want to go through the hassle of porting the game to Unity DOTS, either.

How should I go about this?

 

I have recently been corrected on this: Unity physics IS deterministic, and the project setting flag that indicates it will make "physics more deterministic" can be misleading since it seems to impy that it still won't be fully deterministic.

So yes, Unity built-in physics is deterministic but floating point rounding and cross-platform representation issues remain (in any physics engine, hence actual gameplay-physics simulation in networked games is rare).

One of the surest ways of breaking determinism is to multiply movement/velocities with deltaTime rather than fixedDeltaTime.

Also worth noting that Fish-Net has client-side physics prediction built-in. Just in case you're attempting to build a system that already exists.

 

Non deterministic physics will not give you an unpleasant experience with client side prediction and reconciliation. In fact all major FPS titles use non deterministic physics. CSGO, Fortnite, Valorant etc. Determinism has its uses and can make multiplayer development much easier but it is not commonly used for the FPS model as it is not necessary when only prediction the own player characters which is common in FPS games since other player can never be accurately predicted and would lead to imprecisions when firing.

Also most FPS games use movement that is driven by kinematic character controllers. These will give you very stable results (not fully deterministic) that will hardly ever lead to noticeable error corrections.

 

Thanks for this info! I always thought of these AAA games to have some kind of "advanced" physics systems (especially since I've seen some hiring offers for physics engine designers), but if this is the case, I guess the non-determinism won't cause that much of a problem for me anyway.

I guess I'll stick to using the current solution.
Thank you guys for the insights, since this concern has been bugging me for quite a while now.