Multiplayer: Where to start for lag compensation?

[suranyami]

Hi. Noob at Phaser (but senior in a lot of other things).

I'm currently noodling with Phaser and Elixir + Phoenix + Websockets.

So far: all going well. I've got a simplistic space-shooter happening that sends socket protocols up to the server with position, velocity rotation info about sprites & bullets that get re-broadcast to other players. It's simplistic, but it works.

Next step is to deal with lag compensation, so here is my question:

I may receive, for instance, a "bullet-fired" message that happened x number of game-ticks ago on the other player's machine. How can I tell the (for example) P2Physics Engine: 'this happened in the past, so you should move it to where you think it should be now"?

I realise that the most obvious answer to this question is *PROBABLY* going to be "read how the physics engines work, fork one of them, and add these features yourself", but I just thought it's always worth asking the LazyWeb, just in case someone's already thought of this already.

Thanks in advance.

[ForgeableSum]

I would not recommend trying to sync physics properties/rotations and such of bullets across a network. Bullets are generally much too fast moving. It might fire and reach its destination in the time it takes for a communication to go from 1 client, to the server in one state and to the client in another. Instead, focus on syncing the objects the bullets are firing from and the time that happened. Inevitably, they will not fire at exactly the same time on both clients: your goal is to make them fire at the closest time possible. 

One methodology is to not fire the gun on the first client until the instructions get to the server and back. Essentially, this puts a delay on one client because you know the other client is a little behind (at least the time it takes to get from the server and back). This will help in high latency scenarios and is unnecessary/detrimental in low-latency scenarios (because there is a delay in client input for what actually happens in the game world).  

Write your game code in such a way that + or - a 50 milliseconds isn't going to drastically effect the results of a bullet trajectory/collision course. Unless you're using lockstep (which is insane for a physics game), a few milliseconds is something you absolutely must account for. After all, it takes 100 milli for a packet to get from new york to california. You can't bend the laws of physics. 

Another piece of advice I would give you is to consider tweening bullets instead of applying physics to them. Not only will this save drastically on performance, but you will also have more exact timings for when the bullet arrives as its destination (which makes the networking a lot easier).