Understanding multiplayer local prediction...

Using a client input value to send the flip command from guest to host, then sync’ing the flipper’s position back to the guest unfortunately isn’t cutting it even under optimum conditions of same machine using the LAN bandwidth profile. There’s still too much lag for the precision timing required for the game.

I still don’t really understand what local input prediction actually does but I tried enabling it whilst also flipping the flippers on the guest but it just causes the flippers to jitter – I suspect it’s because they’re normally moved every tick by applying a physics force, but in my multiplayer test, I _think_ they’re only being moved “on client update” and possibly getting slightly out of sync so they keep being moved back and forth slightly showing the jittering.

I’ve also tried controlling the flippers using “unreliable” messaging – that reduces the lag but the syn’cing is still messed up.

And I’ve also tried running the physics on both then sync’ing differences when the ball’s hit – but this just highlights what I think is another fundamental issue – there’s many occasions when the ball hits a flipper then almost immediately hits an opponent’s flipper. Either flipper could be moving, so if they’re out of sync (which they inevitably will be due to physical network/hardware limitations), the positions of the flippers, and particularly the ball, quickly diverge and any subsequent attempts to synchronize them causes noticeable jumps.

None of this comes as a surprise – I’d concluded several years ago that networking Flippee Ball would unlikely work satisfactorily for the reasons above and that sync'ing physics is notoriously difficult.

It’s a shame because I’ve had many requests for network play – but unfortunately, it’ll have to stay local only.

The good news is that I now (mostly – see above!) understand how the plugin works and almost certainly will use it at some point in the future - it seems pretty comprehensive and straighforward to use.

EDIT - just adding this screenshot so anyone reading this has some idea of what I'm talking about!

There will always be some delay when data is sent over the internet. That is simply a physical limitation of networking.

You can make each player’s flipper respond immediately on their own machine, but if the host remains authoritative over the ball, the visible ball reaction will still arrive later. Input prediction does not remove latency, it only tries to hide it by showing the expected result before the authoritative result arrives. And it's just used for inputs, so controlling something. You can't really apply this directly to a physics behavior-ball.

That is generally what real-time multiplayer networking is about: hiding latency through prediction, interpolation, reconciliation and, in more advanced cases, rollback.

For this particular game, one possible hybrid approach would be:

• Let each peer activate their own flipper immediately.
• Send the input, timestamp and relevant flipper state to the host.
• Let the peer temporarily predict the resulting ball collision and trajectory.
• Keep the host responsible for deciding the final authoritative ball state.
• Synchronize regular ball snapshots from the host.
• Interpolate normal movement and gradually reconcile small prediction errors over several frames.

A more advanced implementation would keep a history of inputs and physics states so the client or host can rewind and resimulate from the collision time. That is broadly referred to as rollback.

Note that this is just a simplified overview. There is no single setting that makes networked physics responsive and consistent. the appropriate solution depends on how much latency, visual correction, implementation complexity and potential cheating you can tolerate.

Also keep in mind that that applying these techniques using the physics behavior may not be feasible. It would probably be easier to run your own event sheet driven physics solution. Separating the actual ball's collision box with its visuals could also help to further hide position corrections and so on.