But with the values ​​I put in, isn't it possible to know that? Not to mention that at least where I live the ISP doesn't answer these questions easily.
The only result that matters is the last hop. If earlier routers were having an impact then you would see lost packets at the end. You don't so those routers are having no impact.
Unlikely, infrastructure nodes along a network path really tend to focus on their bread and butter job, forwarding and routing packets (which is often handled by dedicated fast ASICs), anything else like generating ICMP response packets is often handled by rather weak CPUs that also have other important jobs to perform. The upshot of this is that such nodes often employ deprioritisation and rate limiting for ICMP responses so if you see increased delay and packet loss along a path isolated on a single hop, this is likely not a sign of overload of the network path... Here a link to an excellent, albeit technical, documentation about how to interpret MTR/traceroute results.
But since the main point relevant for your example is sort of treated as a side show in that document and @krazeh already mentioned it: true overloaded nodes will cause unexpected increases in latency and packetloss that persists for all nodes further away, where the traffic has to to traverse the overloaded node.
With unexpected increase i mean that e.g. a traceroute from europe to the US will show a big increase in latency the corresponds to the trans-atlantic submarine cable, where all hops in the US will show the same base latency (as will the european ones). That is an expected latency increase and is not indicative of an actionable problem...
In this example hop 12 seems to be in London UK, while hop 13 seems to be in Ashburn VA/US, so the increase in from 16.3 to 92.4 (and later hops) is entirely reasonable and expected... (hop 14 seems to be in Los Angeles CA, so the jump from 92.4 to 151.9, is also expected, after all the traffic needs to cross the entire continental US).
It depends... some ISPs have better transit/peering to the datacenters/AS that host the game servers than other ISPs. So selecting a decent ISP with good connectivity can help, as can trying different VPN services (that are well connected to one's ISP and the game servers) to "route around one's ISP's sub-optimal routing" (this poor man's traffic engineering is quite approximate and what works well today might suck raw eggs tomorrow).
What values ​​​​are you talking about? I didn't quite understand your answer. If it's from Javg the last host is the game server so you can expect it to have little jitter.