Most of the important stuff is certainly done server-side, like determining whether a Pokemon appears at coordinates x,y or not (though my guess is the client is tasked with this, and then says "Hey server, I'm showing there should be a Pidgey at x,y, I'm gonna try to catch it." The server confirms by running the exact same deterministic check on x,y, then says "Yep, I see it too," or "No, you're a filthy liar, Joey.")
But for the actual "I caught it" or "I missed it," unless the exact user input is sent to the server, and then the server simulates the projected path of the throw, the client seems like it gets to say that. So perhaps the client could actually say "I hit it perfectly," and the server just says "Well if you say so."
I've seen the app load something (and hang up while doing that) between pokeball throws. That seems like evidence that it's asking the server about something after each throw / once every n throws.
Checking if a throw resulted in a capture server-side would be weird, I don't see why it couldn't be done on the client. It could be querying for the players inventory, to see if they have enough pokeballs? It'd still be better to just sync that once before the fight...
My best guess is, the conditions for a Pokemon running away involve something only the server knows. A weak example: maybe it considers other players in the area - pokemon might be more likely to run away if the area is too crowded? So every once in a while the client asks the server how many players are there nearby, or something.
I've noticed higher CP pokemon tend to run away more quickly. You also have to remember that there's now great balls and razz berries to influence throw chances, so the client probably publishes the events it's doing (gave a razz berry, threw a pokeball, threw a greatball) and the server creates some randomness that says yes/no.
That "randomness generating" still seems like it would be easily done locally, and it'd reduce server load. But maybe there's some more advanced mechanisms we don't know of.
if it's done locally then people will bodge the client so the random is no longer random. The server's always going to have to do the math, even if to just ensure the client's not lying.
>Checking if a throw resulted in a capture server-side would be weird, I don't see why it couldn't be done on the client. //
It locks up [server access icon spins] a lot on the point at which the ball closes and the game is deciding whether to capture or release the pokemon (what's the heuristic there?), often crashes at that point to.
I wouldn't be surprised if this is because it's sending the whole of the swipe data to the server. Surely it doesn't need to check if there are pokeballs available, when your client says "gotcha" then the server will have record of if there were balls available or not.
To answer your first question, yes you can configure everything; type of ball used, whether the throw is curved or not and the "excellence" of the throw. No one gets excellents throws all the time so I think it's easily detectable and hence bannable.
Most of the important stuff is certainly done server-side, like determining whether a Pokemon appears at coordinates x,y or not (though my guess is the client is tasked with this, and then says "Hey server, I'm showing there should be a Pidgey at x,y, I'm gonna try to catch it." The server confirms by running the exact same deterministic check on x,y, then says "Yep, I see it too," or "No, you're a filthy liar, Joey.")
But for the actual "I caught it" or "I missed it," unless the exact user input is sent to the server, and then the server simulates the projected path of the throw, the client seems like it gets to say that. So perhaps the client could actually say "I hit it perfectly," and the server just says "Well if you say so."