Collision on a Client/Server system - practical?

[sipickles]

Hello,

I've been tinkering with bullet for a while now. It works very well on a single local system.

I've seen a few other posters who have similar problems to this, but I thought I'd start a new thread to discuss some situations and possible solutions.

Situation:
Server AND client both run btDiscreteDynamicsWorlds. Server provides corrective updates to client, which does an immediate warp of position and linear/angular velocities.

Problem:
Collisions produce unpredictable results. Updates from server contradict local physics predictions causing heavy warping and objects jitter heavily, taking time to settle down.

Solution 1:
Turn off collisions on client. Still use physics engine on client to move players smoothly. Rely on server to correct after collisions - Susceptible to lag I assume.

Solution 2:
Turn off collisions on server. NO! Server is always right!

Solution 3:
Turn off all physics for players on Server. Instead add validation code for all player movement.


Love to hear your thoughts on these ideas....

Thanks

Simon

[sparkprime]

Is it possible to, rather than warping your bodies back into place, to drag them there slowly using velocities or forces?

[bengarney]

Networking physics when they need to be synchronized between client and server is hard.

Doing it one-way isn't so bad, I did it (using Bullet! Great API!) for a game - description of the approach I used is here: http://coderhump.com/archives/275 But that's purely as a client side effect, with just some starting data being synchronized.

There are some things you can do to help keep everything in synch when you have a small number of physical objects that need to be synchronized. (ie, if you basically have enough bandwidth but latency is higher than you'd like.) I talk about some approaches for this in a talk I gave at Austin GDC. If you're a good physics programmer but know very little about networking you might find this informative: http://coderhump.com/austin08/

Glenn Fielder, one of the developers for Tribes:Vengeance, did a good series on networking game physics at http://gafferongames.wordpress.com/game-physics/. This might be helpful, his demo is pretty impressive.

If you're in a more controlled scenario (like doing a distributed simulation for the DoD with high-speed, high-reliability links between sim installations), you can do "more" physics and keep things more consistent between client and server. That's really only an option if your target audience is 30 guys, and you have a budget of $300mill for high-end custom hardware.

The best policy for the rest of us is to pick and choose our battles - figure what is minimally needed to make the gameplay/goal of our app work, and let chaos reign where determinancy isn't needed.

[bengarney]

http://gafferongames.wordpress.com/2008 ... ment-10129 is interesting (scroll up to top of page for blog post, the comment linked has a working link to the slides).

Of course the big issue for a multiplayer game is cheating. If you don't have to worry about that, then you can be more flexible. It's unclear to me that this talk deals with cheating (since he mentions it's for Co-op stuff). This is fine if your situation can deal with it. (And remember - if anything is indeterminant, being cheat-resistant will catch this as well, since "client does wrong math" is indistinguishable from "client is cheating" on the server's end.)