After "banner ballance" options implementation all other balance options for me and my friends - are no more acceptable.
Current autobalance is a very good step to the right direction (banner balance)
Very good, but only as a first step. Here is need at least one more.
I (and my friends) very like this new options "autobalance by banner".
Now we just can't imagine - how it is to play without "banner balance"
But here is a some "bugs" or "not exactly correct working things".
(see below suggestions)
First of all - It would be nice to see a current Formula (not a joke).
Lets define some variables and some rules (what developing formula must lead):
(Btw here will raise questions that could apply not only to the current problem, but also to a wider class of problems.
Such issues will be highlighted in blue.
Team_X (Team_A and Team_B) = quantity of players in one team (A or B)
TotalPlayers = Team_A+Team_B = total players in both teams
Banner_X = quantity of players with one banner on the server (Banner_HRE or Banner_STR or Banner_Merc e.t.c.)
RoundDmgByPlayer_A = Damage dealt by player "A" to the enemy team in one round. If it can be stored and displayed at the end of the round - would be nice.
MapDmgByPlayer_A = Damage dealt by player "A" to the enemy team in all round on the current map. If it can be stored and displayed at the end of the round and at the end of the map - would be nice.
PlayerWeightGlobal_A = "weight" of the "A" player (global, in long run_. Weight = helpfulness (correct word?) of current player to the team.
It can be as just a simple variable = kill\death, but also can be a complex variable = function of more than 2 (kill and death) variables.
Overall weight on very long time period (whole player\character live - counted from birth or from "rebirth" if it is a "child" ).
PlayerWeightLocal_A = "weight" of the "A" player on the current map. This variable added to avoid big counting process and wasting resources on that.
At the every map end - all info about player (doesn't matter exactly what info - just K\D or much more) sending to the main DB and PlayerWeightGlobal_A(old) recalculating with just received from server PlayerWeightLocal_A. And when new map starts - on the new map now will be showed on old PlayerWeightGlobal_A, but recalculated. So we can use 2 different variables to make a teams more balanced - "long run" variable and "short run".
It is very good, because players can be very weak at start of playing by this character (some weeks ago), but if he is very good playing right now - we will count this too (I mean this will effect on team balancing too).
Faction_X_player_A - as today every person may choose any banner (and in fact all player may just come to server to see what are 2 biggest faction in current game and just to change own banner to one of the "biggest faction in the game" banner, and here will be only 2 ^) different banner on the server... and in this case "banner balance" will not work as designed.... so - to avoid this - read next...). So - we must have an info - does this player "A" with banner "X"
really belongs to Faction "X". Before this BTW must be implemented "cRPG faction engine", what allow to players to send a request to join to faction, and allow to faction leaders to accept or reject this request. In this case only real faction members will be recognized as "players group", and "fake" members will be not counted (as it must be).
Here is
3 main procedures\algorithms oriented to split players\group_of_players into 2 teams.
1. Before first round - "first roster" splitting.
2. Some parts of algorithm may working at the every round end counting from the 2nd)
3. Full algorithm working only between round 1 and 2 - to let all player are able to join and all will be counted =================================================
Lets start from this, because it is a "main" and other are only part of this.
Algorithm of splitting players between teams (banner balance oriented):
(3.Full algorithm working only between round 1 and 2 - to let all player are able to join and all will be counted).Full Algorithm Step 1. Count (calculate) a faction count (how many) in current map, define what faction exactly presented on the server, define faction members list
Go through all players and if two or more players have the same banner "X" (and they really are in this "X" faction) - then faction X is presented.
Faction with only one member on the server ATM - counted as single player (not a faction player).
As result - there are:
- a list of faction what must be taken into account in splitting process (Faction list = {Faction_HRE, Faction_STR, Faction_Merc} - for example)
- a list of players in every faction (just to remember - REAL members, not just a "temporary banner takers").
- a list of factionless (counting as factionless) players
{
{Faction_HRE_player_X1, Faction_HRE_player_X2},
{Faction_STR_player_Y1,Faction_STR_player_Y2,Faction_STR_player_Y3,Faction_STR_player_Y4},
{Faction_Merc_player_Z1,Faction_Merc_player_Z2,Faction_Merc_player_Z3}
+ factionless players
{FactionLess_N1,FactionLess_N2,....FactionLess_M}
}
Step 2.Calculate or receive from DB every player (faction and "factionless") global weight.
Here is very important question -we may count first round results (calculate and count local weight) and we may not count.
As for me (by me) it must NOT be counted. Because ATM some players in first round (I mean "independent" players) trying
to choose winner command by special behavior - for example to kill many players or do not kill (even if they can)....
If it is needed (isn't clear) I can explain it later.
Step 3. Split larger faction by the teams.
Here is must be not a solid (one) function for all cases, but complex function what takes into account real (%) part of faction and factionless players,
number of big, medium and small (are numbers are not constant, but depends of current server players count) factions and etc.
Mainly - it is so:
Here is a 10 faction (1st faction biggest, 10th - smallest).
So 1st faction goes to Team A, 2nd to team B. E.t.c.
But it doesn't mean what 1,3,5,7 will be in Team A and 2,4,6,8 in Team B. 100% not so.
This procedure must be something like "Cluster analysis" or "mathematical analysis" with idea how to divide some amount of "clusters" of players
with own (cluster) weight - in 2 teams and do not "brake" clusters and lets teams weight will be equal or not (depends of % factionless and faction players in total players count).
It must be complex process (and it can be implemented by many (all will be correct) ways).
If it will be needed to write specific\concrete\particular program code for this - it will be done.
ATM- it is idea how to. Implementation is only 2nd or 3rd problem. Main is idea.
This stem split or ALL faction by teams (all of faction players) or most of them.
I mean most of faction will be in one team. 9 of 10 factions will be solid 100%.
And may be only 1 or 2 (depends of roster) will be spitted. But IMHO it will be rare.
It will be iteration process.
Step 4. Now we have two teams with some factions inside.
And now we putting factionless players (depends of players weight) into the Team A or B.
And at the end Teams weight must be the same.
BUT.
If here is a problem to put factionless players in both team and receive equal teams,
then go to stage "3" and do faction balance so - let it will be NOT equal (for example 45:55 weight of A:B).
And then again stage "4" (this stage).
This will be iteration process. If needed of course.
But it will NOT TAKE a lot or processor time or memory. It only looks complex in many words (in plain text), computer code will be easy and simple.
And fast (for today PC's arrange and split in 2 pieces 100 players by some criteria - isn't a job at all...)
Main algorithm ended.
P.s. it is important - determination who is faction and factionless players doings only between round 1 and 2.
All players who come later will be counted as factionless due to limitation of calculating process.
But, if this process (algorithm) will be really fast and will not be a problem due to processor time and etc.,
determination may be done every round. But personally I like an idea to do it once pro map.
It is easy to program.
=================================================
What must be done after 3rd and all next rounds 2. Some parts of algorithm may working at the every round end counting from the 2nd)First of all - this algorithm will work (frequency) depends of algorithm settings, and players will be moved from one team to other or:
A. every round (are possible to be moved - not will be moved in 100%).
B. every 2nd round.
In case "A" to move or not to move will be defined by "tolerance limit" between teams.
It's needed to avoid every round "jumping" players (by algorithm, not by himself) between teams.
In case "B" this "tolerance limit" can be a little lower. But with the point like in "A".
Step 1.
Because some of faction players may leave server - check - if faction members still the same and balance between factions is still the same (inside "tolerance limit"). If yes - go next, if not (if it is REALLY big difference) - here are some ways: rebalance all server or compensate it by factionless only players.
In case when it is need to rebalance all faction again (due to dramatically players count change) -
this step is almost the same as "Step 1" from "Full algorithm".
Step 2.
Taking into account PlayerWeightLocal_A (every players weight on this map) - rebalance factionless players by teams while faction players (their place) are frozen.
This step is almost the same as "Step 4" from "Full algorithm".
P.s.
It is very important to increase "tolerance limit" after every balancing to let be next:
first balancing (after 3rd or 4th round) - 5\10\15 players are moved.
second balancing (after 4th or 6th round) 2\5\7 players are moved
third balancing 0\1\2 are moved. I think my idea is clear.
Digits are just for example to small\medium\large populated server.
=================================================
1.Before first round - "first roster" splitting.This step is almost the same as "Step 4" from "Full algorithm".
Thats all.
A concrete realization (the exact values and other details) are not important.