Originally Posted by tmakinen

Wouldn't that be a Luxon handicap then if the problem is that Luxons win too many matches?

Putting in any kind of permanent disadvantage for one side is not a desirable solution since the relative strength of each side changes over time. From a physical point of view the current map system can be described as a harmonic oscillator where wins and losses are the pushing force that sets it in motion. There are currently two separate problems with the map rotation, and these can be directly addressed by adjusting the two parameters that describe the oscillator:

The first problem is that the oscillator is lopsided, i.e., it stays predominantly on one side of the equilibrium point. This can be corrected simply by redefining the equilibrium. An automatic mechanism that adjusts the equilibrium once per week so that the weekly average stays within the neutral map region will do the trick.

The second problem is that the oscillator is stagnant, i.e., it is stuck in one point instead of moving through the full range. This can be corrected by adjusting the 'spring constant' which defines how hard one must push to get the pendulum moving. Again, the automatic adjustment can be done once per week by observing the amount of variation. If there is insufficient movement away from the neutral map loosen the spring so that the map changes with less applied force. If the map swings wildly from one end to another stiffen the spring so that more force is needed to move the map.

This kind of automatic adjustment would make sure that on average all maps would see an equal amount of play while keeping the intended feature of short term success driving the selection of the map. The original parameters for the oscillator were hand picked by a developer but they are currently not optimal. An automatic adjustment mechanism would fix this permanently. Since this is a crucial part of keeping the content interesting on the long term I think that the devs should consider implementing such systems.

Originally Posted by tmakinen

To elaborate it a bit further, I've written the same thing in pseudocode.

The current system works like the following:

x is the map position. It's a float that gets values between -6.5 and +6.5, the values corresponding to maps as
-6.5 to -3.5 Ancestral Lands
-3.5 to -0.5 Grenz Frontier
-0.5 to 0.5 Saltspray Beach
0.5 to 3.5 Etnaran Keys
3.5 to 6.5 Kaanai Canyon
v is the current map changing speed in position per polling interval (3 hours)
F is the difference between the sum of Luxon points L and Kurzick points K acquired during the polling interval
w is the spring constant that couples F to v

Every three hours the following is evaluated:

F = L - K
v = v + w * F
x = x + v

The value of x is checked to make sure that it doesn't go beyond limits and that the map doesn't skip over one option (like going directly from Grenz to Etnaran).

The changes that I propose are:

Once per week the system is balanced through evaluating:

y = mean(x) # over the last week
b = sum('Ancestral Lands' or 'Kaanai Canyon') / sum(any map) # over the last week
if (b < 0.1) then w = w * 1.2
if (b > 0.4) then w = w / 1.2

and the regular map change equations become:

F = L - K
v = v + w * F
x = x - y + v

Quite easy to implement I'd say

Originally Posted by tmakinen

To elaborate it a bit further, I've written the same thing in pseudocode.

The current system works like the following:

x is the map position. It's a float that gets values between -6.5 and +6.5, the values corresponding to maps as
-6.5 to -3.5 Ancestral Lands
-3.5 to -0.5 Grenz Frontier
-0.5 to 0.5 Saltspray Beach
0.5 to 3.5 Etnaran Keys
3.5 to 6.5 Kaanai Canyon
v is the current map changing speed in position per polling interval (3 hours)
F is the difference between the sum of Luxon points L and Kurzick points K acquired during the polling interval
w is the spring constant that couples F to v

Every three hours the following is evaluated:

F = L - K
v = v + w * F
x = x + v

The value of x is checked to make sure that it doesn't go beyond limits and that the map doesn't skip over one option (like going directly from Grenz to Etnaran).

The changes that I propose are:

Once per week the system is balanced through evaluating:

y = mean(x) # over the last week
b = sum('Ancestral Lands' or 'Kaanai Canyon') / sum(any map) # over the last week
if (b < 0.1) then w = w * 1.2
if (b > 0.4) then w = w / 1.2

and the regular map change equations become:

F = L - K
v = v + w * F
x = x - y + v

Quite easy to implement I'd say

Originally Posted by tmakinen

To elaborate it a bit further, I've written the same thing in pseudocode.

Originally Posted by Lexar

Kurzicks already have a tiny advantage over Luxons: in the event of a draw, both reach 500 or more at the same time (even if the Kurzicks go from 499 to 501 and the Luxons go from 499 to 503), the win goes to Kurzicks by default.

Originally Posted by distilledwill

There is no fundamental difference between the players who choose to play for Kurzick and the players who choose to play for Luxon.

Originally Posted by glacialphoenix

As someone who plays Kurzick - I highly doubt giving Kurz a handicap advantage would change things. Look you - if Kurz start winning due to a handicap, how many of the bad players would start thinking it's because they're leet, and wouldn't you have the same situation all over again?