What is map bias

[uips]

Does anyone know exactly how map bias works? algorithm behind it?

[Nanaa]

Here's documentation about the whole Skill Rating system.

https://etlegacy.readthedocs.io/en/latest/skillrating.html

It doesn't answer your question but my conclusion is that map bias is simply tells how much win chance differs from 50% based on past matches. So +10% map bias for axis would mean they win 60% of the time and allies 40%.

For example, the bugged baserace_desert where Axis wins every match, has +50% map bias for axis. And 50%+50% = 100% win chance.

Quote

• How is the map bias computed?

It is modeled as an extra parameter evaluating home field advantage using past outcome on that specific map.

 

Edited July 20, 2022 by Nanaa

[uips]

yup, very general answer. I was curious about the fact if it takes into account total amount of maps or past x amount of maps. Because if it is total amount and it has been for example million matches, from that point on nothing will probably change the bias as in reality people can get more skilled, learn more tactics, server side or legacy tweaks can affect the outcome. Probably 10 last matches is not enough accurate data. Infinite amount of data will make the bias unchangeable eventually. I think more accurate presentation would be over x amount of last matches. 100, 200 etc at one point trend diversity will minimize and from that point on it will give same result even after 10 million matches. For map bias to reflect change it should be calculated over past matches, not total matches.

I see almost no change in map bias of some maps.

[Nanaa]

33 minutes ago, uips said:

 I was curious about the fact if it takes into account total amount of maps or past x amount of maps.

It looks like to be always the total amount of matches:

https://github.com/etlegacy/etlegacy/blob/00b35a7e14db6f0b73dd6fbf5fdfe7436a8ed776/src/game/g_skillrating.c

#define SRMAPS_SQLWRAP_SELECT  "SELECT * FROM rating_maps WHERE mapname = '%s';"

 

Edited July 20, 2022 by Nanaa

[uips]

is it very hard to make it use info of last maps only?

for example influence on value of past 100 maps is around 0,5%. That means every match will cause about +- 0,5% change into Map bias.

Change on 2000  is 0,025%. That means to make a 0,1% change in bias one team has to win map 4 times in row. (0,5% change in bias is  20 maps win in row). Eventually it just becomes static number.

Down is little graphic to illustrate the change in bias as the data range goes big the line becomes straight.

Using limited value range rather than total value will bring live updates to bias that would present current state of map in the server more accurately and it keeps changing in real time.

Edited July 20, 2022 by uips

[Nanaa]

35 minutes ago, uips said:

is it very hard to make it use info of last maps only?

Currently the system only tracks the total amount of axis wins and allies win on each map. Like this:

5000, 4000, goldrush

So you'd have to change the code and database schema quite a bit. But shouldn't be hard to do.

Edited July 20, 2022 by Nanaa

[uips]

3 minutes ago, Nanaa said:

Currently the system only tracks the total amount of axis wins and allies win on each map. Like this:

5000, 4000, goldrush

So you'd have to change the code and database schema quite a bit. But shouldn't be hard to do.

that explains why some bias become so "static"

[Nanaa]

Yeah, this is definitely problematic if maps are being balanced with for example spawn time changes but the effect won't be seen in map bias.

One fix would be if server admin reset win_axis and win_allies values to 0 in the rating_maps table after balance changes. And occasionally reset or divide the values for all of the maps. Or simply delete all rows in the table occasionally.

[uips]

Another problem with reset is that in the beginning the fluctuation is very big, it will slowly start working towards static number. for example 11th match will cause around 5% change in bias. I Think most optimal data range is 100-500. As 100 keeps updating fast enough, 500 will cause minimal change of 0,1%. Going over 500 will lose the dynamic  effect.

If u take most popular map, how many times it is played in one day if anyone knows the answer. (15min map, 4 maps in hour. 96 maps per day, 16 rotation cycle that is 6 times a day, so rough estimate maybe 5 times a day?) Cycle of 100 will refresh in about 20 days (month). Cycle of 500 will refresh in 100 days (3+ months). And every time there is a change for example spawn time it will take the cycle to work slowly  towards new number, automated process no need for admin to manually do something.

I think using data of x last matches is the best way to go, depends how hard it is to achieve it

18 hours ago, Nanaa said:

So you'd have to change the code and database schema quite a bit

But yup reset will at least erase all old data so the number can become true value.

 

[Nanaa]

You could create a trigger that checks if map is played over 200 times and if yes, then divide the win counts by 2. That way it stays in 100-200 range. That would be the optimal solution I think.

[uips]

so it only stores data of amount of wins for both teams if im correct?

What about downscale every time limit is reached?

for example if current balance is allies: 250 wins , axis 150 wins. Match limit: 400

Allies win 251 ; 150 ; total value = 401 (over limit)

downscale to 400

Allies: 250,3741, Axis: 149,6259

Idea behind it ratio is the real value that bias shows. Ratio stays the same. This way it is as next match will always be 401th one. So it will endlessly simulate 401th match. Also could start with initial values of 200 for both teams, Whenever u load a new map it is already 200 wins for both teams and it starts working its way towards balance from there. No big fluctuations and always gradual dynamic flow

Edited July 23, 2022 by uips