I’m seeing some slowness on our server with hundreds of players and one of the things I’m looking at is the server getting backed up when the clients start to race ahead of it in framerate and send more moves than the server can process. We have plans to optimize movement a bunch, but in the mean time, is it worth dropping ClientNetSendMoveDeltaTime to match my server frame rate? We already have it quite low (20 normally, 15 when throttled) but in extreme circumstances where the server drops to 10 or even 7fps, is there any reason to keep the send rate higher? or should I just replicate a value from server to client that tells the client how often it should be sending moves roughly?
Hey Joshua, I discuss some of the move combine time nuance here.
If you lower the send rate here is the main fallout I would expect:
It won’t impact the sending frequency of volatile movement (changing directions, movement modes) since those moves aren’t combined anyway.
It won’t impact the sending frequency of movement from root motion sources / anims since those moves are never combined.
You can have increased client CPU cost, because (combined) moves are always rolled back and resimulated before sending. See the PerformMove() call (resimulation) inside UCharacterMovementComponent::ReplicateMoveToServer(). That PerformMove is also called for un-combined moves that are sent, but for larger delta-times it can trigger multiple iterations.
It can feel more unfair to the player: even when the player’s movement is combinable client-side, it will be evaluated against a later world state server-side. Sending at a higher rate increases the chances of at least one player move being executed server-side in every server-side world tick. For example with a send rate of 7 fps and a server tick-rate of 7 fps, because of jitter it doesn’t mean that every server world tick it receives 1 move. With a send rate of 10 fps even when the server is ticking at 7 fps, those chances are more likely so the player’s movement is evaluated more fairly. I’m talking about fairness in the sense of:
Client-side near miss collisions can be server-side collisions if the move arrives later
Client-side dodges of other player abilities can be server-side hits if the move arrives later
With server-side framedrop, the main difference is not granularity of movement trajectories but whether the player’s move executes 1-2 frames sooner (high send rate) or later (low send rate), affecting collisions
I think it’s safe to lower the send rate down to (but not lower than) the server’s tick rate, as long as you keep an eye on:
Client CPU costs of resimulation before sending
During gameplay, player dodges being rejected by the server due to jitter causing some server world ticks not processing any move for the player.
Slightly higher than server tick rate is better, IMO.
None of the Fortnite game’s have a throttled send rate of lower than 20 moves/second.
I want to add that: you may want to verify how often clients actually send.
Because if most of the server’s CPU load is from moves that weren’t considered for combining anyway, then increasing ClientNetSendMoveDeltaTimeto lower the send rate won’t have much of an impact. For example, in the following cases it won’t matter much:
If clients are sending lots of moves due to root motion sources/anims which by default forces a move to be sent every client tick
Or if custom CanCombineWith logic often disallows combining due to the state of move inputs