The Grand Unified Catch Theory: Berry and Throw Bonus Multipliers

After releasing The Grand Unified Catch Theory: Curveballs, the two questions we’ve received the most are:

• What about Razz Berries?
• How do target ring size and Nice, Great, Excellent throws affect catch rate?

Today we'll cover these questions in the second part of our series on the Grand Unified Catch Theory (GUCT). As a quick recap, the base catch rate and level of a wild Pokemon determine its probability of being caught with a Poke Ball:

However, you can also use certain items and skilled throws to boost your chances of catching it. This boost can be predicted with GUCT formula as follows:

where,

Think of multipliers as giving you extra chances to throw additional fractions of a Poke Ball per catch attempt. If you throw a curved Ultra Ball, you are essentially throwing 1.7*2 = 3.4 Poke Balls. To see how the Ball and Curve bonuses work, check out the first GUCT article.

The first bonus that we will cover today is the Berry bonus.

Building on the curveball analysis, we tried to find a best fit function to data points which used a Razz Berry. We filtered out any data points which had a Nice, Great or Excellent throw bonus but left all others, since the Curve and Ball bonuses were already understood. No medal bonuses were in the data. This left us with 7,230 data points.

To test how Razz Berries build on the existing Curve and Ball bonuses, we chose the independent variable x to be

If the exponent also contains the Berry multiplier, we'd expect the catch probability for any of our data points to be

The question is: What is the best-fit value of Berry to reduce the absolute distance of our calculated probability from the observed probability? SciPy, a library for Python with a best-fit function, gives

$$Berry = 1.539 \pm 0.027$$

where 0.027 is the standard deviation. Continuing with the trend of nice looking numbers, the only reasonable guess for the Berry multiplier is 1.5. Again, our Poke Ball capture rate data was rounded to two decimal places, so on top of the standard deviation, this is easily within error - and there are no other round numbers which are also within error.

Let's see how this hypothesis fits the curve: if it is correct, the black line (GUCT with Berry = 1.5) should match with the red dots (actual catch percent for that bin) within error about 68% of the time, since the bars show one standard deviation = sqrt(nCatchSuccesses):

Based on our analysis, we found that the multiplier for Throw bonuses are as follows:

Throw Bonuses are not fixed, instead depends continuously on radius! The formula we found for catch bonus is:

...where r is the radius of the inner circle, which goes up to 1. That means that when the circle is as big as possible, Throw = 1, and when the circle is as small as possible, Throw = 2.

Since ring size and throw bonus are correlated, we could not be completely sure that the multiplier varies continuously with radius, rather than being a flat bonus for Nice / Great / Excellent. However, the communication between client and server during a catch suggests that the bonus is continuous. This will be explained in-depth later.

The graph below shows how much catch rate improves with throw bonus on average:

The analysis proceeds as it did for curveballs and Razz Berries, fitting a function to data points which received a bonus. We only filtered out throws which did not have the bonus being analyzed, because all other bonuses were already understood and no medals were in the data. Most throws in our dataset had no bonus, making our analysis for this multiplier less certain than the previous ones. We also had no data points with Nice throws. Since we did not want to build all of our analysis off the least certain multiplier, this was the last analysis we did with this dataset.

We will begin by discussing Excellent bonuses first and then move on the analysis of Great bonuses.

Our sample of Excellent bonuses had 1442 points. To test how Excellent bonuses build on the existing Curve and Ball bonuses, we designated the independent variable x to be

If the exponent also contains the Throw multiplier, we'd expect the catch probability for any of our data points to be

We look again for the best-fit value of Throw to reduce the absolute distance of our calculated probability from the observed percentage caught. Fitting for the value of Throw with Excellent throws yields:

$$Throw = 1.902 \pm 0.073$$

where 0.073 is the standard deviation. While all of our previous analysis assumed that the multiplier had only one decimal place, we made no such assumptions for this analysis. This is because that the multiplier could be based off of the size of the inner circle.

For reasons we will explain later, we hypothesized that the value of the multiplier for excellent throws is 1.85. If this multiplier is correct, the black line (GUCT equation with Throw = 1.85) should match with the red dots (actual catch percent for that bin) within error about 68% of the time, since the bars show one standard deviation = sqrt(nCatchSuccesses):

The fit is good, but there is some room for error because the sample size was 1442, small compared to our previous sample sizes.

Before explaining why we chose 1.85, we need to give the analysis for the Great bonus. The sample had only 130 data points, and produced a value of:

$$Throw = 1.518 \pm 0.192$$

where 0.192 is the standard deviation. This parameter also need not be a round number if the Throw bonus depends continuously on the inner circle radius.

For the Great throw curve, we hypothesized that the value of the multiplier is 1.5: if it is correct, the black line (GUCT equation with Throw = 1.5) should match with the red dots (actual catch percent for that bin) within error about 68% of the time, since the bars show one standard deviation = sqrt(nCatchSuccesses):

We don't like this graph very much. It could be wrong, and even if it's right, the parameter could be off by ~0.192. But fortunately, we have other evidence for the multiplier which comes from looking at the communication between client and server.

Here is a sample MITM catch log. What can be seen in the client-server communication is that a variable named normalized_reticle_size (NRS) is sent to the server when a ball is thrown. Experimental evidence shows that

where r is the radius of the inner circle as a fraction of the outer circle. In other words, for a full-sized circle, NRS is equal to 1, and for a circle of minimal radius, NRS approaches 2. We also have some lines from the game's code that shows:

        "excellentThrowThreshold": 1.7,
        "greatThrowThreshold": 1.3,
        "niceThrowThreshold": 1,

While the numbers in our fit aren’t exactly the average of the numbers within the range, they are sufficiently close to those values. Our data did not rule out the possibility for there to be flat multipliers for different bonuses, but the fact that the client sends the server a parameter which fits very well for both Great and Excellent bonuses suggests that this parameter is the multiplier.

To add to the evidence, there would be no reason for a value of 2-r to even be calculated if all that mattered was if a throw was Nice, Great or Excellent. Niantic could easily make the thresholds the exact ratio of the inner circle radius to the outer circle radius and spare all our phones some battery life. The fact that they don't do this suggests that the value is "normalized" so that it can be used as a throw multiplier.

Thus, we hypothesize that the Throw multiplier is equal to 2-r and varies continuously as the inner circle size decreases.