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

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

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

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.

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