Sign in to follow this  

Physics & Networking

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I'm trying to make a small race-game to play with friends over the network, something like Micro Machines. I don't have that much time for this project, so I decided to use ODE for the car physics (and since I'm bad in physics myself...). That could work nice, but I'm afraid synchronizing the game over the network will be very difficult with more advanced physics like ODE does. So before I continue with ODE physics, I'd like to make sure if it works with networking. I have very little experience with making network games, but I do know synchronizing everything is a difficult job. You could send the current matrices of all cars over the network, but since other clients also need to predict movement to fill the lag, clients should also know something about their movement directions and velocity, I think. I could let every client use ODE, and send the player commands like 'thottle', 'steer to the left' or 'break'. But I'm afraid the actual car positions/angles will differ completely on each client after a short while. Therefore, I could also send the matrix of each car over the network to correct the cars. But would that work well? Can ODE handle the position/rotation changes every time? Or does it mess up the current physical state? Another 'solution' could be letting the server calculate ALL the physics. Clients won't do anything with physics, they only receive the car matrix so they can put them in the right place. But then again, how to predict the car movement if the server doesn't update it fast enough? In that case I also need to send data for all other small stuff that can collide with the cars, like barrels stacked up beside the track. Does anyone have some good ideas? Greetings, Rick

Share this post


Link to post
Share on other sites
Hmm, I haven't done any network coding, so please take this up with a grain of salt :P

What I would try to do is keep the physics simulation on the client side and server, but 'sync' each other with basic 'important' data.

So for example, in a VERY simple case let's say your store the current position and the velocity vector on the client, and do the rest on the server. When needed, the server sends you a new position/velocity and you just make sure your client agrees with it, fixing up appropriately if needed. So you're running the simulation on both ends, but just allow enough communication to keep each other in agreement.

- Graf

Share this post


Link to post
Share on other sites
Networked physics is really hard when working with stepped simulations like ODE. It doesn't hold much in common with common approaches like trying to predict object positions by extrapolation time and velocity, since the simulation is so advanced. Especially when dealing with many objects that collide with each other. Desynchronizing is gonna kill you. Just imagine how out of sync a pool table would be with a little lag.

The client predicts and simulates that this ball collides with that one, which collides with that one, which sets a third one in motion.
But in reality, on the server, the first ball missed and hit a border, and collided with another ball across the board..

I hold by no means any expertise in this area. But from what iv heard, no game has so far been able to deliver a really good solution for this.

How halflife2 solves it by cheating. On their multiplayer maps, the physics is dampened and comes to rest faster. And they avoid using "interacting" physic objects that collides with lots of other objects on multiplayer maps, of the kind you can see in singleplayer.

Also remember that since its a racing game, you probebly want each client to be desicive over their own car's position, since you want it to respond instantly to the keys, and never suffer over-time synchronization interpolation to get back in sync with the server simulation.

Also, this article by Gaffer might be interesting: http://www.gaffer.org/archives/zen-of-networked-physics

Share this post


Link to post
Share on other sites
I second that post above. For a racing game, the system used is often Peer-to-Peer. Each client is held responsible for its own controlled physics (here, cars), and the car collisions are hacked and dampened. Think Gran Tourismo, where car-car collisions are fake, cars are just pushed aside, can't flip around... If you go client-server, it will be much harder. However, if you have lots of interaction with the track, synching the objects will be harder with p2p than in Server-Client.

if you go client-server, the client will have to run its own simulation, in parallel with the server, to predict the collisions, and the final client will be an interpolation between the two. You will also have to predict the other client's positions forward in time (since the other clients will always lag behind), but that's valid whatever system to use. Note that in Server-Client, the discrepancies between clients will be greater, since they have to go through the server first.

In p2p, each client controls his own car, and send the car's data directly to other clients. The bandwidth is better distributed that way, but it's easier to hack, obviously, since there is no authority that checks the clients calculations. Also, it is dangerous to store other client's informations, which can be hacked and used for other dark purposes. Each clients know every other clients.

In client-server, both run simulations. Only the server knows the real adres of the otrher clients. The command packets are sent to the server, which calculates the position of the server, and send correct/accept messages to the client. The positions are then re-inserted into the client's simulation, in a feedback system. There are problems when the client collides / slides on other clients, since there is no way to predict the accurate position of other clients, so you get more discrepancies, and your car gets 'jerked' around a bit, like in counterstrike when you collide with another player. But calculations of client-servers, for a complex car game, are bound to diverge, so you'll need some smoothing between the calculated positions on the two machines, which might make the car a bit floaty and unrealistic.

my 2 cents

Share this post


Link to post
Share on other sites
The only variables that really matter are position x,y(,z), velocityvector and rotation vector, and maybe some other stuff like car type etc. To make this look fluid use interpolation or put the external cars in the same ode physics system and correct the position with data received from the player.

Sorry if this wasnt very helpfull.

Share this post


Link to post
Share on other sites
Hello,

I'm actually facing the same issue, although the game is a RPG and should suffer less from discrepancies between the client and the server.

After googling a bit on the problem, it looks like a not-so-bad solution for this would be:

- The client and the server both run the physics engine
- The clients send its input to its own physics engine, and to the server
- The server sends the position + velocity of each element to the clients, with a frame tag. This frame tag is kept synchronous on clients and server
- The client receives this information, fast rewinds to the frame tag, sets the correct positions, and fast forward to the current frame tag.

With lag, you could get some odd behaviour: for example, you crash into an opponent car, and then the server tells the client: "Oh, 1 second ago, your opponent actually applied the brakes", and suddendly your car will be back on the road! (Well, not for long, since the inputs you applied to recover from the crash will most likely send you off the track now).

Share this post


Link to post
Share on other sites
Thanks you all!

Luckily, my race game is quite simple. Only the car positions and collisions are important. Other small flying stuff like pillons aren't really important and can be calculated by each client individually. But its gonna be hard anyway I'm afraid... I shall keep your tips mind.

Greetings,
Rick

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Obviously if the input to the discret constraint solver (i'm not sure ODE has a continuous one, does it?) and the timestep is the same, the outcome will be the same (provided the same underlying floating point hardware as well). If you can use a continuous solver it is at least ensured that you do not miss any collisions on the way but due to aproximations in the intergration steps of the solver you will most likely still discover differences, especially with large of heavily varying time steps.
Bottom line is, use fixed time-steps for the physics update (sync asynchronously with rendering and if necessary game logic) sync the objects position, rotation, etc. over the network as usual and update the motion state of your rigid bodies once every n-th physics step from the master simulation on the server. This should work well with anisotropic friction for your weels as well as rigid body collisions for nice crashes. Lag interpolation is already inherently part of the solution.

-- Cheers, Chris

Share this post


Link to post
Share on other sites

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

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this