Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This question already has an answer here:

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!

share|improve this question

marked as duplicate by Seth Battin, Anko, Byte56 Apr 17 '15 at 2:04

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

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.

share|improve this answer
This one came up in the low-quality queue, and I voted to delete because it could just as easily have been a duplicate vote against the OP. – Seth Battin Apr 16 '15 at 20:55

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.

share|improve this answer

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.

share|improve this answer

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)

share|improve this answer