[Netcodes] [2D-Server-Client] [PIXIJS] Network fast paced game - need better direction

[Saqirm]

I started a new project, a fast-paced online game (some sort of 2D MOBA). I encountered a problem with the part of netcode about client prediction & server reconciliation.

Game Mechanics: 2D - Platformer (MOBA)  
Movement: WASD (jump / left / down / right)  
Abilites & Autoattack: J/K/L  
Architecture: Client/server (authoritative)

My netcode is using these techniques:

 Client-side prediction & server reconciliation

•   Server is sending position & data to the player, the player is replaying the last unprocessed inputs
•   Client is sending input each frame at a fixed timestep (60 times/sec) which are processed on the server-side

 Other entities are interpolated
 Bullets/abilities are extrapolated (Dead reckoning)

So far, this is working good on clients. My question is, how to handle some sort of forced movement?

For example, another player stuns or slows down you, on the server, you will be slowed down or stunned, but you will not know it before the packet arrives, since you are predicting the next state, it will teleport you back because your speed was changed to 0 or lower (in case of slow), it will immediately turn you back (teleport). 

What is a good way to handle this technique? I was thinking about interpolating between the current position and the position on the server, but it is not working well for me.

Edited May 17, 2021 by Saqirm
Rephrased article

[b10b]

If I understand correctly the player is effectively being viewed in a predicted future - so when an unexpected interaction from the past catches up with them it is jarring because it proves the recent predictions wrong.

The goal is to smooth this out to the extent it is no longer distractingly observable.

This article explains some approaches better than I would manage here:
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

The takeaway is to embrace a default 100ms lag.  Compensate the Players' inputs (rewind time to when the input was most likely made) rather than rely on extrapolating a future.  Ideally transition the state rather than interpolate data.

[Saqirm]

8 hours ago, b10b said:

If I understand correctly the player is effectively being viewed in a predicted future - so when an unexpected interaction from the past catches up with them it is jarring because it proves the recent predictions wrong.

The goal is to smooth this out to the extent it is no longer distractingly observable.

This article explains some approaches better than I would manage here:
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

The takeaway is to embrace a default 100ms lag.  Compensate the Players' inputs (rewind time to when the input was most likely made) rather than rely on extrapolating a future.  Ideally transition the state rather than interpolate data.

Thanks for your response. 

 

Yesterday i found hacky workaround by smoothing correction which works pretty well, atleast for some sort of testings

 

It is just interpolate correction or in example it slows you down or speed you up to correct your position. It works well for low latency connections, not tested for higher.

 

I will try to do, what you said. Thanks again