New algorithm for autobalance=auto

[the.ynik]

Currenly, alleg offers only 2 choices of auto-balance: balance by player count (#autobalance 1) and balance by total AS (#autobalance auto). Both are fundamentally broken by preventing newbies from joining the team that's up.
Yesterday I made a suggestion to exempt newbies from #autobalance 1 (see this topic), but that is more a band-aid than a real fix.

The real fix, in my view, is to make autobalance care about the average AS on the teams. But of course, average AS alone isn't sufficent - 3 players with average rank 10 vs. 7 players with average rank 10 isn't even.
Total AS alone isn't sufficient, either - if it's 10 players with 100 AS vs. 9 players with 80 AS, then a (0) should be forced to join the side with 10 players (to reduce their average AS), even though that side is up in AS. By the same reasoning, total player count alone doesn't work, either. A proper auto-balance algorithm needs to consider everything at the same time.

Also, I don't like how AB is forcing me to join a specific team if the game is almost (but not perfectly) even. It should notice if the game is almost even and let me join the side I want.

So I've taken all these ingredients, mixed them together into an algorithm, and implemented it in JavaScript so you can try it out online:
http://wp1104860.wp140.webpack.hosteurope....utoBalance.html
That link also has a detailed description of the algorithm.

Do you think this is better than #autobalance auto, and should be implemented in R6 to replace the existing #autobalance auto implementation?
Do you think it's better than #autobalance 1 and stands a chance to actually get used?

Did you find any scenarios using the web app where it doesn't work as you would expect?

[Imago]

just implement it in http://svn.alleg.net/svn/Allegiance/branch/FAZR6/src upload a patch file to trac and we will test it

[DasSmiter]

I like the way you think

[Xynth]

QUOTE (Imago @ Jul 22 2010, 11:14 AM) just implement it in http://svn.alleg.net/svn/Allegiance/branch/FAZR6/src upload a patch file to trac and we will test it

this

I like your algorithm. If C++ is not your thing I may look at it, but you should learn .

[Freyja]

I like that it can block too many newbies on one team. Many comms let imbalance happen from lack of skill or desire to police.

[the.ynik]

QUOTE (Xynth @ Jul 22 2010, 07:47 PM) I like your algorithm. If C++ is not your thing I may look at it, but you should learn .

I know C++, but I don't have any time for coding this myself right now (at least not in the next 6 weeks). I'm already working on other open source projects, and on top of that I got this bachelor thesis to write...
I just wrote that implementation in JS to get the idea out of my mind into some reusable form.

[notjarvis]

Hmm interesting work


To be honest though I would consider sticking with Allegskill's roots and look at theMS Trueskill method ofworking out Team Skill as...

a) it's proven
b) we should have the data to do it

QUOTE But how does the TrueSkill ranking system incorporate the game outcome of a team match? In this case, the team's skill is assumed to be the sum of the skills of the players. The algorithm determines the sum of the skills of the two teams and uses the above two equations where (μwinner,σ2winner) and (μwinner,σ2loser) are the mean skills and skill variances of the winning and losing team, respectively.[/quote]

[the.ynik]

QUOTE (notjarvis @ Jul 22 2010, 09:57 PM) Hmm interesting work


To be honest though I would consider sticking with Allegskill's roots and look at theMS Trueskill method ofworking out Team Skill as...

a) it's proven
b) we should have the data to do it

That could be an alternative to measure 'imbalance'. But I'm not sure we if have that data on client side. Maybe it even requires an ASGS change (to tell the game server µ and σ, if it currently only transmits the rank), that would make it much more complicated to implement than my suggestion (due to closed nature of ASGS).

I haven't really thought about what the advantage would be if both (µ,σ) are available. But that would just be a replacement for the 'imbalance' measure; if implemented that way you'd still want to use my 'flexibility' and rules for joining a side (compare new imbalance with old or with optimum).

Could someone with more AllegSkill and statistics knowledge tell me how to calculate something like my 'imbalance' measure using the player's µ and σ?

Edit: also, my approach has the advantage that it's testable right now; for example half an hour ago I put in numbers from the running game, and it would've prevented Shiz from stacking (with #autobalance 1, the game got to 170:133 AS shortly after). With team's AllegSkill, it would suddenly depend on numbers that almost no one knows how to calculate. And on the beta server ASGS is not required, so where would we get (µ,σ) for testing?
Oh, and another argument against Team AllegSkill: unlike my suggestion, it wouldn't work for multi-team games.

But if you can find solutions to all those problems, then team AllegSkill would certainly be better (using only ranks isn't making use of all the information we have).

[Xynth]

I think the conservative rank is the best piece of information to use anyway. A big problem with Trueskill for allegiance is that experience is more important than on a game like Halo or Gears of War. Learning the intricacies of the game is a big part of being a good player so the conservative rank is actually a good measure of value to a team which is what we really need for balance.

Also I didn't see any algorithms like what the.ynik is proposing in that link. Maybe I didn't go deep enough but I couldn't find anything more than what is on our wiki.

[Freyja]

QUOTE (Xynth @ Jul 22 2010, 09:00 PM) A big problem with Trueskill for allegiance is that experience is more important than [random fps].

Yes, yes, yes, yes!

And AS specifically restricts that learning by having a very small window tied to experience.

Typically a player that's rank 15 playing 6 months is much, much worse than a rank 10 player that's played 2 years... often because of that experience/knowledge.