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:

$$Probability= 1- \left(1-\frac{BCR}{2*CPM} \right)^{Multipliers}$$where,

$$Multipliers=Ball*Curve*Berry*Throw*Medal $$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.

Our analysis of the data revealed that the *Berry* multiplier is equal to **1.5**.

With a Poke Ball and no other bonuses, using a Razz Berry is equivalent to using 1.5 Poke Balls each turn (and identical to switching to a Great Ball). Things really start to stack up, though, when you start piling the bonuses on top of each other:

Balls | Poke | Great | Ultra |
---|---|---|---|

Straight, No Berry | 1 | 1.5 | 2 |

Straight, Berry | 1.5 | 2.25 | 3 |

Curve, No Berry | 1.7 | 2.55 | 3.4 |

Curve, Berry | 2.55 | 3.825 | 5.1 |

The graph below shows how much your catch rate improves by using a Razz Berry before every throw:

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

$$x = (1-\frac{BaseCapRate}{2*CPMultiplier})^{Ball*Curve}$$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 whole numbers, the only reasonable guess for actual value of 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 theory 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):

The graph is very nice, but there is one problem: It seems that the bot which produced this data only used berries for hard-to-catch Pokemon. Although this is a weakness, the fit is very good for points within the domain, and it's unlikely they would have changed which function they use for berries depending on the domain.

There is another factor which greatly strengthens our *Berry = 1.5* hypothesis: Prior to the 0.35 API being shut down, we had seen some logs of data sent by Niantic’s servers to individual phones. After using a Razz Berry, the server sends this response to the client:

returns: "success: true item_capture_mult: 1.5 "

Before our research, nobody knew exactly how "item_capture_mult" was used. It seems very clear now that this 1.5 is multiplied with other multipliers in the exponent of the GUCT, since the best-fit gave the exact same multiplier, within a small error.

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

Throw | Nice! | Great! | Excellent! |
---|---|---|---|

XP | 10 | 50 | 100 |

Target Ring Size | 1~0.7 | 0.7~0.3 | 0.3~0 |

Minimum Bonus | 1 | 1.3 | 1.7 |

Maximum Bonus | 1.3 | 1.7 | 2 |

Average Bonus | 1.15 | 1.5 | 1.85 |

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 chose the independent variable x to be

$$x = (1-\frac{BaseCapRate}{2*CPMultiplier})^{Ball*Curve*Razz}$$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 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

$$NRS = 2 - r$$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,This means that a NRS from 1.0 to 1.3 gives a Nice throw, 1.3 to 1.7 gives a Great throw and 1.7 to 2.0 gives an Excellent throw. Summarizing the NRS range, the average of this range and our estimated values gives this table:

NRS Range | Avg | Fit | |
---|---|---|---|

Nice | 1.0 to 1.3 | 1.15 | |

Great | 1.3 to 1.7 | 1.5 | 1.518+/-0.192 |

Excellent | 1.7 to 2.0 | 1.85 | 1.902+/-0.073 |

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.

From our research, the answer to this question is **no**. You only get a throw multiplier if you successfully land a Nice, Great or Excellent throw.

We expect our conclusion for the Throw bonus to be somewhat controversial because of previous contradicting research. However, upon closer examination of /u/RhyniD's raw data, we found that the GUCT are compatible with the data RhyniD collected, despite reaching opposing conclusions.

The reason being, in reaching his conclusion, RhyniD did not account for the curve ball bonus, which as we showed previously, is quite significant.

In a follow up analysis of RhyniD's data, /u/Binzouin is surprisingly prescient with his analysis, creating this graph:

The Improvement Factor *f* of this graph is equivalent to the Multipliers in the GUCT formula. It is possible that if Binzouin kept at it a bit longer, he could have eventually derived the GUCT on his own!

From the graph, we can see that between 0.7 to 1.0 ring size (color / white) the trend line flatlined at about 1.7 Improvement Factor. Since the RhyniD’s dataset consisted of mostly ordinary, curved throws, this value can be explained by the curve bonus. The absence of a rise in catch rate associated with radius in this region of the graph supports the idea that ordinary throws do not grant any type of catch bonus.

We also isolated the dataset for ordinary throws only. We found GUCT is a predictor of the actual outcome, with Throw bonus defaulting to 1, even though a large number of the ordinary throws recorded have ring size below 0.7.

In other words, the cause of the statistical discrepancy between game's stated catch rate and the empirical data RhyniD found, which he attributed to reticle size, was instead caused by the curve bonus. When taking the curve bonus into account, we found GUCT to be a good match with the data RhyniD collected.

As a final confirmation of the GUCT multipliers, we ran binomial tests of the unbinned data. All of the pre-0.41 update factors were included: ball, curve, berry and throw bonus. We first calculated the GUCT catch rate for all throw attempts using the established multipliers.

Then, we ran two-tailed binomial tests to see if the probabilities from the sample are statistically different from the calculated catch rates. We repeated these tests after restricting our data to only cases where Razz Berries were used and then only cases where Razz Berries were not used. The results of these tests are summarized in the table below. Given that less than 5% of tests rejected the hypothesis that calculated catch rate is accurate, we have no statistical reason to reject our calculated values for the multipliers.

Condition | Rejected Tests | Fail to Reject | Total |
---|---|---|---|

All Multipliers | 17 | 1588 | 1605 |

No Berry | 10 | 1080 | 1090 |

Berry | 5 | 616 | 621 |