Smogon and the competitive Pokemon community as a whole has always had one common enemy: hax. We have gone so far as to implement clauses and bans to mitigate the effects of luck on the outcomes of games. However, our best efforts thus far have failed to make hax an issue of the past. Because of this, I've been trying to tackle this discrepancy recently, proposing to a few people on irc an objective, mathematical formula that could be used to significantly increase the probability that the battle outcome is deemed "more fair." Essentially, this formula would be applied at the end of a normal battle and its outcome would be used to determine the winner. Yes, fainting your opponents six Pokemon ends the battle, but this would not necessarily guarantee the win when using this formula. The formula would play a role in determining the winner and finalise the outcome as a "win" or "loss". There is one problem: I haven't finalised this formula yet, as I'm not entirely sure that it works as we wish. However, I have already shown the prototype model of this mathematical system to Caelum and DougJustDoug, and they told me that this endeavour is by no means fruitless. Because I'm not completely satisfied with the formula, however, I cannot say that this formula is ready to be used; this is actually one of the reasons why I'm posting it here: to get opinions from you Policy Reviewers. The other, more important, reason why I decided to post this all the same is that I'll be having a break from Smogon due to my upcoming marriage next month, and I thought that it wouldn't make sense to let this wait until after my marriage. So here is what I thought about, so far. As people are probably aware, Prof. Glickman, the inventor of the Glicko and Glicko-2 systems, wrote a formula that gives us the probability that a person with rating R1 and deviation RD1 beats a person with rating R2 and deviation RD2. For posterity, it is repeated here: Code: Prob_Win = 1 / (1 + 10^(-g * (R1 - R2) / 400)) where g = 1 / sqrt(1 + 3 * (ln(10))^2 * (RD1^2 + RD2^2) / (400*pi)^2) and pi is the usual pi (approx. 3.14159) Now if Prob_Win is large, 0.8 for instance, and the player won, then the win is more probable that it was on merit and not on hax. Conversely, if it is small, say 0.2, and the player won, then the win is more probable that it is due to hax. Thus, Prob_Win is a measure of 'hax' in the sense that it is inversely proportional to 'hax' - the higher it is, the less 'hax' there was likely to be in the battle. Formally: Code: Hax = k / Prob_Win where k is a constant that needs to be determined. The problem is how to find this constant k. I have tried to write a formula for k in terms of three other variables. The first one is L, which is defined to be the total health lost during the battle as a fraction of the team health. Of course, this would be 1 (or 100%) for the opponent that lost the battle; thus L would only make sense for the player that won. The lower L is, the lower the amount of hax in the game - hence L is directly proportional to Hax. The second variable is 'a', the total number of Pokemon that are still alive at the end of the battle. As before, this would only make sense for the player that won, since 'a' for the losing player would always be zero. For this variable, the higher 'a' is, the lower the amount of hax in the game - hence 'a' is inversely proportional to hax. We normalise the value of 'a' here by dividing it by 6, so that if all the winning team's Pokemon are still alive by the end, then 'a' would be equal to 1. The third variable is p, the number of Pokemon that were used in the battle. Yet again, this variable would not be very interesting for the losing player as it would always be 6 for him or her. If the winning player didn't use all his six Pokemon in the battle, the battle is assumed to have had less hax. Thus, the smaller p is, the less hax there was, and hence p is directly proportional to hax. Again, we divide p by 6 to normalise the value of p so that it is a number between 0 and 1. As a prototype to my system, I suggested k to be equal to the following: Code: k = L * p / a and hence we have Code: Hax = (L * p) / (Prob_Win * a) If Hax is higher than some threshold value, then the game is deemed to have had too much hax, and hence the opposing player would get the win instead. I tried this threshold value to be equal to 2, and it seemed to work okay. However, I'm not at all sure if this formula is correct, or even if the variables I'm using are even relevant to hax. And this is where YOU guys come in. I need your help to specifically improve the above formula. In particular: Are my assumptions about p, L and a correct? Is my threshold value of 2 fine, or should it be lowered or increased even higher? Should there be other factors in the formula that influence the amount of hax present in the battle? Please do fill me in with your help. The people that play relatively frequently have the power to help me more than the others, since they obviously would experience hax more. Please don't just assume that I'm right just because I said it here - as a person who hasn't played much competitive Pokemon for a long time, I'm sure that I can be enlightened further about this matter. A final disclaimer. Because of my imminent marriage, I will probably not be able to monitor this thread as much as I would like. For that reason, I will be keeping contact with Caelum via e-mail over the coming weeks to bring me up to speed on what's going on in this thread, and he might even post in my place about updates and developments to the formula.