Authoritative server physics update

[Gregory]

Hello guys. I'm starting a network based game with a authoritative server. The clients will send the inputs states 30 times/second and the server will broadcast the new game state at 10 times/second.

How do you think is the best way to update the server states with the received inputs?

1 - Each new input the server receives, it updates that player state (position, rotation....) and before broadcast the new states, run the collisions. (the problem here is that the physics will not run at fixed time steps because it can receive more than one input from the same client before the physics runs).

2 - Queue all the inputs received from clients and run only one client update each player for each physics update/broadcast. (The problem here is that the updates can go out of sync because the queues. At each physics step at average the queues will have three client inputs but it can accumulate more and go out of sync).

For me the best is the second option with a simple trick: if the queues get more than 3 inputs I can run more than one physics step before broadcast to get the queue back in sync. Maybe it works...)

What are your opinions?

Thanks. Gregory.

[Ixrec]

My impression is desync is to be avoided at all costs so #1 is probably better than #2, but I know I'm forgetting something and this stuff is really easy to get wrong.

http://gafferongames.com/game-physics/
http://gafferongames.com/networking-for-game-programmers/
These posts might be helpful if you haven't seen them before.

[Gregory]

Thanks.
He says:

Each character object has its physics advanced ahead in time individually as input rpcs are received from the client that owns it. This means that the physics state of different client characters are slightly out of phase on the server, some clients being a little bit ahead and others a little bit behind in time. Overall however, the different client characters advance ahead roughly in sync with each other.

I really don't understand how the updatePhysics method that he use works. Why it needs the currentTime?

Maybe I will need to run the collisions individually for each client at each input arrived?

For me the second option still seems simpler...

[Ixrec]

For just choosing your synchronization strategy, focus on this post for now: http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/

You'll note that option #2 from your post is nowhere in here.  I *assume* because it would result in desync problems so consistently that it just wouldn't work in the real world, but sadly I don't have the time to go test that myself.

[Gregory]

I'll make good read of the articles and I will try the two ways. I think it can be helpful for others.. It's a very important point on network programming that don't have much material on the internet.

Thanks.