2 Players shoot ball to the same wall in turn base game mode.

To synchronize a complex physics simulation with deterministic results is challenging (ok, impossible comes to mind, but I don't want to discourage you ).

Here're some ideas:

The hard way:
Synchronize all input including time ! If you just have one millisecond lag which will not be considered in your sychronization a completly different result could occure. You need to use the same order of events and commands in both simulations, even if it seems that the order will not effect the result.

The other way:
Don't try to synchronize at all. If it is a turn based game, the other player is just watching. You transfer the visual information to the inactive player and don't try to simulate the physics at all. Even lag and a update rate of 10 fps "could" be enough for just watching. A delta compression could be used to decrease the bandwidth demand.

The other way++:
If you want to further decrease the bandwidth you could try to run the physics simulation on both to predict the movement of the objects, but you correct the object movement with the data from the active player a few times per second.

I read an article about this recently... wish I could remember the URL. Basically, you render everything on the client and send input information back to the server (spells cast, movement keys pressed, etc) and the server reconciles everything and sends state information back to the client (character position, amount of health/power, etc) and if there are discrepancies the client "rolls back" and replays events based on the server version of the info. That's what most online games these days do and it's how the Call of Duty games and such revolutionized online play. Most of the time everything will be smooth but every once in a while you'll have client and server data that doesn't match but the server always wins in this scenario.

The problem is, all physic system we try (Havok, PhyX) are undetermine.

Yes, undeterministic simulation is bad for this! There exists physics engines that can be made deterministic, if you take special care controlling the CPU math flags, and also allow latency in all user operations so that all clients have all the input data for a given simulation step when that step starts.
If you want to go that way, I recommend using either the Open Dynamics Engine (ODE) or Bullet Physics, both of which are available with full source code, so you can track down and fix whatever non-deterministic behavior you find. (For example, there's a random number generator re-ordering the order of matrix row relaxation in the ODE solver, which you have to seed deterministically)

Another option is to say that it only has to be "good enough," and use some server as the "master" copy, and have that send out snapshot of some set of objects each frame (whatever your budget can allow) and cycle through them, trying to bring them all in sync over time. Most of the time, the same inputs plus the same simulation constraints will yield similar-enough behavior that users are unlikely to notice. You might want to send important decisions (life/death, etc) through the server before displaying them to the end users, to avoid confusion, though.

I also recommend reading through the FAQ, which has some links to these issues.

I would think sending the "State" of the simulation every X mS would be suffice:

So, you send the same input from P1 to P2, P2 starts the simulation as it normally would, but every X mS, it gets the full state of all the objects that P1 sees, sets it's objects to be at the same position/angle/velocity/torque, and continues the simulation.

This may get "jerky" if the simulation has branched between the 2, but you should be able to work out a X time that it doesn't look so bad. Even something like every 250 mS would probably be OK.

That's just how I would probably try and do it, I don't have any experience with this myself.

That's just how I would probably try and do it, I don't have any experience with this myself.

Thank you for that disclaimer! Many people aren't that honest.

The math of your suggestion is something like this: Suppose the state snapshot rate is every 250 milliseconds. Suppose there are, as in the original poster's example, 100 bricks and 1 ball. Suppose each object requires position, velocity, orientation, and angular momentum. This breaks down to 12 floating-point variables, totalling 48 bytes. This means 4848 bytes 4 times a second, or at least 20 kB per player per second upstream from the server. If you only worry about 2 players, that's 40 kB per second, and may actually be doable on many home broadband connections.

However, if you want to get to 99% of the market, you have to aim for 8 kB or less per second, and if you want more than two players in your game, the bandwidth requirements end up being too big far too fast.

[quote name='BeerNutts' timestamp='1306273554' post='4815322']
That's just how I would probably try and do it, I don't have any experience with this myself.

Thank you for that disclaimer! Many people aren't that honest.

The math of your suggestion is something like this: Suppose the state snapshot rate is every 250 milliseconds. Suppose there are, as in the original poster's example, 100 bricks and 1 ball. Suppose each object requires position, velocity, orientation, and angular momentum. This breaks down to 12 floating-point variables, totalling 48 bytes. This means 4848 bytes 4 times a second, or at least 20 kB per player per second upstream from the server. If you only worry about 2 players, that's 40 kB per second, and may actually be doable on many home broadband connections.

However, if you want to get to 99% of the market, you have to aim for 8 kB or less per second, and if you want more than two players in your game, the bandwidth requirements end up being too big far too fast.
[/quote]

Good points. I typically look for the easy solutions to these things, and I don't have a lot of experience with this kind of physics/network interaction.

I was assuming it was a 2 player thing (as the OP's post was detailing P1 and P2), and assumed it was one sending to the other only (if it's P1's turn, he wold send his state, P2 wouldn't have a state in his turn). I also assumed it was P2P. I didn't do the calculations myself, but, just thinking conceptually about it, I thought it'd be doable.