Physics Collisions + Network Latency

Hi all,

Im trying to put a game together but it looks like ive stumbled across a dead point. The game is a multiplayer car game with physics and collisions. The initial idea was only to send the forces that are being applied onto the car through the network. This will give a smooth look on each player’s screens, which theorehtically, it does. But one problem. What if a collision occurs between two cars. The forces will change dramatically, but due to lag and whatnot, on one screen a collision can have happened, on another, it may not have. Obviously, its a problem.

I couldn’t find many articles on google describing this, and quite rightly so, because most article refer to FPS and a stray bullet isn’t really noticed.

Is server side collision detection and response a good idea? If so, how much of it? Just the collisions between two players and terrain-car client side?

What about if we only used forces. I.e. dont send anything other than forces and torques. Then we do a client side positions comparision wereby the client compares what he sees by what he should see (sending positions) and adding a force to bring the car back on track? Good idea? Bad? It can possibly take a while for the car to be back on track and it also might look weird if the car is drifiting sideways…

What about P2P style networking? send the force and torques via a P2P network (does P2P reduce ping times?) and other statistical things to a server. Also, the server will set out the rules for the game. E.g. how long it will last, what map…etc. Again, good idea? Better than the rest? worst? Im confuzzled! :?



As I understand the concept…

Usually you have a single machine designated as a server (which may also be one of the player machines) Input forces that would affect multiple players are sent to that server machine and the results are sent out as world updates to all players. This ensures synchronization of all player worlds.

So yeah, server side… and all multi-player affecting actions. (For example, having your driver pick his nose is something that doesn’t need to be shared with the server… :wink: )

Thats part of the problem yes. The second part is how to handle collision detection between two vehicles…

Ok, take this scenario. Two cars almost parallel are traveling. They will eventually hit each other. Now one of the players (call him player1), swerves at the last minute to avoid a collision. If we are acting on forces, the other player (player2) will see player1 as carrying on forwards and a collision will happen between the two on player2’s screen. Although player1 has swerved 200 millis ago (average ping).

What should happen in that scenario?


I think generally the server could keep a synch’ed clock and retrace historical events to a certain degree. IOW, at the moment of impact on P1’s screen, he sees an impact, the swerve is sent to the server, the server see the impact happened at t-200ms and updates what the correct position of each car should be and sends that out to the players. P2 would see the collision slightly later, but that’s typical of networked games. The important thing is that the server has an up to the minute picture which can be historically altered up to a certain amount of time into the past.

Anyhow, that’s really off the top of my head how I’d approach it without much research into things, so take it for what it’s worth. :slight_smile:

I’m doing a multiplayer game, too. My approach is to have a server (or multiple servers) deciding all the things (collisions etc.), as it becomes a MMORPG with a space shooter and I don’t want the clients to be able to cheat. The server(s) send(s) position and velocity information to the clients - but only occasionally (on special events like hits and after a max time).

To have smooth movement etc. on client side the client does all the computations (for entities it displays) the server does, too.

Clients commands (like steering, shooting,…) are sent to the server and processed there without assuming they were in the past - like in FPS you need a fast ping to react fast. Though the clients do not react on messages from the server (which would have twice the latency) but on the local events a little bit delayed (when they ‘think’ the server would process them).

First tests are promising. I expect to have it completely working in the next couple of weeks (if real life spares me on the weekends :? )