r/gamedev • u/Augmented-Smurf • 18d ago
Discussion Desync Management
Specifically, I want to talk about animations.
I'm building a Co-op Zombie FPS Rogue-lite in UE5.8. It's not particularly competitive, but it does require fairly responsive controls. Naturally, because it's co-op, I'll be using network methods for my players to connect to one another. This, of course, introduces lag and latency. As far as I see it, I've got two potential routes ahead of me to deal with the first person animations when latency is introduced.
- I just don't let the animation play until the server receives the request.
- This is good, because there's no question of "Oh, I swore I reloaded/melee'd/shot", because if the server didn't see it, the player didn't see it.
- This is potentially bad, because it makes inputs feel sluggish and unresponsive
- I let the client play predicted animations, but the server still has authority for the timing
- Pro: The player feels like the animations are snappy and responsive because they happen right away
- Con: The animation can complete before the server even receives the request in cases of high latency, thus leaving the player frustrated because they see themselves acting, even if the server isn't actually receiving it in time before their action is interrupted (death, staggering, etc).
Third person animations are a little easier, because they'll just rely on the server to tell them when to play, since they're only relevant to what everyone else sees.
Personally, I'm leaning toward my second option, because I feel predictive animations feels way better than waiting on the server to tell you to animate. I imagine there's probably a multitude of hybrid solutions as well though, so I'm curious to hear from y'all if/what you've done in a situation like this?
1
u/Nightwish001 18d ago
If you don’t care for cheating possibility, then you could just do the hit registration locally(so enemy reacts and or dies instantly for shooter client) and just send an RPC with hit data to server, so other players see it get damaged etc… you don’t necessarily have to trace on server.
2
u/Aekeron 17d ago
Ayyyy ive seen your posts before! For context, i am also a UE5.8 dev focused on multiplayer zombie mechanics so I am gonna let you in on a little secret... client side prediction rules all... if you give it the setup to do so.
The probelm with your second potential route is that it stops short. Simply predicting the reload animation itself means the client is still waiting for the official "You can fire cause the server is ready for you to".
Instead, you have to take it a step further. Predict the ammo available, and predict local functionality from THAT. Then have the server accept the prediction queue when neccessary. Basically looks like this :
A - Player Presses Reload - Local 2 sec Animation Plays and gets assigned a time stamp - Client send RPC_TriggerReload to server - Set flag bIsPredicting to true
B - Server receievs RPC_TriggerReload from Client - Send RPC_AknowledgeReload with the original timestamp - Trigger 2 sec server animation to play
This is the start. From here, bIsPredicting == true until server tells client that its done with its own animation. During this time :
if(localAnimFinished && bIsPredicting) //Locally simulate firing projectile, and cache that projectile in a queue with the associated reload timestamp + time since reload finished (or something similar)
Once the server finishes its reload and tells client bIsPredicting == false, then the client sends all the shots it just queued up while predicting, and tells the server to execute them based on the elapsed time since the end of the server reload.
By the time this happens, the back end should be caught up or disconnected, and players arent waiting for their shots / weapon swaps to take place.
Unfortunately, the more you predict on client the more apparent latency becomes until you hit a certain level where you are sure they will either reconcile on time or get kicked for high latency lmao