I am currently tackling real-time multiplayer physics updates for a game engine I am writing. My question is how best to use Box2D for networked physics. If I run the simulation on the server, should I send position, velocity etc to every client on every tick? Should I send it every few ticks? Maybe there is another way that I am missing?
How has this problem been solved using Box2D before? Anyone with some ideas would be greatly appreciated!
You might see this question which deals with the same challenge...
Lag compensation with networked 2D games
Though not specifically about 2D physics, the same issues apply.
Something else to think about, is a clear separation of 'gameplay physics' which needs careful synchronization, and 'special effects physics' which doesn't.
Physics used for effects only, such as explosion debris, does not usually need keeping in sync, and can run independently on each client. It doesn't matter if it looks a bit different on each.
One of the most important things in game networking is to only send information when it's needed.
So the answer is neither of your suggestions. You run the simulation on both client and server (or just clients if peer2peer). If you press the up arrow, you send a packet that you now have initiated an upward motion, and until you stop moving in that direction there is no need to send any more packets, as both the clients and servers can run their physical simulation based on the information in that packet.
It's called Client-side prediction.
What kind of game is it?
Is it possible to keep the 2 simulations entirely in sync?
If you start the 2 instances of the simulation in exactly the same state, and update with a fixed timestep, then they should remain synchronized.
But when you do anything to a physics object, you send a message to all clients telling them what to do and on which frame.
So if you were making something like 'Worms' or 'Angry Birds', and the player launched a projectile on frame 1000, you'd send a message saying 'on frame 1000+N' we're going to spawn a physics object with these parameters.
Of course, this will add input lag. And you need some way to ensure that no player will get too far ahead to respond to messages on the correct frame. Maybe a 5-10Hz 'clock' message, telling all clients 'you may advance your simulation to frame N, but no further'.
(I believe that this is how online RTS games work, where it would not be practical to send the positions and states of several hundred units every update, and where a fraction of a second's lag between giving an order and the unit executing it is acceptable)
