[2020] Peekers Advantage? Strafe Shooting?

Hi all!

There are several topics to unpack - let's do them piece-by-piece: NETWORK BUFFERING / PEEKER'S ADVANTAGE / STRAFE SHOOTING

----- NETWORK BUFFERING -----

This is a new player setting we introduced in the latest patch.

By default, for every player in VALORANT, there is a 7.8125ms "buffer" time on rendering other players on-screen. We do this to smooth out player popping. I've attached an image that demonstrates intent.

https://imgur.com/gallery/xG5PiPq

You could update this buffer to some huge amount (say 1 whole second) and have ultra-smooth player movement, no matter your packet loss rate.

BUT there would be massive peeker's advantage, everyone else would get a whole 1-second jumpstart on you, and you'd lost almost every gunfight.

We have to find a compromise where we avoid jitter/popping in players on-screen, but also keep peeker's advantage as small as it can be.

----

In general, if you have stable internet, do not move off the "Minimum" setting. However, if you are frequently getting the "Network" indicator in the top-right of your screen or see lots of player popping, you may way to try playtesting on one of the other two settings to see if your gameplay improves.

This setting is intended to alleviate gameplay degradation when playing with poor networking conditions, particularly with low bandwidth-based network throttling threshold, and packet loss/ping spiky networks.

It does so by doing two things: Rate limiting outgoing packets and increasing the remote interpolation delay for remote clients. This has the effects of reducing bandwidth usage and smoothing out remote client movements to alleviate symptoms from the previously described scenarios.

"Minimum" is 1 frame of delay (7.8125ms), and full 128 send rate from your computer, to the game server.

"Moderate" is 3 frames of delay (23.4375ms), and chunked updates to the game server (your move data goes to the server every 64-ticks, not 128-ticks).

"Maximum" is 5 frames of delay (39.0625ms), and chunked updates to the game server (your move data goes to the server every 32-ticks, not 128-ticks).

----- PEEKER'S ADVANTAGE -----

Seperately, let's talk about peeker's advantage.

I saw this great post the other day, but didn't have time to comment: https://www.reddit.com/r/VALORANT/comments/g99ipd/valorants_massive_peekers_advantage_problem/fot297a?utm_source=share&utm_medium=web2x

How do you measure it? It's + + +

Some of these values are constant:

NETWORK INTERP DELAY = 7.8125ms (but tuneable with the "Network Buffering setting")

SERVER FRAMERATE = 7.8125ms (1/128)

Others are not:

NETWORK ROUNDTRIP is based on server locations, and Riot Direct routing paths. We are targeting <35ms for 70% of the player population. Closed Beta is a time for testing and improvement, and we are on our way to hitting this target.

YOUR CLIENT FRAMERATE is based on how fast your computer runs; we are trying to optimize framerate as much as we are able, on our side as a dev team.

Peeker's Advantage can never be eliminated, it is something that exists for all games. That being said, our goal is to minimize it as much as possible in VALORANT. Philosophically, we believe the less peeker's advantage there is, the more tactical the game's meta is.

----- STRAFE SHOOTING -----

We devs are aware of this issue, and are thinking about some ways to improve it.

First, some context: Remote Interpolation Delay (see my comments in the first block above) causes a 7.8125ms desync between movement data, and damage data. Otherwise said, when you get killed, the player's move position is always shown 7.8125ms behind from where they actually fired.

This can make it appear that the player was still moving when they shot you, when they might have actually have been standing still.

What are we as devs doing about it?

A) We are working on animation blending updates. When players come to a stop, we'd like to speed up the transition of their anim from "running" to "standing." The animation is sometimes lagging versus what "actually" happened.

B) The frame you die, your corpse (typically) blocks full visibility of the enemy, so you can't see what the opponent did immediately after you died. We are going to fix corpse-blocking in the next patch or two, so you can have constant vision of the enemy. This will help to see if they actually did come to a standstill in moving.

C) We might consider a player setting for "no" remote interp delay; it will get rid of that 7.8125ms desync, but at the expense of you seeing a lot of visual "player pops" when you have packet loss. Packet loss on average varies, but it is not uncommon to have 1-3%. With those numbers, you might see pops up to once-a-second. Not ideal - we're going to test with options tech A & B (and maybe some other small design tweaks) to see if we can get to a good place, before we consider this third extreme option.

I've updated my post with some most context and info, thanks u/grumpypumpkin305

You are definitely going to get a gameplay disadvantage if you use the other two settings. Your opponents will have additional peeker's advantage against you. For moderate, they have 15.625‬ms of extra "free time where they can shoot you", for maximum setting, a 31.25‬ms advantage.

That being said, if you internet is having issues, and players are jumping around all over the place, or your bandwidth is capped/you inputs aren't honored - then you should take the small X millisecond disadvantage in favor of being able to actually play the game smoothly :)

correct, u/ryeguy - delay on sending to the server, as well as a delay in drawing enemies on your screen too.

These settings are for individuals with poor networking setup - not every player has an awesome computer or awesome internet service.

We as Riot want to help these players out by providing optional settings. They have 0-negative impact on the other players in the game, which aligns with our top-line goal of VALORANT - keeping the playing field fair

clickheads showed a good clip, yeah -- see my comments in "STRAFE SHOOTING"

Not seeing the 2nd stutter step is closely tied to the 7.8125ms movement/shooting desync I mention.

We could "fix" this by delaying Shaz's death by 7.8125ms, so the death & enemy movement perfectly sync. We as devs were hesitant to do that though, because that extra 7.8125 ms of time we'd let Shaz still control his player would be a lie .. any bullet he fires/action he takes would never be processed server side, because he is already in fact "dead."

We'd much rather fix this with option B, or potentially C (in my post above).

-----

Either way - we know what's currently in the game isn't quite right. We won't stop making improvements until you'll are happy - expect changes for the better soon.

You should try the settings and see if the game feels better. If it does feel better, keep the setting, if it does not, then revert back to the minimum.

Packet Loss being worse in VAL versus other games is (for some subsets of the population) due to misconfigured settings between Riot Direct and ISPs. We are actively working on fixing these issues during Closed Beta - expect the issue to go away over time.

Hi u/uiki, I've added some context in my post above, hope it helps.

VALORANT is in Closed Beta, and we're just getting started -- we listen to everybody's feedback, and want to make decisions that are most helpful to players.

We are slowly getting around to adding more network commands to players; stay tuned :)

Posted some context above!

We pop this network error indicator for a couple of different reasons:

1) Packet loss (burst - 111XXXXXXX1111, or sporadic - 11111X1111X11111111X)

2) When there is some movement desync between yourself & the game server); usually caused by network variance, or more rarely clock drift.

(by the way - Ping on the scoreboard is a rolling average; if it says "25ms", really you are often drifting between 20-30ms)

3) High ping (which in your specific case u/juhmikay, doesn't sound like you have).

-----

On Round Transitions (from end of round, to the new buy phase) we were triggering this indicator incorrectly - all the "reset" of game state causes some network saturation, which is unavoidable. We are going to hide indicators during this specific bit, because no action can be taken. (can't remember if fix for this was the patch that just went out, or one following)

-----

Why do you see this popup, even with a lit setup?

With the COVID-19 pandemic, lots more people around the globe are using the internet - and all that stress causes packets to be dropped. Your connection may be awesome with your direct ISP, but your game client still needs to use the shared internet infra to hop from your ISP to the VALORANT game server.

League of Legends has a giant footprint across the globe, and we can provably see packet loss % is up on average. Once the virus settles (or when internet infra gets better; it's always getting better over time), you should get more stable net conditions.

Thanks for the question!

- David

My buddy u/Riot_Classick wrote a good post about this stuff the other day, check it out here: https://www.reddit.com/r/VALORANT/comments/g7ql8r/walkingrunning_accuracy_too_high/

Something we are definitely considering, thanks u/Daiephir :)

We're always considering potential design changes - I'm an engineer though and I don't want to speak out of turn. Stay tuned!

See the post in this thread by our design lead: https://www.reddit.com/r/VALORANT/comments/g7ql8r/walkingrunning_accuracy_too_high/

I'll take a followup and get it somewhere more official (and localized) - thanks!

The formula I shared is the basic case, though weird stuff can skew it.

Input lag, server hitches, refresh rate on monitors, network variance (ping isn't absolute what is in the TAB menu, it can wiggle 10-20ms packet-to-packet, depending on network hops & routing).

And for video clips - recording FPS of video capture, slowmo edits, etc.. makes it hard to control for stable testing.

It's hard for me to definitively say that the fl0m clip review is far from 48ms - I welcome someone like battle(non)sense, etc.. to review our netcode in detail as an independent audit :)