Sorting Balance

[HaTe]

This is not about the faction balance, but rather the team sorting balance upon a new map beginning.

This is just an edited version of the previous clan/community algorithm suggestion that I had posted, but it is still very relevant for public matches.

I'm not entirely sure how it does it now (completely random?), but I've seen some team balancing nightmares. Since the global ranking system is set up by IP apparently (name changes only changes the name in the leaderboard to the most recently used one), we could just use this to help team sorting balance.

Essentially, when you join the game, a script would take each player's global ranking (see Leaderboard) and rank them in the game based on it. Best ranking (closest to 1) gets ranked as #1 player in-game. 2nd best ranking gets #2, 3rd best gets #3, and so on and so forth. Then just take these in-game rankings and use them to auto-balance the next map.

Team 1 gets all of the odd numbers (1,3,5,7,9,11,13,15,17,19), and team 2 gets all of the even numbers (2,4,6,8,10,12,14,16,18,20). Or you can edit this however you would like to make it so that the in-game rankings add up to equal each other.

[Ryz]

Always wondered how the balancing worked indeed. Sometimes I join games and when we switch I see 90 percent of the names I know on one site (I assume without switching) while the players with names including 'player' and other random names I don't know on the other side. Usually this team awaits a nightmare and they will lose....

[Agent]

The leaderboard uses a player's Steam ID as their unique ID, not their IP address.

It's already totally possible to do this, since the leaderboard server already informs the UDK server of the player's rank and the UDK server stores it (though this feature is currently unused). Players would have to be placed into the spectator team before the game starts, and then the teams would be assigned when the level starts. Since not everybody uses Steam however, non-steam players would have to be split into teams randomly unless we replace Steam IDs with something else in the future (something I actually hope to implement, but not in the immediate future).

It'd be trivial however to add players to a list, quick sort the list based on their global_rank, and assign players to teams in an alternating fashion.

[HaTe]

The leaderboard uses a player's Steam ID as their unique ID, not their IP address.

It's already totally possible to do this, since the leaderboard server already informs the UDK server of the player's rank and the UDK server stores it (though this feature is currently unused). Players would have to be placed into the spectator team before the game starts, and then the teams would be assigned when the level starts. Since not everybody uses Steam however, non-steam players would have to be split into teams randomly unless we replace Steam IDs with something else in the future (something I actually hope to implement, but not in the immediate future).

It'd be trivial however to add players to a list, quick sort the list based on their global_rank, and assign players to teams in an alternating fashion.

Yeah I figured it was one or the other (IP address or steam ID). I just said IP because I figured non-steam players were ranked on the leaderboard as well, but I guess not. Since it is steam ID, shouldn't this be easy to implement then? Non-Steam players can either just be put by random since that would be the easiest to implement, and that seems to only be ~15% or so of players at any given time. The ranks would still have to be assigned to teams in an alternating fashion (or an alternative equivalent) for the balance system to work regardless. Since it's just Steam ID used, it just means that the first step becomes unnecessary, and so the project as a whole should be that much easier, correct?

*Slightly off topic*

What are the odds that we get an XP/ranking system that provides incentives rather than just "Score"? Renegade had their own version of this. Winning team members get + XP, and losing team members get - XP. The longer a player is in the game, the higher the multiple increases (it went per client). I think we can use this to help decrease the constant "surrender votes" that are going on now too. Make it so that a surrendering team gets 150% of the losing XP. Also make it so that base destruction wins give 125% of the winning XP.

Here's how Renegade's was setup (per readme file):

"1. Nobody on the winning team will ever lose points in game (the minimum they can get is 0

points).

2. Nobody on the losing team will ever gain points in a game (the max they can get is 0 points).

3. On the winning team, the players are sorted in order of the number of points they achieved in

the game, then the lowest scoring player is awarded 0 points, the second lowest player 1 point,

then 3, 6, 10, 15 points and so on.

4. On the losing team, the players are sorted in order of the number of points they achieved in the

game, then the best player is awarded 0 points, the next best -1 points, then -3, -6, -10, -15 and

so on.

5. Once these ladder deltas have been calculated, they are scaled by the amount of time you

played in the game, so for a 20 minute game where you played for 10 minutes, you get POINTS x

10/20.

6. The resultant number is then added onto your ladder points to determine your new ladder rank."

It worked decent. Had some flaws that I can certainly point out if anyone wanted to go this route with it.

[Agent]

I may implement some sort of "Ladder Points" independent from the Score statistic, and switch to using ladder points for ranking. I've been considering that already, but haven't actually decided on a specific algorithm to use yet. That said, I do not under any circumstance wish to discourage surrenders. Surrender is a perfectly valid way to end a game and often preferred in not only Renegade X, but strategy games such as C&C and StarCraft. It's generally considered a waste of time and poor sport to force your opponent to destroy the rest of your base, when you've already lost by a wide margin.

As far as an algorithm for points goes, something based on your in-game score, time in-game, win/loss status, and each team's cumulative ladder points should be used.

Maybe some pseudo-code for a possible implementation:

// Assuming not a tie

float cumulative_winner_ladder_points;
float cumulative_loser_ladder_points;

// Implement: assign 'cumulative_winner__ladder_points', 'cumulative_loser_ladder_points', 'player'

float ladder_points_change = 0.0;
float win_loss_multiplier = cumulative_loser_ladder_points / cumulative_winner_ladder_points;

#define WINNER_CONSTANT 1.0
#define LOSER_CONSTANT -0.01

if (is_winner(player))
 win_loss_multiplier *= WINNER_CONSTANT;
else
 win_loss_multipler *= LOSER_CONSTANT;

float game_time_multiplier = player.game_time / server.game_time;

float team_total_score;

// Implement: assign 'team_total_score'

float score_multiplier;
if (is_winner(player))
 float score_multiplier = player.score / team_total_score; // Reward more for contributing
else
 float score_multiplier = team_total_score / player.score * (enemy_team_total_score / team_total_score); // Punish less for contributing

#define BASE_POINTS 10

ladder_points_change = BASE_POINTS * score_multiplier * game_time_multiplier * win_loss_multiplier;

You'll always gain for winning and always lose for losing, but the gains/losses will be less depending on who wins/loses. You'll always gain more / lose fewer points for playing well.

Quitting mid-game will automatically subtract some constant number of points. Joining mid-game will automatically add the same constant number of points. Being in a game when it starts will also add this constant number of points. This means that crashing mid-game will not hurt you, and players will generally net more points than they lose.

Example game:

30 minutes long

GDI (Winner): 6000 points

• * Bob: 3000 - 30 mins: 10 * 0.5 * 1.0 * X = 5X
  * Jimmy: 2000 - 30 mins: 10 * 0.3333 * 1.0 * X = 3.33X
  * John: 900 - 20 mins: 10 * 0.1 * 0.66 * X = 0.66X
  * Newbie: 50 - 2 mins: 10 * 0.01 * 0.06666* X = 0.0066X
  * AFK Pro: 50 - 30 mins: 10 * 0.01 * 1.0 * X = 0.1X
  

Nod (Loser): 4000 points

• * Bober: 2000 - 30 mins: 10 * 3 * 1.0 * -.01X = -0.3X
  * Jimmyer: 1200 - 30 mins: 10 * 5 * 1.0 * -.01X = -0.5X
  * Johner: 600 - 20 mins: 10 * 10 * 0.66 * -.01X = -0.66X
  * Newbier: 100 - 2 mins: 10 * 60 * 0.0666 * -.01X = -0.34X
  * AFK Proer: 100 - 30 mins: 10 * 60 * 1.0 * -.01X = -6.0X
  

Issues:

* The AFK player on the winning team still earns more points than a player with the same points who recently joined.

* Too much emphasis on score -- this should be solved by rebalancing score and:

* Some multiplier constants need to be adjusted

Obviously the above is a super duper rough draft.

[HaTe]

I'm glad you are taking the initiative on this, and you seem to know what you're doing.

I can see that the base is 10, the second multiplier is the overall team score / client score, the third multiplier is the time-in-game / total game time, and the fourth is the win/loss multiplier.

AFK issues shouldn't be as prevalent when (if) the AFK bot detector is implemented.

Something that should be addressed that is not currently in your algorithm is the amount of players in-game. Currently, I believe a 1v1 would yield the highest profit margin because the second multiplier would be 1.0. You should make another multiplier that takes into account total number of players that have played in the game. The more players that have played in the game should slightly increase the overall ladder points given.

I think surrendering is a fine option, but just happens far too frequently and takes the satisfaction out of winning a lot. It's an anti-comeback mechanic, and many teams use it after losing just one building. There's just very little incentive right now to not utilize it whenever even a minor disadvantage comes around, and I think a small ladder hit would help that out. At the very least, how about a small bonus (*1.15) for a winning team by base destruction and a small bonus for a losing team (*.85) for base destruction (since both teams fought it out until the very end)?

[Agent]

Yeah I was just talking to that about someone else as well. I do feel like player counts need to be somehow incorporated, but we should also make a conscious effort to ensure that we don't discourage players from populating additional servers. Perhaps some sort of logarithmic operation could be used: log(server.player_count). Maybe a base of 10 or 20 would be good for that logarithm.

Maybe a small multiplier against the losing team for surrendering could be used to prevent these same ladder points from encouraging surrenders as well. I'll think on that. We do however want to make sure that players aren't encouraged to leave more than they are to surrender, though.

[HaTe]

Yeah I was just talking to that about someone else as well. I do feel like player counts need to be somehow incorporated, but we should also make a conscious effort to ensure that we don't discourage players from populating additional servers. Perhaps some sort of logarithmic operation could be used: log(server.player_count). Maybe a base of 10 or 20 would be good for that logarithm.

Maybe a small multiplier against the losing team for surrendering could be used to prevent these same ladder points from encouraging surrenders as well. I'll think on that. We do however want to make sure that players aren't encouraged to leave more than they are to surrender, though.

I think I edited my post just before you read it.

"At the very least, how about a small bonus (*1.15) for a winning team by base destruction and a small bonus for a losing team (*.85) for base destruction (since both teams fought it out until the very end)?"

That way it's providing a slight incentive to finish the game outright for both teams (since one team often just camps when ahead in an attempt to force the enemy to surrender). Could even do a 1.10 and a .90 multiplier for time running out too, I suppose.

As far as populating additional servers goes, I think that your second multiplier could accomplish that well enough. If you just keep that in and then add in an additional multiplier that takes into account total number of players, it should balance it out well enough so long as the player also gets enough points. I just think it's important that the script keeps a running tally for number of players that join the server in that game, rather than just taking the final amount.

[Ryz]

Maybe, but I think this will be difficult, you can divide people in multiple classes and than divide them by points and classes? For example:

Kills with snipers (snipers)

Building destroyed / damaged with c4 (infiltrator)

Building damaged / destroyed with vehicle (tank 'pilot'

Repairpoints (repair guy, maybe even divided in building and vehicle repair points)

Mine kills (defender)

I understand this is quite difficult, but if you would balance on score (per time radius) only you might get teams who look balanced based on points. But ingame it still might not work, cause these people with a lot of points cause sieging a building in one game, might be totally worthless next round cause they don't have the support of people defending their base.

I am not sure how this would work out, but I can imagine two things to be 'more easy':

4 people have kills with mines, even though they aren't really highly ranked. Those 4 people will be split over two teams so you have, in a normal situation where those kills occurred in a building, at least 2 people who know to defend.

Snipers gets split over both teams, so every team has the benefit of a sniper IF they chose to be a sniper and on the other hand teams have some guarantee that they won't have all the 'solo' snipers who aren't participating.

Outcome would be that you won't only have highly ranked players, but also teamplayers. It would be cool if the balancing system could more or less assure every team has a miner and a repair guy as a basic.

[HaTe]

I think using score (points) is fine as long as the points earned are balanced. So rather than working ladder points around score, itd be much more convenient to make sure that the points earned are reflecting the things you mentioned. I think that the devs and community devs have done very well with this so far and it is containing to improve in that aspect as well.

[Ryz]

Just noticed the leaderboard now is more detailed with beacons disarmed / placed in it for example, but also proxies placed and removed. GJ!