devtrackers.gg
Hello again! We are the VALORANT Gameplay Technology team and we are here to give you part two of our investigation findings and actions for gameplay consistency.
If you need a refresher on a general overview of what we’ve heard, see our previous post last month. There we covered the general themes of what we’ve heard from players, an overview of what spaces we were digging into (latency, correctness, and high ping player performance).
With the previous post covering most of the “what” and “why,” we wanted to give details today on one of the main areas we improved: Latency and Buffering. We'll share the importance of latency and buffering as it relates to VALORANT, some insight into our investigation, the fixes and improvements we’ve made, and longer term actions we are taking.
Here’s a quick TL;DR of what we are delivering in the Patch 4.10 release:
- We’ve found and fixed a few issues that can occur after bursts of network instability, low client framerate, alt-tabbing, or extended periods of high network jitter.
- These could cause impacted players to feel some combination of delayed processing of their inputs on the server or delayed movement from enemies on their screen.
- We’re shipping changes in Patch 4.10 that should improve how network buffering behaves in these situations, and making available data to players that shows what’s going on under the hood.
- These changes address the primary cause that we found for feelings of inconsistent network latency and reaction times between games, but we'll continue to monitor and make improvements moving forward.
- If you are still experiencing issues in your games, we hope that the new graphs help to quantify and measure what you’re experiencing.
- Please continue to send us reports along with videos, if possible, through our Player Support channel with what you’re seeing.
LATENCY AND BUFFERING
In our previous post, we mentioned that we’re still investigating Latency and how network buffering was performing in VALORANT. We’ve since wrapped up that investigation and are shipping fixes for a few issues that we found in Patch 4.10.
Before we dive deeper, it might help to have a bit of background information on what we mean when referring to “network buffering” or “processing delays.”
In online games like VALORANT, you send your inputs up to the Server to have them executed since the Server’s view of the game is the correct one. Every time the Server updates the game simulation (which happens 128 times a second), inputs from your game Client need to be played for your Agent. If your inputs get delayed while traveling over the internet, the Server will not wait for them to arrive and has to simulate a move for you.
This Server-predicted move often disagrees with the one that is still on its way. These disagreements cause Move Corrections which show up on the client as small teleports to the correct location. Too many of these corrections makes the game feel “jumpy,” and at a high enough percentage, unplayable.
The way to avoid these Server predicted moves is to have the Server buffer up some moves and play them out at a slight delay. This is a very common strategy when trying to stream any data over the internet and helps to ensure the Server can smoothly play moves for your Agent each frame. However, this buffering adds a delay before the server processes your moves, and too much buffering can make it feel like you are playing at a much higher ping than what your Network Round Trip Time (Network RTT) would show.
Providing the correct amount of buffering is an important balancing act. Too little buffering and you get lots of Server-predicted moves and client corrections, too much buffering and you get high latency and are more susceptible to things like peeker’s advantage. If we get the balance just right, VALORANT feels both smooth and responsive.
Similar to how the server buffers your moves before applying them, your client must buffer information about enemy movement before it’s displayed on your screen. This prevents enemy players from appearing to teleport around when you have a bad connection, giving you a smooth, easy to track view of other players.
The Investigation
As part of our investigation, we needed better insight into exactly how these two buffers were performing. We created some new debug tooling to track how much time it took for moves to go through each of the buffers. Using this tooling, we began experimenting to see if there were scenarios which could cause the movement buffers to behave in unintended ways.
One of the player-reported issues we chased down during this investigation was increased shot processing delay when alt-tabbing. Backgrounding the game with the Limit FPS in Background setting emulates an extended client performance issue by throttling framerate. After bringing the game back into focus, the sudden higher FPS could cause the Server’s move queue to become quite large. On the Client, this would feel like playing at a very high Ping that wasn’t reflected in the current Network RTT graphs.
Another way we found to get a similar effect was to simulate a quick Ping spike on the client. A spike of higher ping back to lower would cause a build up in the Server’s move queue for that Client. A spike from lower ping back to higher would cause a build up in the Client’s move queue for other players. In either case, this build up of moves in the queue would cause a higher apparent latency until the queue got back to its target size.
In both of these scenarios, the current system would eventually resolve issues and get the buffers back to their target size, but we found that it could take longer than intended to completely recover, leading to an extended period of effectively increased network latency.
We’ve implemented two new fixes that should alleviate these over buffered states much faster, so that you’re only seeing extra latency for short windows where it’s necessary to smooth the experience.
Fixes and Improvements
The first fix we implemented adjusts how quickly we get the buffers back down to the target size when something causes a backup. We’ve added the capability for the move processing system to more aggressively adjust as the size of the buffer increases.
With this change, backups of buffered moves get dealt with faster than before. For example, prior to this change, if there were an extra 5 moves in the buffer, this could take up to 5 seconds to get back to the ideal target. With these new improvements, that time is now less than 1 second. This means that players that encounter impacting events such as hitches or network spikes will be affected by the latency from that extra buffering for a much shorter time.
However, in severe cases the backup of buffered moves can grow so large that waiting for the move processing to deal with this backlog can still take seconds, even with the above fix. When this happens, we’ll now hard reset the buffer, dropping all moves except for the most recent. This has the advantage of immediately removing added latency, but guarantees that a Move Correction will happen.
We’ve found that in the case of severely impacting events such as extreme framerate disruptions or network spikes, getting a move correction was preferable to waiting even a couple of seconds for the move processing to readjust the buffer size. This tradeoff of receiving a correction in this case was usually less disruptive than the extended period of increased latency that players would have encountered prior to this fix. One such severely impacting event where you might receive this correction, is refocusing the game after alt-tabbing with Limit Background FPS set to a low value. This causes an extreme framerate change which can lead to the problematic over buffered state which should now be quickly resolved by this change.
A related issue we’ve also found while investigating buffering is that players with consistently high network jitter will regularly get shifted between lower and higher buffering targets as the system tries to balance their latency with the number of Server predicted moves. We are working on a solution to better adjust the target buffer size taking this sort of long term network jitter into account.
Looking Forward
Along with the changes above, we realized that players don’t have a good way to visualize the current move processing delays. Since the graphs we made internally were very useful in tracking down this issue, we’ve added a new performance graph called Network RTT + Processing Delays which captures your network round trip time along with both the Server and Client move delays.
This time measured on the graph should be relatively equivalent to the delay you could feel with the old “knife test.” A reasonable value for this graph when things are working well should be roughly 20–30ms higher than your Network RTT—though the ideal value will be different depending on your exact network and frame rate conditions.
Additionally, we’ve also added a Network RTT Jitter graph which shows how Network RTT changes from packet to packet. Ping spikes and high network jitter are often causes that necessitate additional buffering, so we’ve added this as a graph to help potentially diagnose adverse networking conditions that wouldn’t show up in the regular Network RTT graph due to averaging.
We’ve also implemented some additional telemetry so we can collect data on what processing delays players are actually experiencing from game to game. We’ll regularly review this data to help keep an eye on the health of the game to determine whether the above fixes are having the effects that we intended and if additional fixes and improvements are required.
Lastly, although we read posts across various social media platforms, we also want to leverage our post-game surveys to get further in-depth player feedback with respect to the quality of your matches such as the quality of your connection and gunplay. So, we’ll add and revise some questions to reflect these areas.
NEXT UPDATE
We hope these improvements to the movement processing buffers will help to reduce some of the inconsistency that players were feeling when their Ping seemed fine. If you’re still feeling issues in your games, we hope that having the new Jitter and Processing delay information in graph form will help quantify what you’re feeling and help to diagnose potential causes. If you’re experiencing inconsistency issues and are recording your gameplay, having these graphs visible gives extra information that can help narrow down where to take a deeper look.
We’ll end this update with a huge thank you to everyone who posted videos and breakdowns of issues they’ve felt or seen. We appreciate your love for the game and your efforts to help us improve it. As always - we take your feedback very seriously.
Keep an eye out for another future update where we cover server selection and how it relates to high ping player performance.