2006.10.16. I have implemented an adaptive handicap system based on the system described below. It involved minor changes to the QuakeC source code (the most significant change was calculating the standard deviation), but I also added a floating point exponentiation command to the virtual machine to avoid reimplementing it in QuakeC.
Feedback is mixed. Some people like it a lot, while one person (who has not bothered to try it) is adamantly opposed to it, calling it “Commy Quake.”
The only issue uncovered so far is when players join a game already in progress. Simply calculating handicaps based on frags causes such a player to be mistaken for a bad player. Perhaps frags-per-minute or frags-per-death should be considered instead.
Matthew R. Dempsky
9 October 2006
Our LUG often plays multi-player first-person shooter games (e.g., BZFlag, Quake, Unreal Tournament 2004). These games are played primarily for community building—not competitive play—, so it is important that all players have an enjoyable time.
Of course, with such a small community of players, we necessarily have a large range in expertise—“newbies” and pros alike. We would like players to join and have fun regardless of skill level, but to ensure everyone has fun, any handicap system we impose must fulfill two goals: better players ultimately win, and all players can occasionally score points.
I believe the system described below meets these two goals.
Quake currently keeps track of the number of frags each player has accumulated. The idea is to modify the game to additionally keep track of each player's frags z-score. (Recall from statistics that a z-score is the difference between a particular value and the mean, divided by the standard deviation. E.g., if you have 23 frags, the mean number of frags is 19.4, and the standard deviation is 2.1, your frags z-score is (23 - 19.4) / 2.1 = 1.714...)
Each player's z-score is recalculated each time the score board changes. Previous score board states do not affect the current handicaps.
Whenever a player would inflict damage to another player, the difference in their frags z-score is combined with some scaling factor x, and the inflicted damage is scaled appropriately. E.g., if the scaling factor is x = 1.2, your frags z-score is 1.7, your target's frags z-score is 0.8, and your attack would normally inflict 40 points of damage, you would actually inflict 40 * 1.2^(0.8 - 1.7) = 33.947... points of damage.
Finding the optimal value for the scaling factor will take some experimentation.
In a nutshell, the goal is that if Alice is a better gamer than Bob, Alice should end up winning, but Bob should still occasionally score frags against Alice. Both of these goals are important: if Alice will not end up winning, she has no incentive to improve her skills beyond Bob's; if Bob can never score frags on Alice, he will not have fun playing against her.
We assume because Alice is a better player than Bob, that when there is no handicap, then Alice is able to reliably frag Bob. We can then “prove” by contradiction that Alice will always win under the adaptive handicap rules. Suppose by way of contradiction that Bob ends up winning against Alice. By definition, Bob's score ended up higher than Alice's. Therefore, at some point Bob's score was equal to Alice's, and he scored a frag. When two players' scores are equal, they will have the same frag z-scores, and their handicaps will cancel out. But this leads to a contradiction because Alice is a better player, so if there's no handicap, Alice should have scored a frag against Bob instead of vice versa. (Note this argument does not depend on the scaling factor.)
As for ensuring Bob still enjoys scoring a few frags against Alice... well, we cannot guarantee that. Bob might just join the game and never shoot. However, even if Bob is really, really bad, eventually his handicap will grow high enough that he is effectively invincible and has one-hit kills. Random point-and-click gaming should then score Bob at least a few frags.
We might worry Bob's handicap would grow to the point that he begins “owning” the game. If that were to happen, his handicap will start to fall again and eventually level out where he is able to score occasional frags against others (but fewer than they score against him, by the above proof that Alice will always win).
Handicap systems are only meant to level the playing field—they are not suitable for preventing malice. There are numerous ways to manipulate this system. For example, a player might repeatedly commit suicide to lower their frag tally and artificially boost their handicap. In a variant on this scheme, two players collude; one player accumulates a large number of frags on opponents after his partner has softened them up (aided by an artificially-inflated handicap).
It is my opinion that such problems are primarily social issues, and should be solved by warning (and removing, if necessary) disruptive players. However, see below for ideas on possible technical solutions.
The system described is elegant in its simplicity. There is only a single “knob” to be tuned, and it has fairly simple proofs that it meets the set goals.
I can imagine numerous variations on this system: replace exponentiation with another function for calculating the damage scale; only apply handicaps when frags z-scores differ significantly; disregard suicides in calculating z-scores; calculate z-scores from some other measure of player skill (e.g., accuracy or inflicted damage); simply use frags instead of z-scores. The possibilities are endless.
I find sufficient evidence that the above described handicap system is worth experimenting with. I plan to modify the QuakeWorld Quake-C source code in the near future to provide this functionality on my server.