Yesterday, the entire Pokemon GO community was in an uproar after witnessing the removal of Pokemon tracking mechanism from the app. The long awaited app update took out more than it introduced and it felt like a slap for most players. Niantic has not disclosed any details on the removal or about the possible time frame when the footstep tracking will be available again.
As it is unlikely that the previous changes to Pokemon GO step tracking (the fabled “3 step” glitch) are unrelated, we are inclined to believe that the removal of footstep tracking mechanism is a performance optimization and not Niantic intentionally ruining the game.
Let’s consider the action set a player can do inside Pokemon GO and the possible requirements for loading new data from the server:
- Capturing Pokemon should only load/send data when loading the encounter screen, after using items and after the encounter has been finished – N times inside a discrete time frame
- Gym battles are real time and should only load data in between battle rounds. As gym battles are based around twitch mechanics, it’s unlikely that any data transfer is performed during it.
- Loading nearby Pokemon should happen every N seconds or every N meters, possibly triggered by both scenarios. In order to provide players with accurate step count, the server needs to calculate the relative distance, which depending on the implementation can be a costly computation. Even worse, as players move more often than they battle or capture, this mechanism is bound to become the bottleneck during heavy loads.
Here’s a simple table illustrating the relative scale of server load these actions generate:
|Action Scenarios triggered per player per minute
|Number of server requests per scenario
|Resulting relative server load (requests per player per timeframe)
|1-2 (this goes up with Lure/Incense)
|3-N (depending on items used)
|6 – 10
|1 – 2 rounds
|1 (load the opponent Pokemon)
|1 – 2
|Loading nearby Pokemon
|4-10 (depending on distance moved, speed and map geography)
|5-N (depending on number of nearby Pokemon distance traveled)
|40 – 200
Even from this simple table, just one player produces a lot of server load when the app loads nearby Pokemon. Multiplies the numbers above with the number of players and you’ve got yourself a problem.
The same logic can be applied to early day login issues. A huge chunk of the player base was performing the same action as the same time and we ended up deadlocking each other as Niantic’s server-side authentication couldn’t cope with the load.
The big picture
Most modern multiplayer games use simple mechanisms to calculate if other players/objects should be visible – almost all of them do it on the server-side to prevent cheating, wallhacking and different ways of abuse. In term, this generates a lot of server load. Usually, server side endpoints carry the entire information set that the client uses to render the map and in game objects.
Judging by the sheer fact that PokeVision was able to exist, it’s obvious now that Niantic is doing the same thing.
The only difference is their server-side endpoints provide more data than it’s displayed in the current iteration of the app, thus enabling PokeVision to display exact Pokemon locations and timings. Also, they were not adequately protected from abuse, judging by the number of third party tracking apps and websites that appeared in the past weeks.
We believe the following to be true:
- Niantic’s server-side infrastructure could not cope with the load as illustrated in the table above
- Niantic did not like the abuse or the fact third party developers knew the endpoints were so easily abused
- Removing/turning off footstep tracking is a monkey patch solution that will be fixed in the future
We are quite sure that the underlying issue behind the removal of step tracking was not the abuse, but the server load it generated. After all, the Poke radar broke down days before PokeVision become a thing.
The first step was to hard code the server side to always return that a Pokemon is 3 steps away, thus preventing the costly calculation. The second step, which happened now, was to remove the steps from the app until the feature gets fixed.
We already reported in our “Pokemon GO Server Issues Explained” article that a lot of server-side architecture can be easily scaled if it was planned for scale. If not, it’s necessary to re-engineer the architecture and the approach to scale. We believe that this is what’s currently happening at Niantic’s HQ.
We also believe that at some point Niantic will refactor the existing API, limit the number of possible server requests per client and protect the API in various ways to prevent websites like PokeVision from becoming popular.