Hello,
I think everyone here agrees that it's not normal to lose pp on a map with a new play. Nevertheless, it happens a lot, and can sometimes result in the loss of 10% (Maybe more ? I just know I once went from 130 to 117pp with a new play).
Of course, one cannot hope for the server to compute the pp of every plays before it chooses to update it to top pp or not. This would be to heavy for the server, that couldn't handle it (or if it is not too heavy, why on earth is it not already done that way? So I'm assuming it's too heavy).
I see 2 solutions to this problem, one partial (and very easy), and another (my fav) a little bit more implicated, but fairer in a sense.
Solution 1:
Simple: before the server adds a new pp play, it checks whether it's better or not than the current pp on the map. The only problem here, is that a replay is sent over to the server only if the score on the play is better than your previous record. And in that case, some good pp play could be omitted. This problem is resolved in solution 2 below.
Solution 2:
The idea is to implement a pp computation on the client side. Compute the pp value of one replay would be easy for the client, and it could do it after every play. Then, the client confronts with the server (the current top pp could even be cached locally to often save a communication), and if it's more pp than the current top on the map, then the replay is sent over to the server, which would then recompute the pp value of the play, to ensure that the play was not misvalued (via a hack on the client side for example). Finally, if and only if the new value is better than before, it's updated.
Again here, the server will not be more sollicitated than it now is.
The only "problem" here is that if the pp forumla is suppose the remain secret, then it could (and would) be reverse engineered with the client application. But I'm fairly sure that it's already been done more or less precisely, and it's not really a big issue (unless the current formula is flawed, in which case it should be fixed) is it?
Security-wise, it's the exact same, since the server recomputes when a replay is recieved.
~~~~~~~~~~~~~~~~~~
If you like the idea, please comment below which solution you prefer. If you don't like the idea, please enlighten me
I think everyone here agrees that it's not normal to lose pp on a map with a new play. Nevertheless, it happens a lot, and can sometimes result in the loss of 10% (Maybe more ? I just know I once went from 130 to 117pp with a new play).
Of course, one cannot hope for the server to compute the pp of every plays before it chooses to update it to top pp or not. This would be to heavy for the server, that couldn't handle it (or if it is not too heavy, why on earth is it not already done that way? So I'm assuming it's too heavy).
I see 2 solutions to this problem, one partial (and very easy), and another (my fav) a little bit more implicated, but fairer in a sense.
Solution 1:
Simple: before the server adds a new pp play, it checks whether it's better or not than the current pp on the map. The only problem here, is that a replay is sent over to the server only if the score on the play is better than your previous record. And in that case, some good pp play could be omitted. This problem is resolved in solution 2 below.
Solution 2:
The idea is to implement a pp computation on the client side. Compute the pp value of one replay would be easy for the client, and it could do it after every play. Then, the client confronts with the server (the current top pp could even be cached locally to often save a communication), and if it's more pp than the current top on the map, then the replay is sent over to the server, which would then recompute the pp value of the play, to ensure that the play was not misvalued (via a hack on the client side for example). Finally, if and only if the new value is better than before, it's updated.
Again here, the server will not be more sollicitated than it now is.
The only "problem" here is that if the pp forumla is suppose the remain secret, then it could (and would) be reverse engineered with the client application. But I'm fairly sure that it's already been done more or less precisely, and it's not really a big issue (unless the current formula is flawed, in which case it should be fixed) is it?
Security-wise, it's the exact same, since the server recomputes when a replay is recieved.
~~~~~~~~~~~~~~~~~~
If you like the idea, please comment below which solution you prefer. If you don't like the idea, please enlighten me