Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm trying to implement a client/server physics system using Bullet however I'm having problems getting things to sync up.

I've implemented a custom motion state which reads and writes the transform from my game objects and it works locally but I've tried two different approaches for networked games:

  1. Dynamic objects on the client that are also on the server (eg not random debris and other unimportant stuff) are made kinematic. This works correctly but the objects don't move very smoothly
  2. Objects are dynamic on both but after each message from the server that the object has moved I set the linear and angular velocity to the values from the server and call btRigidBody::proceedToTransform with the transform on the server. I also call btCollisionObject::activate(true); to force the object to update.

My intent with method 2 was to basically do method 1 but hijacking Bullet to do a poor-man's prediction instead of doing my own to smooth out method 1, but this doesn't seem to work (for reasons that are not 100% clear to me even stepping through Bullet) and the objects sometimes end up in different places.

Am I heading in the right direction? Bullet seems to have it's own interpolation code built-in. Can that help me make method 1 work better? Or is my method 2 code not working because I am accidentally stomping that?

EDIT: Another problem with method 1 I just noticed is that the collision response will be way off for collisions against non-synchronized objects. Kinetic bodies kind of shoot stuff to infinity sometimes since they can't be knocked back.

share|improve this question
    
A few things that might help you get an answer: What language/engine are you using? What type of connection is it? How bad is the synchronization deficit, compared to the ping to the server? –  Fibericon Sep 10 '12 at 7:03
2  
The second option doesn't work because you only set the velocities to the server values after a few frames so between each packet there are a few frames where things can drift. I would recommend reading all Gaffer's posts on game physics, you should probably first read 'fix your timestep' but here is the final article which talks about networked physics gafferongames.com/game-physics/networked-physics –  Roy T. Sep 10 '12 at 7:11
    
I'm using a self developed engine in C++. However I'm pretty sure the synchronization deficit is not that bad, probably 1 frame over ping if I had to guess but I'm still doing mostly LAN only testing. I'll check out those articles and yeah you are right that velocities are off. However things are way off, like the crate is across the map. Shouldn't explicitly setting the transform make thing generally conform eventually? (even if it's not pretty yet, jiggles, etc.) –  Lucas Sep 10 '12 at 9:07
    
I read Gaffer's post and it was informative but it seemed to deal mostly with player movement, which is something I already have working. I've been reading around and it seems like my method 2 code is practically identical to the method used in the Unreal engine. They don't provide many details but it makes me wonder if the idea is sound but my use of Bullet is just incorrect. –  Lucas Sep 11 '12 at 7:11
    
An interesting read, that is partly related to your topic: gamasutra.com/view/feature/3094/… . Its about an rts and its not about physics, but they get to the point, where they have to sync a simulation on server and clients. The way they do it? They run independent simulations on both client and server, but the server sends sends packages that make sure, that the client simulation does not diverge and is corrected, if it does happen... –  tom van green Sep 18 '12 at 10:48

3 Answers 3

up vote 3 down vote accepted
+50

You need proper client-side prediction.

You should really read in details the link Roy T. provided you in his comment. It describes what to do with player input & character physics, but the principle stays the same for "server-driven physics".

This isn't trivial to implement but in a few words, for game objects that need to be in sync:

  • Run the physics on both the server and the client;
  • Server sends updates regularly;
  • Client continuously & smoothly re-adjusts its physics world to the server values.

So yes, you're heading in the right direction with your method 2. Just overriding the values isn't enough though, you will get jumps on the client, what you need to do is smoothly & continuously interpolate to the server values.

For your actual bug, I'm not familiar with Bullet, but you're probably missing some values e.g. you've set the linear and angular velocities, but have you set the accelerations?

share|improve this answer
    
Thanks! This makes me feel better that I am on the right track. I'll go over my code with a fine tooth comb now. Maybe some notification is not getting fired or as you say I'm missing a value since method 2 should (jerkily) work. –  Lucas Sep 19 '12 at 17:46

What I do personally is whoever is hosting the game creates the phsyics world and sync objects with the clients. Even if its a p2p network scheme I still base the physics engine on one of the players clients.

Other physics that I use that is purely eye candy doesn't even need to be synchronized.

In a prototype I made a while back called "boilerzerker", I ran physics on the host and particle effects(also using physics) were not synced across a network but independent for each client because they were eye candy.

share|improve this answer
    
Thanks, yeah that's one way to go about it. However it doesn't result in nice collision responses on the client to stuff that client does and also the eye candy stuff won't always interact correctly since it can't push back on the server things (at least within that timestep). I feel like this must be possible since engines like Unreal and Source seem to do it. –  Lucas Sep 19 '12 at 3:23
    
eye candy doesn't need to sync, it can be per-client calculated. the response on the client is calculated on the server, the coordinates for the client are just calculated and sent back, you don't send a callback to the client saying it collided, that would probably look horrible. –  tsturzl Sep 19 '12 at 18:35

It is impossible to implement network synchronous physics worlds. Small difference in step N course much more bigger difference in step N+1 You can't apply forces or impulses to keep it sync and look realistic.

Solutions:-

  1. You can consider to sync only few objects like characters or racing cars especially if they are kinematic. But most part of the world would not be in sync to look realistic.

  2. You can have one physics worlds on server and broadcast object positions and velocities to clients.

share|improve this answer
    
You may try to play some network game with physics to see that worlds are not in sync. e.g. Need For Speed World is free and has multiplayers and basic physics. (boxes on the road and destructible objects) –  Max Sep 18 '12 at 8:04
    
I'm not sure I follow you exactly. I'm pretty sure this is possible since many games allow players to throw crates around (for example). It seems like your option 2 is similar to my option 2, but I can't get Bullet to cleanly snap the objects to their server positions. Maybe that's my root problem? –  Lucas Sep 19 '12 at 3:25
    
No. Usually it is illusion of synchronous. If you compare screens then you will see that when you bounce in boxes then boxes fly in different directions. or boxes are not physics at all (just ed animations). Number of boxes are different. When I say animation I mean there is no physics animation behind movements. They do no various tricks make picture look somewhat in sync but it is not synchronous physics worlds. You should look and compare how they move in different games. –  Max Sep 19 '12 at 8:36

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.