Anchor Ratio — VALORANT

Samarth Goyal
5 min readOct 31, 2022

--

The previous post talked about how the anchor time can be calculated to observe and analyze how well a particular person was able to anchor a site.

Despite being one of the best parameters for comparative analysis, it had some drawbacks, two major of them being:
1. The anchor time is calculated for the teams on Defense, but the same time is dependent on the pace of the attacking team whether they play a high-octane game by being super aggressive and approaching the sites in seconds (like Paper-Rex) or are they the types to be playing the slow mind games while burning down the time to the last 30 seconds (like Gambit [in 2021]).
2. Another factor is that the ‘time of rotation’ does not tells if the rotation was incorrect (over-rotation) or was a perfectly timed one, as the anchor needs to time his rotations at the exact time so as to not allow any openings for the flanker to take advantage of.

Both these problems persisted with the previous model of Anchor Timed and had the scope to be fixed with the implementation of another parameter and converting the time into a ratio giving a relative idea of the perfection of a specific person as a “site anchor”.

Since there were a lot of parameters available to choose from, making the right choice felt a little difficult, but with different considerations, I came to the conclusion to consider the ‘Time for Spike Plant’ as the comparison factor since the pace of a team can be somewhat comprehended from the amount of time a team takes to plant the ‘Spike’ on the site, it would be the best fit, adding to the fact that the anchor should be able to guard the site against any possible flankers with a well-timed rotation.

“The Formula” or the “Algorithm” remains pretty easy to understand, we calculated the Anchor Time (which can also be called the Rotation Time) in the last Article, we need 3 additional parameters this time,
1. Was the spike planted?
2. Spike plant time.
3. Overall round time.

Now for every round, we check if the spike was planted and just divide the rotation time by the spike plant time and append it into the final array.
If the spike was not planted, we calculate the ratio using the round length time (deathmatch feels). Again, there are chances that the final array might contain some ratios greater than 1.0, which is practically not possible and may disturb the integrity of the ratio as a comparative parameter. Hence if the ratio gets ‘greater than 1’, we just make it 1.0

The results were not totally different, but it did make more sense now and made it easy to understand where the person might have got wrong as well, since:
1. Checking for low anchor time (last model) does not always make sense, as there can be other reasons contributing to the ‘low’ value.
2. Checking for low anchor ratios (current model) gives the exact rounds where the person might have messed up in aim-fight or might have over-rotated, giving a much much (yes, I did mean to write it twice) better idea.

This time I chose a match between Gods Reigns (a new Indian team, my new personal favorite) and the giants Global Esports (my all-time favorites). All the data was scraped from RIB using the same tool as mentioned in the last article.

You can find all the graphs on my Twitter or Github, here I will discuss the 2 cases which are affected the most by moving from the conventional Anchor Time method to the new Anchor Ratio method.

First, let's discuss the same for Ember, the solo controller present on the map. It was absolutely magical how perfectly timed some of his rotations were and how he used to clear any flank possibility before making the rotations over to the other site, also how beautifully he anchored the site when the executes came to his site was a site to enjoy as well.

The Anchor Time Graph:

Site Anchor Time Graph for Ember

As expected, he had the second-highest average anchor time in the team as a controller.

The Anchor Ratio Graph:

Site Anchor Ratio Graph for Ember

Yet again, he had the second-highest average anchor ratio in the team, which is pretty impressive considering they had sage present in the team as well, a so-called ‘sentinel’.

If you compare rounds 13,14,15 the anchor time decreased with consecutive rounds, but the anchor ratio remained constant, because he was not only able to keep his sight clear but also made the rotations at the exact time when the spike was planted on the other site, keeping his rotation strictly on time, clearing flanks, while also supporting his team with the utility since he was playing Astra. The same can be observed with the change in the slope of the line connecting rounds 18 and 19, which corrects the misunderstanding which occurs by observing just the Anchor Time.

Second, let's look at an even better case of Hoax, mas was stuck to the site like a magnet to whichever he was planted on, and his anchor capabilities with sage as the agent in pretty praiseworthy in itself.

The Anchor Time Graph:

Site Anchor Time Graph for Hoax

An average anchor time of 58.3s is a feat in itself, but if you look at those hills and valleys it feels very inconsistent, which is where the Anchor Ratio comes into the picture, making things easier to compare and observe.

The Anchor Ratio Graph:

Site Anchor Ratio Graph for Ember

Observe the change in the graph at rounds 14 and 15, and see how those valleys have become consistent, hoax had the best anchor time in the team, keeping not only flanks clear but also keeping attackers away from the site or delaying the spike plant, he was the master at it with sage as his weapon.

The ‘anchor time/ratio’ does not make much sense for the initiators and the duelists as they have to be among the initial people to make those early rotations when the requirement may be.

To conclude, compensating for all the drawbacks that came along with Anchor Time, the Anchor Ratio can be the best parameter to compare how efficient ‘controller’ and ‘sentinel’ players have been in their Defense, providing better insights.

You can connect to me on my Twitter.
Or, If you are interested in the ugly code, here’s my GitHub.

--

--