The original version of this very good ranking system has been used to rate french PBM chess players for years. So why reinvent the wheel ? Here I have adapted it a little.
Every new player gets a Rank of 500 and an Index of 500.
Stakes are points added to the winner's Rank and subtracted to the loser's Rank. Unless the following article apply, the stake is the same for both players.
If the weaker player wins, the stake is 10. If the stronger player wins, the stake depends of the gap between their respective Ranks :
| Gap | 0 | 1-10 | 11-20 | 21-30 | 31-40 | 41-60 | 61-80 | 81-100 | 101-140 | 141-200 | 201+ |
| Stake | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
Stakes don't need to be adjusted in the following cases :
Otherwise the stake is multiplied by a different factor for each player. Let's call A the hundredth part of his Index and B the hundredth part of his opponent's. Then the factor is (1 + 19A - B - 3AB) / 16. So, to get the adjusted stake won or lost by a player, you multiply the unadjusted stake by the factor and you round down.
If P1 whose Rank is 520 and Index is 453 wins against P2 whose Rank is 648 and Index is 131, the (unadjusted) stake is 10 so :
To quote Andy Graves in
Stellar Crisis
v3.2 - Motivation, Among the most significant new features is the
introduction of the
Bridier Ranking
System for 2-player (Grudge) games, enablement of which is a server-level
option, and if it is enabled, it becomes a series configuration option.
With these systems, it can happen that you don't get any points even if you win, providing your opponent's Rank is much lower than yours. This can be depressing. It has been suggested in the Yahoo! SC Club to restrict game access in a way that your rank would at least increase by one no matter who you nuke, and I think it's a good idea. The best way IMHO to avoid great differences in rank in a given game is to restrict entry to players within a given Rank interval and/or Index interval (both more meaningful than wins). These parameters would be series configurable.
It should not be possible to get more points by first getting a nuke in game A, then in game B, instead of doing it in reverse. You avoid this problem entirely if the scores used for the calculation are taken from the beginning of the game (i.e. it doesn't matter whether you have nuked people elsewhere meanwhile). But what if you nuke several people in the same game ? This is something that can't happen in chess, for which the Bridier system was initially designed. I would suggest you use the initial scores anyway, so that nuking X then Y is not any different from nuking Y then X. Otherwise you might soon find games lasting longer than necessary...
This said, goth raised a valid concern on SC Yahoo! lately (2000-10-07): what if someone started 20 games with his initial Rank of 500 and won most of them ? That's why he proposes that my Bridier change is based on my rating at the end of the game, but on my opponent's rating at the start of the game. I don't think this is much of a problem though, because I've experienced that if you try playing too many games at once, your playing level decreases...
If you nuke (or are nuked by) someone while allied, the Rank used to compute the stakes is the average of people in your alliance. So that if you were allied with an SC God you'll get less points [or lose more] than if you were allied with Mr. Stupid. This said, it only makes sense when alliances are fair, at least at the beginning (not 3 on 2 in a 5 player games for instance).
In my SC proposal, someone falling into ruins is also considered as nuked. So, to score the ruin itself, I suggest the ruiner's Rank loses X (5 for instance) times (the number of previous ruins + 1). So, if it's your first ruin, you don't lose too much (only what you lost for being nuked plus X), but if it's your 7th, your Rank won't like it ! It works a bit like cumulative upkeep in Magic The Gathering: at the beginning, it's ok, but after a while, it becomes prohibitively expensive.
| Tell me (replace localhost by agt-the-walker.net) if you have comments / suggestions / etc. about this page, since feedback is always appreciated ! | |
| Last Update: 2006/01/18 23:31:29 |