[dalto]

Originally Posted by Extreme_One cool. How about not writing data about BOTs to the database? Can you ignore them altogether (in the database) whilst still maintaining Team Balancing when BOTs are active?

I can add that as an option. That is what it used to do but I was having problems with the bots. Probably only an issue on extremely small servers.

[Extreme_One]

Originally Posted by dalto I can add that as an option. That is what it used to do but I was having problems with the bots. Probably only an issue on extremely small servers.

OK cool.

It's just that we noticed the freezing when a BOT left as well as when a human player left and I noticed that data for the BOTs was also being written to the database.

Whatever it takes to stop the freezing and maintain the integrity of the Team Balancing algorithm.

[pRED*]

Dalto you should use the threaded sql natives. Would get rid of the pauses.

[dalto]

Originally Posted by pRED* | NZ Dalto you should use the threaded sql natives. Would get rid of the pauses.

Thanks, I will take a look at it.

[exvel]

Russian translation

[Shadowdogg]

Whats this about pausing? I can't have distrubtions on our server.

[dalto]

Originally Posted by Shadowdogg Whats this about pausing? I can't have distrubtions on our server.

Some people are seeing small pauses when people leave. I have made some changes which I believe will fix the problem. It is in testing now.

As soon as I am comfortable it has been tested I will release it.

The team balancer is a lot more complicated than any of my other plugins and I like to run it for at least a couple days to make sure we have an adequate test.

[[Arnold]]

Thanks for your plugin, it made a good job at first sight, especially considering it's early stage! Could you perhaps post some details on the algorithm you used?

[dalto]

Motivation:
My motivation for doing this was that I had tried several team balancers and none of them were doing a very good job balancing the teams. As I run a small recreational server this was very frustrating.


As I started to look at why this was I realized that it was primarily because a few key reasons.

• Some team balancers look at team strength to determine if the teams should be balanced. This means that there were cases where it was deciding the losing team was too strong and taking away key players.
• The balancing algorithms were often looking at things like the real delta between kills and deaths or just the total number of kills. When players join mid-round these stats can be misleading.
• The most critical problem that seemed to plague almost all team balancers was that they were looking at round statistics to evaluate player strength. Unless you have exceptionally long rounds with a fairly stable player base, this just does not work.

It was this which motivated me to get into Sourcemod scripting in the first place. I knew that a team balancer was not a good first project though so I did some other things first.


Vision:
With a couple of plugins under my belt I began working on the team balancer. Taking from the above, there were three principles which guided my development.

• I decided that the evaluation of determining when the teams should be balanced would be based on short term team performance rather than strength. Balancing on performance means that we take strong players away from the team who wins too much regardless of the existing team strength.
• I decided to use the kill/death ratio (kdr) as the primary measure of player strength.
• Most importantly, I decided to track long-term kdr. This gives me a longer-term view of player strength.

There are two main components of the team balancer. They are the evaluation algorithm which determines when the teams should be balanced and the balancer which moves the players around. Of the two, the evaluation algorithm is far simpler than the balancer.


Evaluation:
As discussed above the evaluation algorithm is performance based. The evaluation function can return three possible states. Balanced, Pending or Unbalanced. There are three CVAR’s that control evaluation.

• sm_team_balance_min_rounds is the number of rounds a map will run before balancing starts. This is because the first couple of rounds are often not a good indicator of performance because of the pistol round and people joining late.
• sm_team_balance_new_join_rounds is the number of rounds to wait before balancing when a new player joins the losing team. This allows us to account for recent changes and ensures that we don’t balance too often.
• sm_team_balance_consecutive_wins is the number of straight wins required to immediately declare the teams unbalanced.
• sm_team_balance_wlr is the win/loss ratio needed to declare the teams unbalanced. It is computed by dividing the losing team’s wins by the winning team’s wins.

Using the above, the evaluation algorithm does the following.

1. Checks to see if the current round is less than the minimum number or rounds. If it is the balance is Pending.
2. Checks to see if a player has joined the losing team in new_join_rounds rounds. If one has, the balance is Pending.
3. Check to see if the winning team has won at least consecutive_wins times. If they have the teams are Unbalanced.
4. Check to see if the win/loss ratio of the losing team is less than wlr. If it is then the teams are Unbalanced.
5. If none of the above are true than the teams are considered balanced.

As you can see, the evaluation algorithm prioritizes pending conditions over unbalancing conditions.



The Balancer:
Coming soon....

[dalto]

Originally Posted by [Arnold] Thanks for your plugin, it made a good job at first sight, especially considering it's early stage! Could you perhaps post some details on the algorithm you used?

Thanks, it should get better as it builds up kdr statistics for your regular players.

I started to post some details above. I will keep working on it.