Box2D Forums

Hi. Me and my friends are experimenting with Box2D and we've run into some trouble synchronizing new clients with the server. The server has the "real" values of the simulation and the clients are to synchronize their simulation with the server. If the clients are synchronized from the start then there will be less to send over the network, and also there will no "snapping" of objects. That's what we want.

The problem:
It seems that if any body is touching another body in the server-side.
And the new client joins exactly when that happens
Before the first world.step for the new client the bodies are in-sync.
After the next world step for the new client the bodies becomes off-sync.

I've stepped through the world.step method and i see that the internal values indeed are different.

Is there any way to for example:
- suspend the world
- clear all contacts
- set internal values

so that the new client can join safely and become synchronized for all the next frames as well.

Anyone who has done a network game with Box2D, please share your opinion.

Yeah, Box2D does some caching to improve performance, so starting a simulation midway with just positions, angles, and velocities isn't enough.

I'm not sure if there is a way to clear all contacts, but I know there are SOME internal values that can be set without messing too much with the source. I can't think of any on top of my head, but I don't think the ones that you can alter are enough, though. So you may have to alter the source to get the results you need.

There's an option of having the new client simulate and sync a lot for the first few seconds before the user can actually do anything so the client's cache catches up with the server's cache. I'm not sure how effective that would be, but it's an idea.

thanks for confirming this.

about the initial syncing process. problem is that there's no guarantee that the game will ever reach a state where no objects touch each other and thus in the way i sync right now, it would cause the new client to wait until the game reaches that state, which could probably be forever.

can i assume from the lack of replies that there is no easy way to let a client join mid-game using box2D and be in-sync from the start?

Hi ColacX. This is some tricky stuff - I expect the lack of replies is only because you are doing this already, which actually makes you one of the leading authorities on the subject

I did some similar stuff a long time ago in 3D with the ODE engine and it was no picnic. As long as you give the same inputs to all simulations, theoretically they should run the same (although there are of course plenty of other problems from floating point precision on different architectures etc). As long as you add the new body in the same time step, theoretically the outcome should be the same. So for example, if the server adds the new body between the 135th and 136th time steps, the client should too. This pretty much means that the two simulations need to progress in lock-step, as fast as the slowest among them can go.

It sounds like you already have a good system for checking if things get out of sync, maybe you could apply similar checks to all the data going into each simulation as well to make sure they are the same.

hey thanks for the reply. feels good to know I'm on top of things
Yeah if the client and server starts the simulation on the same frame it works really well. However the problem is when the client joins mid-game all existing bodies needs to be recreated on the client side and that is when the internal-state of the b2world differs. Joining-mid game is a really wanted feature as we want up to 8 players to join and leave as they wish.

As you said I already am running the simulations in lock-step, that does make the outcome exactly the same. Except for the problem described above.
Currently I'm testing on the same computer so I wont have to worry about floating-pointers just yet.
I'm using a checksum of all bodies property values to determine if they are in-sync or not, currently the solution right now is to simply resync any body that is off-sync which causes a snapping of the position every 60th frame or so, which looks a bit bad for the user.
The input data are in sync, I've tested that. But it's easy to just add a checksum for that too so why not.

Excellent stuff! Sounds like you are ahead of any suggestions I could have made, so glad I didn't spend time typing them out

I haven't checked the source code too thoroughly, but one thing I might try is this for all bodies, at each point where both ends should be the same. If you are lucky it might get rid of the internal optimization warm starting state:
Not very elegant, but it would be something easy to try... Erin might be able to tell you if there is a nice way to just 'reset' the internal optimizing state.

I wouldn't try to keep multiple worlds in sync this way. I would determine ownership of objects. When a world doesn't own an object, it simply tries to keep it's mirrored version in sync using the motor joint. I would probably not allow the mirrored object to collide with static or kinematic bodies. A lot of these decisions depend on the game.

IMO, trying to keep the entire state of multiple Box2D worlds in sync is a losing battle.

Check out http://gafferongames.com/ for more information on networked physics.