Auto Team

From BZFlagWiki
Revision as of 23:13, 21 February 2007 by Brad (Talk | contribs) (add category)

Jump to: navigation, search

AutoTeam is a way of assigning color/team that is already in the 1.10 release. It is selectable by the server or by the client. When selected, the team assigned to tank is decided by some automatic criteria.

Bots always join requesting AutoTeam.

The team selection is done in this way:

* If Rogues are allowed and player asks to be a rogue, assign to Rogue if there is space for it. They don't want to be in a team at first.
* If you have only one colored team (not Rogue) with players, assign the incoming player to the others.
* When you have at least 2 teams (not Rogue), before assigning other teams, put the player on the lowest numbered team with at least a tank on it.  
* When you have at least 2 teams with 1 player, don't bother creating another team, add a player to one of these teams.
* When the above rules give more than one choice, follow the user requested team, and if not available, assign the tank to the weakest (in term of team point) team

I explain with example what I mean :

* We have 4 teams with this distribution 5R-2G-1B-0P on an AutoTeam server.
     If a player joins he will be assigned to Blue to have 5R-2G-2B-0P. Should both the 2 Blue exit and rejoin, he will go to Green having 5R-4G-0B-0P
   in case of a distribution 5R-5G-0B-0P, when Blue/Purple tanks has left, while Red/Green stay, I want to start the other team earlier, so we can have 5R-5G-0B-1P and the next 5R-5G-0B-2P
* With 20 players joining, with no leaving, team will be 5-5-5-5
     if, after some leaving, we have 10-0-0-0, the next 10 players joining will give 10-10-0-0
* With 4 players joining, with no leaving, teams will go 2-2-0-0, that I think is better then 1-1-1-1


TimRiker comments:

* If the player asks for a color, they should get that color unless there are no more slots of that color available. If there are no more slots then treating them as type "automatic" is fine.
* I don't under stand what you mean by "try to balance the bigger"
* There is no "user preference" just a "user requested team" which might be "automatic".

learner/brlcad comments:

I updated the "current 1.10 behavior" description to reflect what I effectively made it do in 1.9. Basically, the player gets what they request if it's available, otherwise the assignment is automatic to the first available and most empty team. If there are no slots available, they are joined as observer (or rejected).

Let me reiterate, the player should get what they asked for period. The only questions that come into play are when they ask for automatic team placement.

The suggested changes listed above by Tupone effectively makes only one modification to the existing behavior. Instead of simply joining a player to the least filled team, a bias is imposed to prefer filling teams up first. That is to say that if we have a map like HiX where there are four teams with, say, 10 players allowed per team -- there will be 10 vs 10 vs 0 vs 0. New players will cause the third team to be imbalanced until sufficient additional joins/leavings are achieved.

I considered that case when I first implemented the automatic joining server-side and rejected it for a couple reasons:

1. That imbalance caused can be detrimental.  The team is effectively weak and potentially unplayable (from a CTF perspective) until rejoins or new joins are able to balance the teams out.  This time is completely unknown giving rise to a horrible potential situation.
2.  It's simply not true to say that two or three 'large' teams are better than four or five relativley 'empty' teams.  That is completely personal preference.  To impose a bias for larger teams even potentially goes against the server/map design.  I made a map for 4 teams -- empty or not, that is what was specified and may be what I (as an operator) want to encourage.  There may be justification to allow a server-side configuration to allow this autoteam-bias, but I seriously think it's a bad idea to make it the default behavior.