How can I sync billiard balls in network?

Question

I'm developing a billiard game my problem is I don't know how can I sync balls in network

I use forge for networking but feel free to answer photon or unet because I know them.

What I tried

1.sending position and rotation of each ball in network

2.sending force direction and Intensity inside network

networkObject.SendRpc(RPC_SHOOT,Receivers.AllBuffered,force);

    public override void Shoot(RpcArgs args)
    {
       Vector3 Force = args.GetNext<Vector3>();
       GetComponent<Rigidbody>().AddForce(Force);
    }

I don't know why but when I send force direction and Intensity in network sometimes Physics is different! I asked this question in forge forum and they tell me:

It's non-deterministic It's how most physics simulations work Because of floating point inaccuracies and different CPU architectures and a whole load of other factors That's how PhysX works Well PhysX is technically deterministic for the same inputs But all inputs have to be identical

source is available:

https://github.com/smkplus/BilliardNetwork

Answer 1

In UNET I’d just add a Network Transform to all the balls and that would easily take care of position and rotation. I’m not sure about forge though.

If that’s not an option, why don’t you just use something like RPC to add force, the problem could be that physics might act a bit different for both clients though.

So another option could be to create a separate game object to store ball positions, and at the end of every turn they would get updated by the last player, and then checked on each client if the positions of the balls are the same as values, if not then move them.

Hopefully this helps you, that was just some ideas.

Answer 2

In a networked scenario, you should not try to rely on physics determinism to keep your simulation in sync.

Even if both players are running identical binaries on identical chips, the difference of a single fixed timestep due to network latency, or a single object being spawned in a different order due to any optimizations happening in the engine's internals, is enough to introduce divergence.

---

Since billiards is a turn-based game, the simplest and most robust approach is to alternate authority over the simulation.

The player who takes the shot simulates the physics locally, and sends position & orientation updates to all other clients, who are for the moment just spectators.

Each spectator maintains a buffer of recent updates from the current player, and uses that buffer to show a state some time in the past. Not far - just enough to be able to absorb the occasional missed or delayed packet without visibly stuttering. This lets them always show an interpolation between two actual positions & orientations that occurred in the current player's simulation - they never need to extrapolate or simulate the behaviour themselves, and the balls always end up exactly where the current player's sim settled.

You may need to adjust the interpolated position slightly, to ensure a ball doesn't sink into the table on its way into a pocket, or to ensure the ball doesn't take a shortcut when changing direction, blunting what should have been a sharp collision, but these are purely visual fix-ups that don't affect the final gameplay state of the table in time for the player's next turn.

Then you switch authority and the next player takes the shot.

Note that this only works if you're willing to trust each client to fairly report their play. If hacking is a concern for your game, then you'll want to use an authoritative server under your control, and let all players see a copy of the simulation from the recent past. You can a wind-up animation of the pool cue to cover the latency before the first results from the server are available.

---

A more robust, but also more intensive solution is to compute the trajectories yourself, so you're not at the whims of a fully general physics solver, and can control the operation explicitly. I wouldn't do this for most games, but for billiards the problem space is reasonably small and well-studied, so it would be feasible to write a "billiards engine" that solves just this case exactly the way you want it.

Since you're no longer bound to iteratively approximating the outcome frame by frame, you could have one client compute the full future of the table at the moment the ball is struck, and transmit the exact sequence of actions to the other clients like a set of animation keyframes.

You could even use fixed point math to sidestep the complexity of getting floats to agree between binaries / differing hardware. Then the player could simply send their action with the pool cue, and all spectators (or the central server) can independently reproduce the outcome of that action (and check each others' work to spot cheating).