Raycast based server authoritative lag compensation
Asked Answered
C

6

0

I'm working on adding server authoritative lag compensation to my FPS game - specifically by using raycasts for hitscan bullets. My algorithm is as follows:

  1. Clients send inputs to the server
  2. Process movement and save all player locations
  3. For each "shooting" input received,
    3a. interpolate player positions to the time the shot was taken (based on previously saved locations)
    3b. Run a raycast while players are in those positions
    4c. process hits
  4. revert players to saved locations from step 2
  5. send all important info to clients

After struggling with this on and off for like - years (lul) - I found someone that could tell me that in Godot "Physics bodies will only be in their position on the next frame". This didn't make sense to me at first - but now does completely. If this is the case - I can't do raycast based lag compensation at all because all the times I interpolate player positions in step 3a they aren't actually moving at all. And based on how this works - I can't let the server process n frames to update player positions for every n shots it needs to process as that would freeze the game for n ticks.

Anyone have any insight on how I could do raycast based server authoritative lag compensation in Godot?

Cordiacordial answered 24/10, 2022 at 16:42 Comment(0)
C
0

Sounds like what I want to do is straight up not possible. See more here: https://github.com/godotengine/godot-proposals/issues/2821#issuecomment-870070597

If anyone has workarounds I am interested!

Cordiacordial answered 25/10, 2022 at 14:11 Comment(0)
C
0

I maybe just found that Unity offers this method to force the physics updates mid frame (maybe?): https://docs.unity3d.com/ScriptReference/Physics.SyncTransforms.html

Does Godot have something similar?

Cordiacordial answered 24/10, 2022 at 17:1 Comment(0)
S
0

I think the way this is typically done these days is to use "rollback," meaning both the server and the clients process inputs, with the client resyncing to the server's game state whenever there's a discrepancy. So you could use the raycasting method you describe above, you'd just need to be able to retcon hits if the server got a different result than the client.
https://sea.ign.com/street-fighter-next/188810/news/what-is-rollback-netcode-and-why-is-it-so-important-for-fighting-games

Standee answered 25/10, 2022 at 0:20 Comment(0)
C
0

That is essentially what I am doing - instead of rolling back though inputs to put the players in position I interpolate the player positions based on saved state (or snapshots).

Based on my understanding, neither way will work with because players only actually are "moved" in the physics world upon the "next" physics tick - and the physics based raycast operates within the physics world. So in my current implementation where I move the players around for each shot (raycast) to run - the players don't actually move and I'm just running raycasts against the players' original location.

Cordiacordial answered 25/10, 2022 at 1:11 Comment(0)
C
0

Sounds like what I want to do is straight up not possible. See more here: https://github.com/godotengine/godot-proposals/issues/2821#issuecomment-870070597

If anyone has workarounds I am interested!

Cordiacordial answered 25/10, 2022 at 14:11 Comment(0)
T
0

Cordiacordial Further down there's this:
https://github.com/godotengine/godot-proposals/issues/2821#issuecomment-992667189

For now that might be your only option, though the discussion there indicated that there's at least some plan to have a solution for this in core for 4.1

Thinnish answered 25/10, 2022 at 16:59 Comment(0)
C
0

Thinnish Ya I am chatting with dsnopek now about it on his discord. Might wait til 4.1!

Cordiacordial answered 25/10, 2022 at 17:27 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.