A large suite of changes were recently activated for all PvP battles, following the rollout of version 0.241. This seems like a good time to review the changes, what they mean for PvP, and the work that has been done to get to this point. We had the privilege of discussing some of these changes with Niantic at the end of the Interlude season, and now are able to test many of them with our own hands.

The game is still not perfect, but the developers have made significant progress fixing some long-standing issues with PvP. Some of these changes have been activated in previous updates, such as 0.233, 0.237, or 0.239, but may have been turned on only temporarily, or only turned on for specific leagues for testing purposes. Now the full set of changes has been activated for all leagues. The work has not finished either. Further work is being done for future updates, to identify and remove bugs still remaining.

Although the Interlude season was often frustrating to players, with unclear signs of whether any progress had been made with the state of the game, there was continual behind-the-scenes work. The first work was done on the combat refactor, discussed below. The second half of the Interlude season was focused on developing changes for various specific issues, discussed subsequently. It should also be noted that apps have lead times for code to actually make it into users hands; it has to be tested, approved, and rolled out through app stores. This means that fixes developed during the Interlude season weren’t always immediately available for distribution.

Combat refactor

A PvP refactor was identified in the code months ago, which led to mistaken hopes this was a new version of PvP without the bugs of previous versions. Instead the refactor had a different purpose: cleaning up the code and adding tools to make it easier to adjust and fix issues for the future. During the first half of the Interlude season, most of the development work was just on building tools to help fix the game. The flagship tool was combat logging. In our most recent call with Niantic, they described this work as cutting the time needed to fix a bug from 2–4 weeks to 2–4 days.

QoL fix: switch buttons appearing earlier, during Charged Attack animations

Players often face a situation where they have to switch as soon as a Charged Attack ends and are hammering the location of the switch button for when it reappears. One source of human error was to accidentally tap too high or too low while the buttons were invisible. Now the buttons appear earlier, reducing the chance of human error here.

Transferring Fast Attack damage after Charged Attacks

This change has been turned on for some formats recently and is now live in all formats. If a Charged Attack is activated more than one turn before the end of an opposing Fast Attack and the Charged Attack user performs a switch, the damage now registers on the Pokémon using the Charged Attack, rather than the switched in Pokémon. An example is Toxicroak (with some prior energy) does 3 Counters against a Hypno, throws a Sludge Bomb, and switches to another Pokémon. Previously, the damage from the second Confusion would be transferred to the new Pokémon. Now the damage registers on the Toxicroak. It is still possible to transfer damage if a Charged Attack is not used. For example, if the Toxicroak did 3 Counters and swapped without throwing a Charged Attack, then the switched-in Pokémon would receive the damage from the second Confusion.

Damage priority between Fast Attacks and Charged Attacks

Previously, GO Stadium has published articles regarding a change to damage priority between Fast and Charged Attacks. The intention of the change is for Charged Attacks activated a turn before a Fast Attack ends to take priority over the Fast Attack damage. Currently, Fast Attack damage registers at the beginning of the final turn of the Fast Attack (i.e. Confusion damage registers 1.5 seconds after the Attack starts). If a Charged Attack is activated at this moment, the Fast Attack damage currently applies first. For example, an Azumarill does one Bubble against a Hypno and throws a Charged Attack. If the Confusion would faint the Azumarill, the Charged Attack currently won’t activate. The change would allow the Azumarill to activate the Charged Attack before fainting. Based on our testing, this change does not appear to be consistently active in the game. It is our understanding this change is still the intention, and we may see further updates to ensure this happens.

Overtapping

Although the previous change doesn’t appear to be active, some related changes around Attack priority appear to be active. Fast Attack energy is now applied at the same time Charged Attack damage is resolved. Previously, if a Fast Attack sneaked around a Charged Attack, the energy would apply after the Charged Attack resolved. This made it possible to do something often referred to as "overtapping". An overtap could happen when the player facing an opposing Charged Attack would tap their own Charged Attack button as they fly out of the opponent's Charged Attack animation. The tap would instead trigger a Fast Attack before their own Charged Attack. This doesn't seem to occur anymore. Hammering the location of a Charged Attack button before it appears should trigger the Charged Attack as soon as the button appears, with no accidental Fast Attacks triggered. This change was activated in GBL before it was activated in Trainer Battles. It now appears to be active in all formats.

Accelerated fly-in or fly-out animations

When a Charged Attack begins, the camera flies in to face the Pokémon performing the Charged Attack. When it ends, it flies out. The game is now able to speed up the fly-in or fly-out to catch up with the server if it determines the client is lagging. This is intended to reduce how out of sync a player’s game can get. Additional synchronization points have also been added to the game.

Fast Attack clipping (AKA fast move denial)

Saving perhaps the most important fix for last, this fix is new to 0.241, and was first activated on 27/28th June. From testing, this fix appears to be successful. Fast Attack behavior is now much more consistent around Charged Attacks. Previously, if both players concluded a Fast Attack on the same turn and one activated a Charged Attack (an especially common occurrence in mirror matches), the other player would have a chance of sneaking a Fast Attack through or having it denied. This chance was unpredictable, and appeared to vary depending on location, internet quality, and esoteric timing techniques around when to tap Charged and Fast Attacks. Charged Attacks are for most purposes considered to use one turn of in-game time, so the expected behavior was that the opposing player should always sneak a Fast Attack, which was how the game used to work a few years ago. It appears the game has finally returned to this consistency.

Some implications:

  • It's now almost always optimal to try to throw a Charged Attack one turn before a Fast Attack concludes. Here's an example involving Walrein Vs Azumarill. Walrein typically runs the 2-turn Fast Attack Powder Snow, and Azumarill typically runs the 3-turn Fast Attack Bubble. Walrein would give Azumarill the fewest unnecessary Bubble turns if it throws a Charged Attack one turn before a Bubble concludes, such as by doing 1, 4, 7, or 10 Powder Snows before throwing a Charged Attack. Previously the Walrein could risk trying to get an extra turn worth of Powder Snow by throwing when the Bubble finished and hoping for a fast move denial, such as by throwing after 6 Powder Snows. This would now more consistently lead to the Azumarill sneaking a whole Bubble—an undesirable situation for the Walrein player.
  • A Pokémon one Fast Attack from fainting with two Charged Attacks worth of energy can no longer throw one Charged Attack, hope for a fast move denial, and throw a second Charged Attack without being fainted in between.

 

We don't expect this to be the end for bug fixes for PvP. Development work is still ongoing, and the successful changes in 0.241 are reassuring about the prospects of future fixes. We as players can help the developers to properly identify the causes of bugs, by submitting combat logs. Submitting a support ticket alongside the log can also be helpful, to raise the visibility of the issue and help the engineering team find what to look for in the log.