# How to obtain precision of Physic simulation in Online multiplayer game

This topic is 2573 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi,

I have problem about Online multi player game which need precisely physic simulation.

Suppose my game is to shoot ball to the wall of 100 bricks objects.
Bricks are all physic object, each of them may collasp or stand remain after ball hit them
depend on the physic simulation.

2 Players shoot ball to the same wall in turn base game mode.
While P1 shooting, P2 can see the situation.
P1 will send force of shooting ball to P2. (and other info the physic needs)
Then P2 will simulate and hope the result will be perfectly same.
Every bricks stand, collasp, move or fall in same way.
We need precision in millimetre unit.

The problem is, all physic system we try (Havok, PhyX) are undetermine.
2 simulations with same input, even on same machine, will give a little bit different result.
The different is in centimeter or metre unit which unacceptable in our game.

And due to the bandwidth limitation, we cannot send update state (pos, rotation, vel, etc)
of all 100 bricks from P1 to P2 machine.

I know most of online game which use Physic system are not care much about
precision of bouncing or collasp objects that collideable,
but my game requirement need
Is there anyone have a good solution to this kind problem.

Thanks.

##### Share on other sites

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.

##### Share on other sites
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.

##### Share on other sites
Read the forum FAQ, especially follow and read all the links in #12 that directly addresses that question and includes examples as it was used in four different games, several with their source code released.

##### Share on other sites

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.

##### Share on other sites
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.

##### Share on other sites

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.

##### Share on other sites

[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.

##### Share on other sites
If this is as complicated as your game will be. You could go for a server side physics setup. This way the clients act more as dummy terminals and simply draw a graphical representation of your physical world. The clients then would only send inputs to the server, and the server would do the crunching. feel like tis approach is very bad for other setups, but might work well for you!

1. 1
2. 2
3. 3
4. 4
Rutin
17
5. 5

• 12
• 9
• 12
• 37
• 12
• ### Forum Statistics

• Total Topics
631419
• Total Posts
2999983
×