A Bit of Better Balancing

[Gil-galad]

Or that, indeed. but if somebody is swapped because of you answering the phone, when you hang up and resume action, that swapped player should arguably be swapped back too.

[Gil-galad]

The value of a kill, or a damage, can be broken into various parameters.

 - how close you are from your target. the further, bigger the value => Aim factor
 - the quality of the target you off or damage. The better player, the more value has the kill or the damage => Target dangerosity factor.
 - how close the target is from his flag post, his dropped flag, your dropped flag, your flag on its post. The closer, the higher the value of the the damage => Implication factor. (1)
 - Is the target shooting your FC? Or killing your best player?  In essence, what is the value of the targets YOUR target is shooting (or aiming, as trying to shoot at)=> Support factor.
[edit] Since writing this, i've  thought of one more general factor :  the distance from spawn. see below.

Note : "how close is the player from the flag" could be swapped by something else. In fact, what you want is to order the value of the kill for it to be the highest (for this parameter) when you kill the guy that would have reached the flag first. Perhaps looking at player vectors could be better suited to reflect the value of some relocations and movements in the map.[EDIT.. see next post. I'm working the ideas]]

After some thoughts I ended up with this. what do you think?

(1) perhaps better broken further to discriminate between [ your flag defense  and flag retrieval ]  and [trying the take their flag and preventing them from returning it], with the idea of distinguishing offense and defense. Perhaps not so useful as all the 4 categories separated instead of joined 2x2?

[Gil-galad]

If a player is equidistant of the two flags : he should have a value of 1/2  in both [damage delivered to flag defender] and [damage delivered to a flag taker] counts when the enemy kills him. whatever the position and situation of the flags (dropped or on post). Take the actual position of the flag if carried or dropped.
if the player then reaches to the enemy's flag post (flag on it), the value of the damage credited to another player that would kill him there would be maxed for [damage delivered to a flag taker] and minimized for [damage delivered to flag defender].
If he takes the enemy's flag, he keeps full value for others as [damage delivered to a flag taker] (distance to enemy flag =0).
Now, as he returns to his base, on top of that, his enemies will be credited more [damage dealt to a flag defender] as he gets almost to his flag's post.  If he is killed, the value his enemies will get for [damage delivered to flag takers] would still be full value, as the value [damage delivered to flag defender], because he is close to his own flag. He has there the fullest value of the Implication factor if killed, the two indicators being maxed.

Now the enemy being crafty go and takes his team's flag, so he can't score.  As long as he caries their flag, the one that kills him is credited with a full [damage delf to enemy flag taker], but less and less value, as the other FC rejoins his side, for the player that kills him, in the [damage delt to flag defender] count. In that situation,  that value gets to zero once the max distance is achieved (the other FC ran all the way and is waiting to score on his flag post while he had done the same).

I think this could work well. it's clearer this way. It's a nice step towards the definition of the implication factor.

[EDIT : I kept writing about killing, but I do mean damage delt to, which will not always result in death.]

[Gil-galad]

for averages calculation and variations at the end of the match, the accumulated total for every category by a player could be weighted against the value achieved by other players, to avoid the noise of the variation of the game-play rhythm that is due to the nature more or less spammy  and speedy of the maps.

[edit : or not. I'm full of doubts.]

[Gil-galad]

Other counts, credited to players? flags? that are necessary to value a flag retrieve and a flag run. We need these two three values

A. [how much away is your flag from your base] as a value between 0 and 1, to be able to attribute it to the flag retrievers. when they return a flag.

B. [how much close is their flag to your base] as a value between 0 and 1, to be able to attribute it to the flag carriers when they drop a flag. Or as fraction of it, the fraction of the path he did carry the flag if he didn't pick it on post but where it had been dropped, like was said earlier in this thread.

Inverse A and B for values for the other team.

The tactical value of a dropped flag, if A=1, B=1 (a teammate is scoring or the enemy's flag has dropped on your flag post) is there the fullest and should be credited for a flag return.
Likewise, the tactical value of a flag run lies in how close you got it to your flag post, even if your flag isn't on its post because it's there that you'll be able to score if yours would be retrieved, like B=1 (completely close to, so, in the same spot).

If the enemy's flag is (dropped or carried) on your post, but your flag is at their post, then the return of your flag should be credited full value. If your flag is on post, and you do a successful run, the run has the fullest value.

Why? because both flags are necessary to score. So, the value of a flag run or a flag retrieval should also depend on the situation of the other flag, favorable to your team or favorable to the other ; depends on the position of both flags.

If you combine A and B for their total to be equal to one (=1 cap, just a scaling of the results), and scale the A and B parameters for one cap  1= A+B. I keep banging my head around this but I'm sure it should be fairly simple to finalize the vision. the values i give would have to change to reflect this, but it's all a question of weights after that anyway. I think it's more general and precise definition of  caps and flag actions, and thus more robust,  to think of them like this.

0 of a cap is when that value reaches the fullest for the enemy, meaning he is capping. Boths flags on their post would be half a cap for both teams, in that sense - as would be both FC waiting on their flag post for their flag to be returned. like that, if your flag gets taken to the exact middle of the map while the enemy's stays on its post, it's actually 0.75 of a cap for the enemy, 0.25 for you. We could still discuss further about distances not flag post to flag post, but center of gravity (see below)  to enemy flag post, to correctly measure efforts invested in the flag carrying or returning, since it's so crucial. but it's the rough idea.



C. [is the player closer to his team's zone or the enemy team's zone] something like that. Values 0 to 1.

I also propose  to use the center of gravity of the team spawn points and team flag post to establish the team "center of gravity"(1.) as points to define where you have more or less value if killed. If the distance you are from your center is greater than from your enemy's, the damage an enemy deals on you has more value. The most value for this factor would be 1 on top of the enemy's center, to 0 on top of your center. It's a tentative to factor in the spawn points. in vctf.

That would be one more variable per player,

(1.) I mean the center of the polygon those points make in any map. Per team, or to say it again in another manner, per side. EDIT : here  perhaps a pole of inaccessibility will be useful github if so.)

[Gil-galad]

Reading back, I see i give a lot of though about damage delt, but it's not taking into the value for the enemies of the action I described earlier. They are valuable game for their enemy at the situations I described, but we have to reward the risk factor.  It goes like this :

The circumstantial value of where the player is set at at a given instant, and in relation to other points some of them maybe moving - the value given by those factors, when when summed, define the value of the damage the enemy deals on you. We have to consider the risk takers too, and give them something. For a flag run, how close you get to their flag post before dying should be valued too, because it's opening the way to the flag. In fact, going to the enemy flag on its post is in many maps more than 2/3 of the distance flag post to flag post. Since a flag run flag post to flag post is worth 0.5 of a cap (max), the journey to the flag is worth like a portion of it. It should be valued like this. If the flags are their flag post, the worth of a successful run should be considered like this :

(distance of the path from the spawn point to the enemy flag post) + (distance of the path flag post to flag post)  = value of the run = 0.5 of cap.

You can there find a value for caps against distance value, like how much is of a cap is one distance unit worth in the given map. This value will change for each map because maps vary. Used for flag carriers and flag retrievers matters. But also for flag takers that die before metamorphosing into the flag carrier butterfly (often a short lived condition, as we know). If one player dies by the enemy's flag even without touching it, his tentative has value, as it forced the enemy to react to him, and, with the teammates doing the same, hopefully overwhelm them. So lets reward this as a portion of the necessary travel distance to cap a flag. since we can argue that these tentative are portion of a cap that never get full, but still they're there, and those players tend to cap. Anyway, it's a way to give a balanced value for the risk of going into the enemy zone (pole of inaccessibility as seen last post.). 

Now, let's consider the situation of when the player picks it up or return it from  somewhere else, because it's dropped there. The flag hasn't all the way to travel to his flag post, it's also closer to the player's spawn points, hence costing less reaching it as well as then taking it to the flag post.

You could then use the value determined above a multiplier to compute the value in cap of a distance (not any sort of distance, just the carried or returned distances. Edit actually there's one more distance, that is the distance you are when you die, from your spawn and from the enemy 's flag post).

((Distance the dropped flag is from your flag post) + (distance the dropped flag is from your spawn)) x (the multiplier) = (value that assess how valuable is a flag run or a flag return when a flag is dropped, anywhere in the map).

Note that we decided to use a ratio for the flag travel, 0 for nothing of the way, 1 for the full way. The flag will be dropped at a proportion of 1,  and we ought to do the same for  the spawn to enemy flag post distance. Just multiply the corresponding ratio with each term in the above calculus, and you have the value.

Of course, I'm here training the idea, going for simpler cases first.

But we know that the player can still drop the flag. I'd look at the value of where he picked it, the one of where he dropped it using the calculus above, and substract the first by the last to have the value of a partial run.

One the things we can manage better, then, is when the player actually get the flag further away than it was before. In this case the right way to input in in the player stats would be a negative value, distance and the such going down in his stats, according to how much further did the flag go.

NOTE. I wrote distance as distance of the path. I wrote "spawn" as a place, but i should have used, if all agree to the idea, the pole of inaccessibility of the polygon designed by the team spawn points and the team flag post. If there's only one spawn point, then the point to be used is the middle of the segment of an imaginary line that would connect spawn point to flag post. by the shortest path (a straight line). See previous post for the pole of inaccessibility if you're not understanding what it is. I wasn't explicit for sentence simplicity's sake.

[The_Cowboy]

Howdy!

At this point in time, Equalizer is 60% complete. We have a strong PHP backend with the ability to memorize Googolplex worth of players state (kidding, depends on the limit of the PHP webserver). A smooth UnrealScript-PHP communication channel has been established and CTF gameplay gauging measures discussed in this thread are now functional.

Now comes the hard part: designing a metric on basis of which players shall be categorized in teams. So far, I have been thinking of two actions
1. Attack: Score, FlagGrabs, Frags and Captures
2. Defense: Covers, Seals and FlagKills
(in units of "Per Hour") to compute the individual player ratings. Next, I don't know how to utilize the ratings to decide teams. I am all ears.

P.S You may want to read https://miasma.rocks/index.php?topic=1703.0
P.P.S https://github.com/ravimohan1991/Equalizer

[The_Cowboy]

https://www.youtube.com/watch?v=WXQzdXPTb2A

Just leaving this link here. Because we men are good with abstractions, this should help in coming up with good metric.

[Flenser]

I'm glad I didn't get too far in reading up on PHP.

It seems like the scoring criteria might be over-complicated, at least to start with. Maybe just record each player's ending score at the end of a game, and use the sum or average of that, to pick balanced teams?

[The_Cowboy]

Yup, that can be done! How do you suggest teams should be categorised? I need the algorithm!

One algorithm could be
 
1. Query backend for the PPH of all the players present on the server.
2. Sort and arrange the player array in some order (descending let assume).
3. Highest PPH player gets into some random team (say Red). Then next highest player to the Blue.
4. Now the next next highest player can be either in Red or Blue depending on the difference of total PPH of Red and Blue. If the difference is below some threshold, then randomly the player is categorised else in Blue.
5. The new players are categorised randomly (?)

[Piglet]

In Freon/TAM, PPR is used. One team gets the player with the highest PPR. The other team gets the next two highest, then it's alternate teams all the way to the lowest PPR.

Mid-game if the average PPRs are way out it balances by swapping two players whose PPRs would most closely balance the team average (or something like that!).

That's fine for TAM, but for Freon there are two main skillsets that ideally should be balanced: Fragging and Thawing.  A better balancer would somehow arrange that the two teams have similar fragging and thawing ability. Some players frag mostly and some thaw mostly. Some do both and some do neither.

With just those two attributes it's hard to code a balanced pair of teams.

For vCTF it's harder. There are different roles to try and distribute. The current code TheCowboy has written tracks:

Captures
Grabs
Covers
Seals
FlagKills
TeamKills
Points
Time Played
Frags
Suicides

Ok - given those stats for each player...balance teams. Hmmm. Hard.

[Flenser]

Given that we have zero balancing now, I'd say go with The Cowboy's algorithm — best-ranked player on one, 2nd best on the other, then check the "scores" of the two teams and keep adding the next-best player(s) to the team that's down in score.

Then see if that helps by running it for a week. See if it needs more tweaking. If not, done. If so, then we can try to figure out which aspects of gameplay are still unbalanced, and factor those into the balancing. I have to believe that something is better than nothing, but I could be wrong.

I was up in the air as to whether to have the database server pick the teams (have the UT server send the list of players to the PHP server, have the PHP server look up their rankings and generate the teams, and send that back to the UT server. Or, keep the database server relatively dumb, and just store and fetch info about the players.

[Piglet]

Currently the database is dumb. It collects the information.

The way I see this going is that as people join the unrealscript code will grab stats from the php&database and then order the players before the map starts.

The question here is the algorithm to use the data to derive a rank.

[tirofijo!!]

i think the best option in vctf is letting people to choose teams, i guess the best players wont be joining in the same team right? R I G H T

[The_Cowboy]

i think the best option in vctf is letting people to choose teams, i guess the best players wont be joining in the same team right? R I G H T

Yup, in an ideal world that would be a solution. But real life constraints are too intense which interfere with right decision making (saying from first hand experience  ).

The goal here is to make the game more engaging and relevant for everyone who chooses to get involved.