In several blogs/forums, suggest applying a constant time lag(say 100ms) between the server time and the client time as Humans can adjust to a constant input lag rather than random jitters
For more details refer section 7.2 from this blog. (I am not referring to interpolation and other technics).
But in my case, I am trying to create a p2p game where the position(and other properties) of the sprites are synced between the player but it needs some time to complete the sync. So now I am trying to implement a delay on when the sprites are rendered. The problem is I am trying to using Phaser physics to update the states but want to render from old states.
For example, Let the game physics steps are occurring at a constant delta of 16ms but during render time I want to render the sprite as it was say 160ms ago (constant delay of 160ms or 10 steps).
I am trying to figure out the best way to achieve this.
Not sure if I fully understand your problem, but I’ll give it a try based on my (limited) experience.
Your client should not really be doing the physics for the sprites that you do not control directly, eg. The other players. The server will send you updates at a fixed rate, and those updates will say what the new coordinates of the object are.
Your job is to interpolate between these with a delay, but you are not using the physics engine to do this. As for the delay, like in the tutorial you want to keep a buffer (list) of the server updates, and process them one by one. If you reach an update that is later than your delay, then you don’t process it. So if your server updates ever 50ms and your pre-configured delay is 100ms, then you will always be processing up to 2 updates behind the server.
@Is0tope I am not following that tutorial exactly
In my case, there is no server so the clients have to run the physics. If 1 client creates/modifies a Game Objects it the changes get synced with the other client(s) using a p2p(peer to peer) connection within 20-100ms depending on the network.
Ah apologies, I missed the part about it being p2p. In that case I am not so sure. Ultimately it will boil down to some sort of queue with updates in it, and reading that queue with a delay. I guess you can send the input instructions over the network eg. Press left, press jump etc and assuming the physics engine is deterministic enough then it should work. Bear in mind you will need to keep all of it in lockstep, and make sure the times are correct etc. That would require sending (ideally) the tick number on each update.
We also used this source for reference: Client-Server Game Architecture - Gabriel Gambetta
Note, I found it all very difficult and I’m glad I got help.
From what I understand we currently use a system where the server creates “StaticObjects” and “DynamicObjects”. Also these contain staticList and dynamicList properties. The server basically emits these properties to the client when changed.
With code such as:
socket.emit(MSG_TYPES.CREATE_OBJECT,…)
I guess if you use peer-to-peer, maybe look this up with Socket-io (or other network protocol which you are using).