I'll get it fixed. Avoid it in the meantime.
Announcement
Collapse
No announcement yet.
sv_balance creates misnumbered teams
Collapse
X

sv_balance creates misnumbered teams
Steam Community? Add me.  Free Remote, Encrypted Backup
Darkilla: In short, NS is pretty much really fast chess. With guns. Apophis: I haven't seen anyone say that SM's are better than nonSMs. Nordbomber: This is THE first server I've seen where either side can comeback from out of seemingly nowhere with the right teamwork. en4rcment: I have NEVER experienced the type of gameplay that I have found here. Nightly I am amazed at the personalities and gaming talent. Zephyr: Apophis is clearly a highly sophisticated selfaware AI construct that runs on a highly modified toaster oven in Wyzcrak's basement. 
Re: sv_balance creates misnumbered teams
This is fixed.
Teams form much more slowly in build 240 than in build 239 when this command is used.Steam Community? Add me.  Free Remote, Encrypted Backup
Darkilla: In short, NS is pretty much really fast chess. With guns. Apophis: I haven't seen anyone say that SM's are better than nonSMs. Nordbomber: This is THE first server I've seen where either side can comeback from out of seemingly nowhere with the right teamwork. en4rcment: I have NEVER experienced the type of gameplay that I have found here. Nightly I am amazed at the personalities and gaming talent. Zephyr: Apophis is clearly a highly sophisticated selfaware AI construct that runs on a highly modified toaster oven in Wyzcrak's basement.
Comment

Re: sv_balance creates misnumbered teams
We were discussing earlier tonight how sv_balance tends to make the same team out of the same set of players. Sometimes this is a good thing, like for rematches after a close or short game. Other times, after 5 rounds the same teams get a little stale. Micro and I both suggested creation of a sv_balance2 that would use similar logic, but with a different starting point so as to mix things up. I don't know enough about the way the current balance works to be able to give a solution though.
Comment

Re: sv_balance creates misnumbered teams
I agree; being placed onto aliens like 8 games in a row gets fairly stale after a bit, though I don't typically want to manually team switch so I just play it out, win or lose.
Even if it were to create the same teams, it'd be less of an issue if they at least swapped sides.
Comment

Re: sv_balance creates misnumbered teams
There are lots of ways to balance teams. Here is some brainstorming:
1
Do an internal random on all the players (as in code, not actually executing on the server).
Calculate the odds for each team.
Swap the best player on the stronger team with the worst player on the weaker team.
OR (more complicated but better results)
Swap a random player from the stronger team with a winrate higher than the weaker team with
a random player from the weaker team with a winrate lower than than the stronger team.
Repeat until the weaker team is now the stronger team.
Then assign players to each team.
2
Classify players into 10% win rate buckets.
For each win bucket, random 2 people or skip to the next bucket.
Rebucket on larger skill deltas (20% > 30%) until everyone is assigned.
3
Port https://github.com/dougz/trueskill or install NS2Stats
Pick a random starting team (alien/marine)
Assign players in this order: 1,2,2,1,2,1,2,1,2...Last edited by micr0c0sm; 03082013, 09:56 AM.
Comment

Re: sv_balance creates misnumbered teams
Originally posted by micr0c0sm View PostClassify players into 10% win rate buckets.
For each win bucket, random 2 people or skip to the next bucket.
Rebucket on larger skill deltas (20% > 30%) until everyone is assigned.
I just took a quick look at the balance plugin and I see how it could be generating similar teams; there doesn't appear to be any randomizing being done in the code.
What adds randomization currently is:
 which players are on the server
 which players are left in the readyroom once the balance command has started
 how the data has changed from the previous round
Each of those factors can be fairly constant round to round, leading to similar teams when 'balanced'.
I vote for buckets. Maybe take the top 24 players and place each in their own bucket to make sure they get separated.Steam Community:  
Comment

Re: sv_balance creates misnumbered teams
My understanding:
sv_balance is supposed to be a replacement for sv_random that solves the issue of sv_random stacking a team, leading to unfair games.
sv_balance is currently a command for creating the most balanced teams possible, but has an issue of creating similar teams when there are the same players on.
My suggestion:
sv_balance should be built on sv_random, and only add a logic to solve the stacking problem.
Randomization:
Solving the stacking problem requires randomization, as kormendi mentioned.
I support the simpler method of randomization (suggestion 1 in my previous post), which favors randomization over strict teambalance. The teams are not mathematically guaranteed to be as close as possible, but are guaranteed to be no further apart than (best_player  worst_player) / team_size. In fact I think the bounds are even smaller because the restriction of (weaker team is now the stronger team), which would make it something close to (best player on team 1  best player on team 2) / team_size, but I have to do a simulation and some algebra to confirm that.
I do not support the bucket method of randomization (suggestion 2 in my previous post), because the math involved may be very complicated. My mind would change if someone could come up with a simpler algorithm to bucket players than suggestion 1, which in essence is a liverecalculated 2 bucket per team algorithm. The best bucketing ends up trending towards continuous, as seen in Microsoft's TrueSkill algorithm. Which may be fun to implement but still is more complicated than either suggestions on the table.
The buckets are very handwavy, which may end up being easier to code and good enough for an 8v8 game though, so I wouldn't strike that off the table as ultimately this comes down to what the devs build, which is always better than pure discussion. (As an aside, I especially like how open Wyz, kormendi & the rest of the team favors writing something and testing on the servers over endlessly redesigning before the first line of code is written)
Big post, lots of rambling. Good distraction from work. Maybe I'll spin up some code to simulate multiple methods.
You think you could post some sample data of player names (or 'fake names') and winrates?
Comment

Re: sv_balance creates misnumbered teams
http://github.com/jedahan/sv_balance will be up after work today, since I don't want it to look too bad that I was slacking :p
Comment

Re: sv_balance creates misnumbered teams
Came up with a much simpler solution, so braindead it could be called a zombie strategy.
(readyroom all and sv_random) until the teams are balanced (expected winrates of each team are within 10%)
This preserves the variety and spirit of sv_random, while eliminating ridiculously stacked games.
If you want to let people who already joined a team stay on that team (SM benefit?) then just keep track of those players when readyrooming.
Comment

Re: sv_balance creates misnumbered teams
OK, here are some results from running the code:
Code:~/c/j/sv_balance git:master ❯❯❯ npm start ✱ ◼ > [email protected] start /Users/jedahan/Dropbox/code/jedahan/sv_balance > coffee sv_balance.coffee trying strategy sv_random After 10 simulations the expected win rate difference is 6.5 ± 0.1% the randomness is 58.8 ± 4.1% trying strategy swap_until_balance_shifts After 10 simulations the expected win rate difference is 6.7 ± 0.2% the randomness is 52.5 ± 0.6% trying strategy swap_until_within_bounds After 10 simulations the expected win rate difference is 1.4 ± 0% the randomness is 50 ± 1.6% trying strategy sv_random_until_within_bounds After 10 simulations the expected win rate difference is 9.4 ± 0.3% the randomness is 62.5 ± 2.2% ~/c/j/sv_balance git:master ❯❯❯ npm start ✱ ◼ > [email protected] start /Users/jedahan/Dropbox/code/jedahan/sv_balance > coffee sv_balance.coffee trying strategy sv_random After 100000 simulations the expected win rate difference is 9.2 ± 0.4% the randomness is 50 ± 1.7% trying strategy swap_until_balance_shifts After 100000 simulations the expected win rate difference is 6.7 ± 0.3% the randomness is 50 ± 1.8% trying strategy swap_until_within_bounds After 100000 simulations the expected win rate difference is 2.5 ± 0% the randomness is 50 ± 1.8% trying strategy sv_random_until_within_bounds After 100000 simulations the expected win rate difference is 9.2 ± 0.4% the randomness is 50 ± 1.7%
A large number of simulations is useful to checking the standard deviation for each strategy, especially in regards to win rate difference. Here it is clear that 'swap_until_within_bounds' produces the most fair games.
A small number of simulations is important for checking randomness, which we want AS close to 50% as possible.
Here it is clear that 'swap_until_within_bounds' produces the most random teams from one game to the next.
I wasn't expecting that, but here it is. I'd like if someone could fix the sv_random_until_within_bounds, since that may be simpler to write since right now it is the same as 'sv_random'.
It would be cool if someone could port our current strategy to this simulator as well.
Comment

Re: sv_balance creates misnumbered teams
Originally posted by bentring View PostSo would that actually send people into teams then back to ready room until the code is happy or would it just simulate the randoms?
I could see getting put onto a team over and over to get annoying.
Comment

Re: sv_balance creates misnumbered teams
It looks like the braindead strategy is actually as good as the swapping player strategy. And its a bit simpler to implement. So, thats my recommendation for sv_balance  sv_random (behind the scenes) until the expected winrates are within 5% of one another. Should keep varied teams, while avoiding sv_random stacks.
Implemented sv_random_until_balanced strategy, here are the new results:
Code:~/c/j/sv_balance git:master ❯❯❯ ./node_modules/.bin/coffee sv_balance.coffee simulations=100000 after 100000 simulations of strategy sv_random the expected win rate difference is 9.2 ± 0.4% the randomness is 50 ± 1.7% of strategy swap_until_balance_shifts the expected win rate difference is 6.7 ± 0.3% the randomness is 50 ± 1.8% of strategy swap_until_within_bounds the expected win rate difference is 2.5 ± 0% the randomness is 50 ± 1.8% of strategy sv_random_until_within_bounds the expected win rate difference is 2.5 ± 0% the randomness is 50 ± 1.8%
Code:~/c/j/sv_balance git:master ❯❯❯ ./node_modules/.bin/coffee sv_balance.coffee simulations=10 after 10 simulations of strategy sv_random the expected win rate difference is 9.9 ± 0.5% the randomness is 45 ± 1.6% of strategy swap_until_balance_shifts the expected win rate difference is 6 ± 0.2% the randomness is 62.5 ± 4.1% of strategy swap_until_within_bounds the expected win rate difference is 2.3 ± 0% the randomness is 52.5 ± 0.9% of strategy sv_random_until_within_bounds the expected win rate difference is 2.3 ± 0% the randomness is 56.3 ± 2%
Comment

Re: sv_balance creates misnumbered teams
Thanks for this.
Now that you've got pseudo code you like, will you be porting to Lua?Steam Community? Add me.  Free Remote, Encrypted Backup
Darkilla: In short, NS is pretty much really fast chess. With guns. Apophis: I haven't seen anyone say that SM's are better than nonSMs. Nordbomber: This is THE first server I've seen where either side can comeback from out of seemingly nowhere with the right teamwork. en4rcment: I have NEVER experienced the type of gameplay that I have found here. Nightly I am amazed at the personalities and gaming talent. Zephyr: Apophis is clearly a highly sophisticated selfaware AI construct that runs on a highly modified toaster oven in Wyzcrak's basement.
Comment
Advertisement
Collapse



Comment