The current team balancer seems to do this, from observation:
When the number of players differs by more than one, move the most recently-joined player from the team that has more players, to the team that has fewer.
That doesn't do a heck of a lot when it's 4-0, and Arbok, DcNR, etc. are all on the winning team, 3 people rage (or otherwise) quit the losing team, and some poor soul who just joined 30 seconds ago gets moved to the losing team.
Here's my proposal, and I have no idea whether it's technically possible, but perhaps it is, or perhaps someone else will have an even better idea.
What if, if the score hits 3-0, the top player on the winning team gets moved to the losing team? If it hits 4-0, then the (new) top player also gets moved.
Or maybe the 2nd-to-top player gets moved? Or maybe the teams get completely randomized.
We seem to have a lot of 5-0 games lately, and they are the least interesting or fun games possible. Either you're on the winning team and it's like you're playing against a bunch of bots set on "visually impaired" or you're on the losing team and you can't even get out of the spawn point before dying or the other team scoring again. I'd love for there to be more 4-3 games or 3-1 games.
What we really need is something like the balancer in Freon, or the code Shambler wrote for ONS in his TitanTeamFix balancer.
Both those things rate every player, then aim to build teams with similar ratings.
The problems for vCTF are:
1. How to assess players for rating
2. How to get enough time, skills, and enthusiasm to write in-game and back-end code to store away and use ratings
1 is very hard
2 is even harder. Free time is short and it's a lot of work.
There is already something similar existing for UT99 https://unrealadmin.org/forums/showthread.php?t=23777 (source: https://github.com/joeytwiddle/code/blob/master/code/unrealscript/AutoTeamBalance/Classes/AutoTeamBalance.uc)
Pros:
1. It has a seemingly decent algorithm for assessing players for ratings.
2. It has been refined over several years based on the feedback from multiple UT99 CTF servers. Assuming the
CTF playerbase has the same magnitude of frustrations (or envies) for unbalanced teams, I don't see why the
algorithm can't/won't work for VCTF crowd.
Cons:
1. What Piglet said (point 2, mostly the time and enthusiasm part).
2. For UT2004 VCTF it might need some patching up. Like identification based on GUID or something similarly robust (instead of just names).
At some point down the line I would love to look into cooking something like this, but no commitments :-\
Hello,
If i can help, being a noob at every thing but of ingame equilibrium sense...
things that come to my mind when i think of a team balancer :
- the closer the guy is from scoring before being killed by an enemy, more the points that should be awarded for the kill, IF the flag is indeed returned. Think of it like an assist on a manta run.
- the closer your flag is from the enemy's flag post base, the more points you should receive for returning it.
- for flag runs : in an ideal manner, if you capture the flag running all the way or just the last centimeter should NOT be rewarded equally, IMO.
- shooting at an enemy that is shooting your team flag carrier should be rewarded more that regular shots, because it's support.
In general, I think the right perspective is to acknowledge and measure what denotes overall match awareness, reactivity and commitment towards VCTF goals (the Things That Need to Be Done, like IMO touching, capturing, killing the flag carrier, returning, and, to an extent, support your team's runner).
I probably forget a lot of ideas i got about this old, old subject. If i remember something that i think that could be of use, I'll post again.
Some time ago I was working on SmartCTF(https://miasma.rocks/index.php?topic=1357.0) which tracks almost all the features that Gil-galad mentions. A snap shot of the features https://imgur.com/BnBo7gk.
Quote from: Gil-galad[The REAL one] on May 14, 2021, 14:50
- the closer the guy is from scoring before being killed by an enemy, more the points that should be awarded for the kill, IF the flag is indeed returned. Think of it like an assist on a manta run.
Can be implemented in that framework with just a couple of lines of code.
Quote from: Gil-galad[The REAL one] on May 14, 2021, 14:50
- the closer your flag is from the enemy's flag post base, the more points you should receive for returning it.
Implemented.
Quote from: Gil-galad[The REAL one] on May 14, 2021, 14:50
- shooting at an enemy that is shooting your team flag carrier should be rewarded more that regular shots, because it's support.
Implemented. They also get extra adrenaline!
Quote from: Gil-galad[The REAL one] on May 14, 2021, 14:50
- for flag runs : in an ideal manner, if you capture the flag running all the way or just the last centimeter should NOT be rewarded equally, IMO.
Implemented.
Quote from: Gil-galad[The REAL one] on May 14, 2021, 14:50
In general, I think the right perspective is to acknowledge and measure what denotes overall match awareness, reactivity and commitment towards VCTF goals (the Things That Need to Be Done, like IMO touching, capturing, killing the flag carrier, returning, and, to an extent, support your team's runner).
That is precisely the motivation for building something like SmartCTF.
Infact Piglet did suggest using these features to balance the teams
Quote from: Piglet on June 10, 2020, 23:35
The readme is great.
What I'd really like to see is something that we can use to ensure the teams are reasonably well balanced at the start of each match (separate from the scoreboard logic so that they can be used separately or together.
What you have in there is a lot of information about the players and how they're playing. All that is interesting, but could be made useful by storing that away and using it to balance teams at map start - separating cappers from each other, separating defenders from each other and splitting the other players into roughly even groups to the teams.
That would require saving the information to a server and recalling the bits needed as players join.
All I will say is that it needs a "better mind" to connect the remaining dots and bring this issue to a just resolution (https://youtu.be/0f2jpwn6M-E?t=80).
great to see that all i thought isn't off the mark, then. And indeed, we stand on shoulders of giants. it would be great to be able to use that. I wonder is someone has ever done something for assault. I used to hope for it years and years on. being a noob forever in coding.
Anyway, i was just giving my vision, and glad to see that is not alien.
Now that you mention, here is the teambalancer (for assault) https://github.com/TheRealWormbo/EvenMatch by one of the giants :D
it is, apparently,
QuoteA UT2004 mutator that provides special team balancing rules for public Onslaught matches.
Onslaught, then, which is pertinent for Warfare.
Ah yes, you are correct! I got confused between the two gametypes.
I am more than willing to give a few pointers regarding the unreal scripting for setting the build environment and writing a well behaved balancer, if you are interested in taking a shot. All it needs is basic familiarity with the programming (java or c/c++/c# or python) and mental coherence.
...and time. A lot of time...and a remote back-end to talk to in a sensible protocol that can take stats information as game ends or as the player leaves the server, and provide you with the stats of the players as they join.
As we've seen over 30,000 different players over the years there'd be far too much information to store in ini files on the server.
Wow, 30,000 is a lot. I have no experience in preparing the backend stuff (could you give a working example of that). Guess there would be some learning for me too.
Anyways I went ahead and setup a repository with initial code https://github.com/ravimohan1991/Equalizer (let me know how you feel about that).
The best examples for the UT side of things I have are are in:
* "TitanAdminSM1" (https://miasma.rocks/downloads/TitanAdminSM1.zip) - using httplib for simple web-server communication
* Freon - grab from your cache directory after visiting the Freon server here. - using UDP connection
Sounds good. I did some research and found http://www.utstatsdb.com/demo/. It is based on PHP and I think I can tailor it specifically for CTF/VCTF (only matter of removing other gametypes and adding some more statistics).
Pros:
1. It has a decent ranking system already built in (http://www.utstatsdb.com/demo/rankings.php).
It would be just to equalize teams based on the points metric.
Quote
Ranking is based on ELO Chess ranking.
Everyone starts with a rank score of 0. Points are based on how often you trigger positive personal score events, e.g. kills, captures, assists, etc. Against your score are deaths, suicides, teamkills, opposing team scores, etc.
The lower the rank of the other player or team is, against whom you score, the less points you will get, so the ripping of weak opponents will get you less rank points, than beating a stronger (in rank) opponent.
2. Nice way to display publicly what is going on under the hoods.
Con(s):
1. Relevant modifications will take long time (6-8 months, not counting the time to be spent on the mutator).
I was wondering if we have enough resources (webhosting wise) to support it.
I really dislike utstats - we had it running for a while and the backend database was huge. It was so huge I didn't want to keep it running.
Something much lighter would be better - tracking just enough information to be useful.
e.g. pph, win/lose, caps, kill/death ratio...or whatever you need to determine which team the player should be in
Yeah, I think I can understand the frustration. It is overkill to basically track the servers, maps played and player career not to mention the different gametypes and each and every shot fired from the weapons :o. For our purposes we just need to track few statistics (like covers, seals, flagkills, captures) along with the total score (it can be discussed further). These statistics will be submitted to the backend (PHP) at the game end or when player leaves the server.
Then, for the backend, we can come up with an algorithm to assign player rating based on those statistics (here UTStatsDB may be useful). At the match start (and when players type "teams") Equalizer will query the backend for rating and, well, equalize the teams.
The Freon process works well - see class Misc_ServerLink extends BufferedTCPLink;
It registers:
games (not really used),
player stats (Rounds, Score, Kills, Deaths, Thaws, Git - of which only rounds and scores are used to get a PPR) - on end of game or when player leaves
It has a request for a player's average PPR
The back-end then does the work around storing the player stats and responding with average PPR for the front end to use at round start to balance the teams (or when the admin calls "teams").
Interesting - the version I used of the back-end is php. I just found this java version: https://www.youtube.com/watch?v=xZXgJogfnKc
Informative tutorial, it is going to be very useful for our purposes. Thanks!
You may have noticed a prototype of team balancer on Warfare. It is already tracking some CTF specific events like covers (https://github.com/ravimohan1991/Equalizer/wiki/Covers) and seals (https://github.com/ravimohan1991/Equalizer/wiki/Seals) and broadcasting them.
Since it is still in alpha stage (bug prone) with a long TODO list, please let us know if you observe anything "funny" or unexpected (something that worked earlier but now broken). Thanks for your patience and contribution 8)
Quote from: Gil-galad[The REAL one
- the closer the guy is from scoring before being killed by an enemy, more the points that should be awarded for the kill, IF the flag is indeed returned. Think of it like an assist on a manta run.
Question:
If the Killer gets killed and then flag gets returned, does the Killer still get points?
Also I would note that on killing the FC (flag carrier), you get 3 points by default (1 for the kill and 2 for being FC). Any other added bonus would be at the top of that.
Do you get points for returning the flag (not killing flag carrier)?
I noticed that sometimes you get 3 points, sometimes you dont get any points.
Quote from: The_Cowboy on May 21, 2021, 23:37
Quote from: Gil-galad[The REAL one
- the closer the guy is from scoring before being killed by an enemy, more the points that should be awarded for the kill, IF the flag is indeed returned. Think of it like an assist on a manta run.
Question:
If the Killer gets killed and then flag gets returned, does the Killer still get points?
I think that that player should receive those points.
Quote from: The_Cowboy on May 21, 2021, 23:37
Also I would note that on killing the FC (flag carrier), you get 3 points by default (1 for the kill and 2 for being FC). Any other added bonus would be at the top of that.
I guess i should have worked my piece better. I use "points" and "award", but what i meant is that when a player kills the enemy's team FC, that player should be deemed more useful/effective to his team than another who did not manage that.
How to instate the usefulness?
If the enemy is almost scoring, you are
more usefull to your team if you kill him than your teammate that killed the FC right beside your team's flag post, since it's more difficult (distance from spawn point and aiming). It's also less likely to be done by another teammate (same reason). So, I'd measure the distance from the enemy's flag post, and give credit by distance unit (the smaller the better (1)). Then, for this competence, measure the sum of those distances, and rank accordingly. I'm not sure how to traduce all that in points, because points mix various actions. How to balance the worth that they have relative to one another? How to evaluate a (normal) kill count against a flag touch counts? Both are useful to achieve victory.
To end up with a unified value for a player is more complicated than that. Feel free to point the shortcomings of my ideas to devise ways to deal with them.
(1). Or the distance from your team flag post, the more, the better. Same end result.
Quote from: Gil-galad[The REAL one] on May 22, 2021, 11:22
I think that that player should receive those points.
Great! That is what I thought.
Quote from: Gil-galad[The REAL one] on May 22, 2021, 11:22
I guess i should have worked my piece better. I use "points" and "award", but what i meant is that when a player kills the enemy's team FC, that player should be deemed more useful/effective to his team than another who did not manage that.
How to instate the usefulness?
If the enemy is almost scoring, you are more usefull to your team if you kill him than your teammate that killed the FC right beside your team's flag post, since it's more difficult (distance from spawn point and aiming). It's also less likely to be done by another teammate (same reason). So, I'd measure the distance from the enemy's flag post, and give credit by distance unit (the smaller the better (1)). Then, for this competence, measure the sum of those distances, and rank accordingly. I'm not sure how to traduce all that in points, because points mix various actions. How to balance the worth that they have relative to one another? How to evaluate a (normal) kill count against a flag touch counts? Both are useful to achieve victory.
To end up with a unified value for a player is more complicated than that. Feel free to point the shortcomings of my ideas to devise ways to deal with them.
(1). Or the distance from your team flag post, the more, the better. Same end result.
I think I comprehend the spirit of this concept. In most maps (like Linear) what you mention (about the relative distance from either flags) works. But some maps which have more space perpendicular to the (imaginary) flag corridor, we may give extra points to the player (assuming FC ran perpendicular to the flag corridor) if we reward based on how far FC moved (lateral distance shouldn't be taken into account).
So we can project the position vector of FC (relative to enemy flag) on to the relative vector of both the flags and get the exact idea about how much progress FC made starting from enemy flag to their own flag. Then we can normalize that magnitude with the magnitude of relative vector to get a number between 0 (FC killed near enemy flag mount location) and 1 (FC killed near their flag mount position).
I implemented the concept in this commit https://github.com/ravimohan1991/Equalizer/commit/be2d7a5d9d882593a47248841fa81bf64bca9279
Quote from: The_Cowboy on May 22, 2021, 12:20
So we can project the position vector of FC (relative to enemy flag) on to the relative vector of both the flags and get the exact idea about how much progress FC made starting from enemy flag to their own flag. Then we can normalize that magnitude with the magnitude of relative vector to get a number between 0 (FC killed near enemy flag mount location) and 1 (FC killed near their flag mount position).
That seems clever. I don't understand it fully, so my nooby opinion is just that.
I guess you'd also have to implement this calculus for flag touch (A), flag drop (B), which would permit you to do B - A = [distance that player carried the flag], which would be a portion of 1 (all the way) and 0,01[...] ( almost nothing of the distance that has to be traveled with the flag, post to post). or something like that. be cleverer than me please, I'm a john snow in statistics as well.
Instead of 1 you could chose another value, one that would reflect better the action's value in points, the real action's worth in the overall point counting thing. it's a question of balance, and it has to be set right.
The problem I see, in traducing any of those actions in number of points, is that you have to balance the right way the various actions. How much is worth each action relative to each other? Like, supporting the flag carrier or touching the flag? Or returning one? Or killing an enemy close to your flag? or just being able to kill and take some of the the top enemy players's pressure of?
I don't know if I just added confusion here. What do you think on that matter?
One other thing that just came to my mind that perhaps can help a bit.
we could also take the last flag drop position to infer the enemies's postion/vector/...? regarding said dropped flag as a way to it to assign value to a kill. The idea is to recognize the value of the action of returning flag, thus also in preventing the enemies from doing it, to be logical.
Sorry for the late reply (got overwhelming few days, not that I was not expecting them :))).
Quote from: Gil-galad[The REAL one] on May 22, 2021, 19:09
Instead of 1 you could chose another value, one that would reflect better the action's value in points, the real action's worth in the overall point counting thing. it's a question of balance, and it has to be set right.
Yes you are absolutely correct. That is the way to compute the fraction of path FC has covered carrying the enemy flag. Now that fraction is multiplied by the maximum score that should be awarded if the FC were killed, if I can say, "within the stone throwing distance" from their own flag. It is configurable and for the admins to decide (I set it to 4). Finally the result is converted into integer. For instance if the fraction is .80 then 4 * .80 = 3.2 and, when converted into integer it is 3. Specifically see (https://github.com/ravimohan1991/Equalizer/blob/44a5fdd02df00376448000c6eeacac5f39696529/Classes/Equalizer.uc#L648)
Quote from: Gil-galad[The REAL one] on May 22, 2021, 19:09
The problem I see, in traducing any of those actions in number of points, is that you have to balance the right way the various actions. How much is worth each action relative to each other? Like, supporting the flag carrier or touching the flag? Or returning one? Or killing an enemy close to your flag? or just being able to kill and take some of the the top enemy players's pressure of?
Those actions have values which are configurable and can be set at the discretion of admins.
As a goal, as far as points go, I concede that at the end of the match, the value in points should thrive to somewhat reflecting the overall actions accomplished by a player.
But what I think that should be done too is to monitor more events per player that are monitored right now. And then find a multiplier to traduce that in points, but to set balance, the points are not the best way. Measure those actions, and then the balancer would work by trying to give to each team an overall identical profile, given available players. the difficulty will be on the very good or very bad players, the one that seem to be a black hole sucking your efforts (when you feel you play alone and in your team is a real noob in small teams context, for exemple) or megaturbo surpercharged (Moi and Arbok join your team and you don't have to push anything, It's a walk in the garden picking the flag)
for flag carriers
- total distance traveled carrying on foot.
- total distance traveled in a vehicle
- for manta run, raptor run, ... i think the right solution is to consider that if the FC is driven or flown by someone else, the [vehicle distance while carrying the flag] should in that case be awarded to the pilot. it's named an Assist, and could be labelled in distance (= distance traveled while driving FC, as distance meaning how much closer did the FC got brought to his flag post)
(very provisional) final note on flag carrying : perhaps the value in Time could be better suited and simpler, or perhaps a good counterbalance for some blind spots we have with the value in distance, as in : keeping their flag while waiting for yours to be returned is sometimes quite difficult, in spammy maps all the more. on those matches, the time you managed to keep the flag should be valued and could be interesting. Of course, the blind spot of the time value is camping with the flag in a remote/inaccessible just to get stats and rewards. or another thing. i don't know. perhaps devise that 1. in set interval, if distance =0 (camping) and [time carying the flag] continues to go up, and 2. your flag is on its post, then 3. the reward for time should be stopped. Aaaaanyway, it's all ery sketchy, it's there because it's ideas and they only (eventually!) get valued if shared.
for flag carrier supporters and dropped flagS (both) defenders, enemy flag defenders and enemy flag retrievers:
- special kill count of kills of nearest to flag carrier/dropped flag. let's call those Support kills...? or, it could perhaps be a count of total damage delivered to those targets.
For flag retrievers :
the value of a flag return is to be understood as in how close/far is your team's flag from the enemy's flag post. Count it the same way you do for flag carriers (same technique you devised). the question is : at how much of the continuum that separates each flag posts was the flag dropped when a player returns it. How close was it from their post? if very close, then the distance from your flag post is big. That value is to be recorded for each flag return, and summed to the the distances of other flag returns already credited to the player.
I still have more ideas, but i don't have more time to get them ordered. Anyway, what do you think?
It's a tricky one. You're thinking in terms of flags all the time - however if you watch me in Bloodbath, my aim is to prevent players getting anywhere near the flag. I'm shooting the hordes of players attacking and trying to prevent them even getting there.
How are you going to measure the value of me killing 100 players before they reach the flag, compared to the sniper being nothing more than a nuisance shooting 100 people milling around the spawn points?
How are you going to measure the value of Moi shooting me and preventing me from defending?
QuoteHow are you going to measure the value of me killing 100 players before they reach the flag, compared to the sniper being nothing more than a nuisance shooting 100 people milling around the spawn points?
I suggested this, earlier :
Quotewe could also take the last flag drop position to infer the enemies's postion/vector/...? regarding said dropped flag as a way to it to assign value to a kill. The idea is to recognize the value of the action of returning flag, thus also in preventing the enemies from doing it, to be logical.
that mecanism would be used for
Quotefor flag carrier supporters and dropped flagS (both) defenders, enemy flag defenders and enemy flag retrievers:
- special kill count of kills of nearest to flag carrier/dropped flag. let's call those Support kills...? or, it could perhaps be a count of total damage delivered to those targets.
meaning that if you kill the enemies to prevent them from getting close, your kill has more value if the enemy is closer, less value if they are further [from reaching their objective, like 1. defending their flag that is on post, 2. taking yours that is dropped, 3. returning their flag that is dropped, 4. taking yours that is on post]. Count those distances, probably separatly, to measure the value of the action, sum them per player. Rank players accordingly for balance.
For points, there's more room.
The example you propose is not satisfactorily addressed, though. spawn kill is a thing that can be completely useless to your team, like we see in some matches in the map longest yard. on other occasions, it is arguably valid strategy : think of the enemy being blocked while you get a head start running with the flag. I guess sk should be valued IF it has a strong (temporary) tactical purpose, which will obviously be related to flags.
QuoteHow are you going to measure the value of Moi shooting me and preventing me from defending?
the value of the kill depdns on how precious you are to your team. if you are the best player in your team (determined by the counts I keep talking about, at least partly, as far as balancer goes), then killing you, blocking you should be beneficial for Moi's team. IF moi were to block one player that does not provide much of value for his team, then Moi is not having the same beneficial impact for his team when he kills him/block him.
I'm still not satisfied but that's all I can think of. There's probably a better way. Perhaps give a set weight to [a total damage given player rank ] to alter what the counts i'm proposing would suggest in terms of team balance. Or something cleverer (please!)
There's also one thing that should be implemented, and much simpler, that is a mechanism preventing team balancer abuse. it could work like this : if, by going on spectator mode (leaving the match) or quitting the server, the team balancer is triggered and somebody is swapped, then, if you try to rejoin, force spectator mode until the end of the match. I think it's the way it works on LDG.
...or you get put back in the original team...
Possibly better to drop to spec or leave to take the phone call than to stand idle.
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.
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?
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.]
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.]
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 (https://blog.mapbox.com/a-new-algorithm-for-finding-a-visual-center-of-a-polygon-7c77e6492fbc/) perhaps a pole of inaccessibility will be useful github (http://github.com/mapbox/polylabel) if so.)
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.
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. 8)
P.S You may want to read https://miasma.rocks/index.php?topic=1703.0
P.P.S https://github.com/ravimohan1991/Equalizer
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.
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?
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 (?)
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.
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.
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.
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 ???
Quote from: tirofijo!! on October 13, 2021, 22:18
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 8)).
The goal here is to make the game more engaging and relevant for everyone who chooses to get involved.
Quote from: Piglet on October 13, 2021, 16:14
The question here is the algorithm to use the data to derive a rank.
Thinking out loud here... Or typing out loud. Or something.
The game already has a scoring algorithm for each player. That score takes into account kills, captures, returns, etc. doesn't it? If so, we should just be able to use the final score at the end of each game.
I was thinking just take the scores of each of the players at the end of a game, and add that to their overall score in the database. But I'm not sure whether someone who plays a lot and gets 10 points per game is on par with someone who plays 1/5 the number of games but gets 50 point in each game they play.
Using a per-scoring-action algorithm doesn't change this aspect, does it? If we record (for example) 10 points in the DB every time a player captures a flag, that still doesn't necessarily balance correctly against someone who just plays a lot.
So, if the DB stores each player's scores, FOR EACH GAME, then we can calculate the average score per game for each player, and use that as the "rank".
So if Arbok only plays 2 games a week, but scores on average 120 points, he's a way better player than someone who plays 120 games a week and scores an average 2 points each game, even though they've accumulated the same number of points.
Good thinking!
Boys, we are going nuclear!
(This is how nuclear shells are filled, well similar process. Pun intended!)
Strange as it may seem, I don't think we want the balancer to be too good. You could end up with stalemate every game.
Saving stats for each game makes for a lot of data.
Storing number of games played may help, though time may be as good. The player who plays for a short time and gets lots of caps or points or covers etc will be flagged high if you use an "attribute/time" benchmark. The same will be the case for players who have huge caps and very large play time. Conversely, a poor player with a lot of caps but a huge amount of play time will be ranked low when using "attribute/time" benchmark.
The hardest thing is using the data (whatever the data) to assign a rank for ordering.
You don't want to end up with all attackers on one team and all defenders on the other. There needs to be a "reasonable" mix of the attributes on each. My gut feel is that if you get the better cappers split between the teams, and then the better defenders split between the teams then you're well on the way.
I completely agree with you Piglet.
I believe what Flenser has given me (us?) a starting point to build the metric upon, starting simply with the total score which covers (covers (see what I did here :D), seals, flagkills etc).
We can than start massaging and tweaking the factors with relevant weightage, depending on the feedback churned.
And of course you will have the final absolute say.
Quote from: The_Cowboy on October 14, 2021, 10:46
I completely agree with you Piglet.
I believe what Flenser has given me (us?) a building point for the relevant metric, starting simply with the total score, which covers the Equalizer factors (covers (see what I did here :D), seals, and flagkills ...).
We can then start massaging and tweaking the factors with relevant weightage, depending on the feedback churned.
And of course you will have the final absolute say.
One big issue exists with using scores per X for balancer ratings.
A game with 32 players will naturally have higher scores than a 12 player game. The releationship is not linear, which makes it harder to weight.
Then there are 10minute games and 30 minute games.
There are also maps that favour kills-scores like bloodbath/edge and others.
Which means some players will have lower ratings due to 12 player games or "slow" maps.
Other players will have extreme scores due to 24 player games on "action" maps.
So when the time comes for the balancer to run, if you have 2 groups of players with equal skill that have 2 types of ratings, they might be paired together because they are "balanced"
Which is why ELO ranking exists, you climb/drop ELO ranking depending on the skill of your opponents.
Which means you should gather data based on weighted subscores(kills-deaths-caps-returns-covers) to create some basic ELO ranking for the current playerbase and then convert everything to pure ELO gain/loss
I prefer a simple approach without the massive overhead of ELO ratings.
ELO works for 1v1. It fails to work when the lowest possible skill player accidentally shoots assault rifle and hits the best player in the world who happens to be on 1hp after battling the entire emeny team; 10 times in the same match.
Wacky thought; given that quite a few players play multiple games in a row, wouldn't it be possible to at least make sure the teams are sort of even at the start of next game, based on the scores of the previous one?
So for instance below, put Kuha and Soma in different teams the next round?
This doesn't solve people leaving/joining and the different types of maps/players, but it's a start.
Not sure if this has already been discussed before, apologies if so.
(https://i.imgur.com/IcgUn6s.jpg)
I think that's impossible or hard to let equalizer know all players levels so it can put best 2 players in the match in different teams and most of good players want to finish all matches 5-0 in 3 or 5 minutes, for me i don't do my best when i play against weak team moreover i don't capture, i give them chances to let matches take more time, game is old i think it's hard to solve this problem.
Here's a snapshot of the highest cappers. I suspect not many are missing from there:
+----------+-------+--------+-------+-----------+-----------+---------+-------------------+-------+----------+---------------------------+
| Captures | Grabs | Covers | Seals | FlagKills | TeamKills | Points | TimePlayedMinutes | Frags | Suicides | EQName |
+----------+-------+--------+-------+-----------+-----------+---------+-------------------+-------+----------+---------------------------+
| 294 | 1091 | 248 | 29 | 786 | 31 | 304162 | 85618 | 5392 | 833 | MrHuhuhu (UK) |
| 261 | 578 | 207 | 24 | 706 | 10 | 244355 | 50168 | 6955 | 334 | moi (FR) |
| 226 | 494 | 34 | 16 | 234 | 11 | 11993.3 | 3502 | 1143 | 262 | Mjolnir (US) |
| 214 | 550 | 234 | 35 | 661 | 22 | 323014 | 83929 | 5119 | 583 | {V][M}Quadro (BE) |
| 184 | 741 | 207 | 32 | 388 | 21 | 91105.8 | 51683 | 4107 | 390 | HELL_FIRE_BACK (FR) |
| 151 | 386 | 103 | 27 | 461 | 8 | 377963 | 131677 | 2621 | 201 | Antonius (AT) |
| 150 | 459 | 262 | 68 | 1166 | 31 | 557885 | 204407 | 6559 | 525 | Rounin_Napoli (IT) |
| 144 | 768 | 128 | 17 | 389 | 29 | 196587 | 83511 | 3047 | 463 | KillaKilla (DE) |
| 137 | 600 | 282 | 54 | 988 | 24 | 809857 | 323911 | 6506 | 564 | Kyhado (US) |
| 134 | 592 | 93 | 15 | 302 | 18 | 239510 | 84987 | 2466 | 340 | Little_Johnny (IN) |
| 110 | 500 | 104 | 12 | 312 | 11 | 276417 | 171044 | 2402 | 323 | DM4E/DRG (RU) |
| 106 | 458 | 70 | 15 | 261 | 7 | 172427 | 34348 | 2356 | 386 | notthc (HU) |
| 103 | 261 | 25 | 7 | 109 | 1 | 54636 | 29462 | 815 | 173 | Mike (SE) |
| 101 | 963 | 162 | 29 | 775 | 26 | 273474 | 131565 | 5435 | 584 | Mr.Magoo (CL) |
| 98 | 631 | 65 | 11 | 166 | 21 | 128924 | 132161 | 1399 | 386 | cronix (HR) |
| 94 | 417 | 105 | 34 | 598 | 23 | 305515 | 120111 | 3437 | 437 | David (AT) |
| 91 | 240 | 20 | 3 | 91 | 5 | 5466 | 1397 | 468 | 115 | Sup (BR) |
| 91 | 449 | 205 | 52 | 654 | 17 | 253291 | 92861 | 4429 | 522 | NONAME_StreetRat |
| 82 | 276 | 34 | 5 | 132 | 2 | 11070.3 | 1992 | 708 | 166 | JP (NL) |
| 81 | 390 | 92 | 9 | 283 | 9 | 185281 | 99399 | 2189 | 289 | corsica_nazione (FR) |
| 79 | 476 | 42 | 4 | 117 | 6 | 23520 | 6495 | 1048 | 242 | duke (PL) |
| 74 | 359 | 65 | 11 | 212 | 11 | 76427.6 | 34252 | 1855 | 231 | ELECTRO (UK) |
| 72 | 281 | 59 | 7 | 203 | 5 | 84976.9 | 13924 | 1806 | 155 | Wirus.Win9x.DòóM (PL) |
| 71 | 207 | 44 | 9 | 185 | 7 | 188298 | 58428 | 1024 | 140 | BaZzY (NL) |
| 69 | 481 | 76 | 15 | 250 | 20 | 198111 | 85899 | 1719 | 215 | -=BL@=- (PT) |
| 64 | 232 | 50 | 4 | 149 | 2 | 64965.8 | 19601 | 1250 | 228 | Paul (RU) |
| 63 | 458 | 51 | 5 | 138 | 9 | 64692.4 | 23610 | 1216 | 238 | ParadoX (BG) |
| 63 | 395 | 150 | 28 | 377 | 20 | 107309 | 54466 | 3907 | 288 | gerbil (RO) |
| 61 | 364 | 96 | 10 | 194 | 4 | 214327 | 59814 | 2917 | 137 | Kuha (FI) |
| 58 | 220 | 46 | 3 | 107 | 3 | 73142 | 36982 | 1074 | 147 | MILEYCYRUS{.}{.} (SE) |
| 56 | 172 | 38 | 3 | 79 | 0 | 28184 | 5621 | 827 | 35 | stefanie (FR) |
| 55 | 272 | 51 | 16 | 286 | 10 | 202632 | 272325 | 1879 | 536 | SaintHappening (US) |
| 54 | 289 | 57 | 5 | 132 | 11 | 137068 | 71450 | 1345 | 207 | BarnBurner (IL) |
| 52 | 167 | 33 | 6 | 129 | 3 | 9548.09 | 3943 | 826 | 150 | ScHiSmFeAr (US) |
| 51 | 124 | 9 | 1 | 54 | 2 | 1939.64 | 471 | 328 | 88 | zath (FR) |
| 51 | 265 | 163 | 34 | 332 | 21 | 325320 | 165732 | 3642 | 366 | Flenser (US) |
| 50 | 175 | 26 | 7 | 103 | 1 | 58289.8 | 17840 | 620 | 54 | HYDRO (IR) |
| 50 | 360 | 50 | 8 | 279 | 3 | 16920 | 5964 | 1149 | 147 | El_Gato (AR) |
| 49 | 328 | 69 | 13 | 253 | 17 | 77012 | 53450 | 1326 | 320 | WïÜè (RO) |
| 47 | 87 | 31 | 2 | 70 | 5 | 24064.5 | 8528 | 817 | 125 | tigger (UK) |
| 47 | 211 | 71 | 9 | 220 | 10 | 168998 | 97010 | 1644 | 252 | imonfire (UK) |
| 46 | 111 | 24 | 7 | 82 | 3 | 79829.5 | 64386 | 486 | 85 | James.T.Kirk (AT) |
| 44 | 150 | 42 | 11 | 157 | 23 | 98712 | 129141 | 1509 | 421 | wito (PL) |
| 44 | 200 | 14 | 5 | 32 | 3 | 3647 | 1140 | 391 | 93 | ThunderCrash (RS) |
| 43 | 169 | 114 | 28 | 385 | 13 | 116764 | 43910 | 3480 | 386 | memo (ES) |
| 42 | 259 | 32 | 12 | 138 | 3 | 129429 | 49484 | 1239 | 96 | RonnieColeman (PT) |
+----------+-------+--------+-------+-----------+-----------+---------+-------------------+-------+----------+---------------------------+
Then again, some people have more fragging than capping...and some of the cappers are good at fragging:
+----------+-------+--------+-------+-----------+-----------+---------+-------------------+-------+----------+---------------------------+
| Captures | Grabs | Covers | Seals | FlagKills | TeamKills | Points | TimePlayedMinutes | Frags | Suicides | EQName |
+----------+-------+--------+-------+-----------+-----------+---------+-------------------+-------+----------+---------------------------+
| 261 | 578 | 207 | 24 | 706 | 10 | 244355 | 50168 | 6955 | 334 | moi (FR) |
| 150 | 459 | 262 | 68 | 1166 | 31 | 557885 | 204407 | 6559 | 525 | Rounin_Napoli (IT) |
| 137 | 600 | 282 | 54 | 988 | 24 | 809857 | 323911 | 6506 | 564 | Kyhado (US) |
| 101 | 963 | 162 | 29 | 775 | 26 | 273474 | 131565 | 5435 | 584 | Mr.Magoo (CL) |
| 294 | 1091 | 248 | 29 | 786 | 31 | 304162 | 85618 | 5392 | 833 | MrHuhuhu (UK) |
| 214 | 550 | 234 | 35 | 661 | 22 | 323014 | 83929 | 5119 | 583 | {V][M}Quadro (BE) |
| 19 | 195 | 125 | 33 | 560 | 18 | 428227 | 303433 | 5048 | 504 | ps (RO) |
| 91 | 449 | 205 | 52 | 654 | 17 | 253291 | 92861 | 4429 | 522 | NONAME_StreetRat |
| 184 | 741 | 207 | 32 | 388 | 21 | 91105.8 | 51683 | 4107 | 390 | HELL_FIRE_BACK (FR) |
| 63 | 395 | 150 | 28 | 377 | 20 | 107309 | 54466 | 3907 | 288 | gerbil (RO) |
| 68 | 474 | 126 | 25 | 358 | 20 | 258127 | 179126 | 3794 | 866 | -=BL@=- (PT) |
| 51 | 265 | 163 | 34 | 332 | 21 | 325321 | 165734 | 3643 | 366 | Flenser (US) |
| 43 | 169 | 114 | 28 | 385 | 13 | 116764 | 43910 | 3480 | 386 | memo (ES) |
| 94 | 417 | 105 | 34 | 598 | 23 | 305515 | 120111 | 3437 | 437 | David (AT) |
| 20 | 307 | 139 | 20 | 254 | 25 | 237639 | 102666 | 3344 | 481 | NONAME_StreetRat |
| 10 | 13 | 98 | 23 | 99 | 6 | 140322 | 73961 | 3313 | 475 | Frazzle (UK) |
| 144 | 768 | 128 | 17 | 389 | 29 | 196587 | 83511 | 3047 | 463 | KillaKilla (DE) |
| 15 | 44 | 118 | 25 | 268 | 14 | 30856 | 15253 | 2931 | 378 | DRAUGR (RU) |
| 61 | 364 | 96 | 10 | 194 | 4 | 214327 | 59814 | 2917 | 137 | Kuha (FI) |
| 23 | 48 | 77 | 15 | 190 | 16 | 165865 | 77555 | 2758 | 210 | Lòónät´iç (AR) |
| 21 | 91 | 72 | 7 | 249 | 6 | 147998 | 133476 | 2709 | 256 | islander (RU) |
| 151 | 386 | 103 | 27 | 461 | 8 | 377963 | 131677 | 2621 | 201 | Antonius (AT) |
| 23 | 229 | 114 | 15 | 178 | 25 | 208659 | 87651 | 2621 | 333 | Russ (UK) |
| 134 | 592 | 93 | 15 | 302 | 18 | 239510 | 84987 | 2466 | 340 | Little_Johnny (IN) |
| 110 | 500 | 104 | 12 | 312 | 11 | 276417 | 171044 | 2402 | 323 | DM4E/DRG (RU) |
| 106 | 458 | 70 | 15 | 261 | 7 | 172427 | 34348 | 2356 | 386 | notthc (HU) |
| 40 | 192 | 76 | 32 | 396 | 4 | 134933 | 29655 | 2340 | 314 | Snoop (UA) |
| 13 | 141 | 57 | 1 | 135 | 5 | 86868 | 40642 | 2330 | 137 | lol (NL) |
| 14 | 77 | 61 | 16 | 158 | 6 | 273704 | 182489 | 2251 | 221 | noob_Racer (SV) |
| 28 | 140 | 64 | 11 | 267 | 5 | 310653 | 172457 | 2208 | 245 | Steve (UK) |
| 81 | 390 | 92 | 9 | 283 | 9 | 185281 | 99399 | 2189 | 289 | corsica_nazione (FR) |
| 18 | 100 | 90 | 8 | 199 | 14 | 69127 | 34122 | 1955 | 354 | geum (US) |
| 10 | 115 | 57 | 10 | 165 | 7 | 143607 | 147821 | 1912 | 224 | Ripleye (FR) |
| 55 | 272 | 51 | 16 | 286 | 10 | 202632 | 272325 | 1879 | 536 | SaintHappening (US) |
| 74 | 359 | 65 | 11 | 212 | 11 | 76427.6 | 34252 | 1855 | 231 | ELECTRO (UK) |
| 17 | 169 | 80 | 7 | 144 | 3 | 37111 | 9921 | 1828 | 99 | NanoC (FR) |
| 72 | 281 | 59 | 7 | 203 | 5 | 84976.9 | 13924 | 1806 | 155 | Wirus.Win9x.DòóM (PL) |
| 9 | 49 | 43 | 8 | 199 | 8 | 103865 | 49282 | 1728 | 300 | Ragnar (BE) |
| 47 | 211 | 71 | 9 | 220 | 10 | 168998 | 97010 | 1644 | 252 | imonfire (UK) |
| 29 | 231 | 62 | 10 | 157 | 6 | 133069 | 33239 | 1524 | 225 | Herbal_Mint (CH) |
| 7 | 109 | 65 | 7 | 137 | 16 | 7523.32 | 2848 | 1510 | 375 | ICH (DE) |
| 44 | 150 | 42 | 11 | 157 | 23 | 98712 | 129141 | 1509 | 421 | wito (PL) |
| 7 | 64 | 57 | 8 | 149 | 5 | 146513 | 159511 | 1408 | 208 | Bluecat77 (US) |
| 98 | 631 | 65 | 11 | 166 | 21 | 128924 | 132161 | 1399 | 386 | cronix (HR) |
| 29 | 90 | 43 | 11 | 179 | 11 | 133469 | 27691 | 1393 | 143 | Ju5tIC3[RezQ] (FR) |
| 28 | 417 | 71 | 10 | 152 | 8 | 135487 | 61713 | 1361 | 297 | SA21 (UA) |
| 35 | 138 | 22 | 6 | 155 | 10 | 38791 | 59736 | 1353 | 182 | ChocolateChip (US) |
| 54 | 289 | 57 | 5 | 132 | 11 | 137068 | 71450 | 1345 | 207 | BarnBurner (IL) |
| 49 | 328 | 69 | 13 | 253 | 17 | 77012 | 53450 | 1326 | 320 | WïÜè (RO) |
| 64 | 232 | 50 | 4 | 149 | 2 | 64965.8 | 19601 | 1250 | 228 | Paul (RU) |
| 42 | 259 | 32 | 12 | 138 | 3 | 129429 | 49484 | 1239 | 96 | RonnieColeman (PT) |
+----------+-------+--------+-------+-----------+-----------+---------+-------------------+-------+----------+---------------------------+
But then...who stops the flag runners?
+----------+-------+--------+-------+-----------+-----------+---------+-------------------+-------+----------+---------------------------+
| Captures | Grabs | Covers | Seals | FlagKills | TeamKills | Points | TimePlayedMinutes | Frags | Suicides | EQName |
+----------+-------+--------+-------+-----------+-----------+---------+-------------------+-------+----------+---------------------------+
| 150 | 459 | 262 | 68 | 1166 | 31 | 557885 | 204407 | 6559 | 525 | Rounin_Napoli (IT) |
| 137 | 600 | 282 | 54 | 988 | 24 | 809857 | 323911 | 6506 | 564 | Kyhado (US) |
| 294 | 1091 | 248 | 29 | 786 | 31 | 304162 | 85618 | 5392 | 833 | MrHuhuhu (UK) |
| 101 | 963 | 162 | 29 | 775 | 26 | 273474 | 131565 | 5435 | 584 | Mr.Magoo (CL) |
| 261 | 578 | 207 | 24 | 706 | 10 | 244355 | 50168 | 6955 | 334 | moi (FR) |
| 214 | 550 | 234 | 35 | 661 | 22 | 323014 | 83929 | 5119 | 583 | {V][M}Quadro (BE) |
| 91 | 449 | 205 | 52 | 654 | 17 | 253291 | 92861 | 4429 | 522 | NONAME_StreetRat |
| 94 | 417 | 105 | 34 | 598 | 23 | 305515 | 120111 | 3437 | 437 | David (AT) |
| 19 | 195 | 125 | 33 | 560 | 18 | 428227 | 303433 | 5048 | 504 | ps (RO) |
| 151 | 386 | 103 | 27 | 461 | 8 | 377963 | 131677 | 2621 | 201 | Antonius (AT) |
| 40 | 192 | 76 | 32 | 396 | 4 | 134933 | 29655 | 2340 | 314 | Snoop (UA) |
| 144 | 768 | 128 | 17 | 389 | 29 | 196587 | 83511 | 3047 | 463 | KillaKilla (DE) |
| 184 | 741 | 207 | 32 | 388 | 21 | 91105.8 | 51683 | 4107 | 390 | HELL_FIRE_BACK (FR) |
| 43 | 169 | 114 | 28 | 385 | 13 | 116764 | 43910 | 3480 | 386 | memo (ES) |
| 63 | 395 | 150 | 28 | 377 | 20 | 107309 | 54466 | 3907 | 288 | gerbil (RO) |
| 68 | 474 | 126 | 25 | 358 | 20 | 258127 | 179126 | 3794 | 866 | -=BL@=- (PT) |
| 51 | 265 | 163 | 34 | 332 | 21 | 325321 | 165734 | 3643 | 366 | Flenser (US) |
| 110 | 500 | 104 | 12 | 312 | 11 | 276417 | 171044 | 2402 | 323 | DM4E/DRG (RU) |
| 134 | 592 | 93 | 15 | 302 | 18 | 239510 | 84987 | 2466 | 340 | Little_Johnny (IN) |
| 55 | 272 | 51 | 16 | 286 | 10 | 202632 | 272325 | 1879 | 536 | SaintHappening (US) |
| 81 | 390 | 92 | 9 | 283 | 9 | 185281 | 99399 | 2189 | 289 | corsica_nazione (FR) |
| 50 | 360 | 50 | 8 | 279 | 3 | 16920 | 5964 | 1149 | 147 | El_Gato (AR) |
| 15 | 44 | 118 | 25 | 268 | 14 | 30856 | 15253 | 2931 | 378 | DRAUGR (RU) |
| 28 | 140 | 64 | 11 | 267 | 5 | 310653 | 172457 | 2208 | 245 | Steve (UK) |
| 106 | 458 | 70 | 15 | 261 | 7 | 172427 | 34348 | 2356 | 386 | notthc (HU) |
| 20 | 307 | 139 | 20 | 254 | 25 | 237639 | 102666 | 3344 | 481 | NONAME_StreetRat |
| 49 | 328 | 69 | 13 | 253 | 17 | 77012 | 53450 | 1326 | 320 | WïÜè (RO) |
| 21 | 91 | 72 | 7 | 249 | 6 | 147998 | 133476 | 2709 | 256 | islander (RU) |
| 226 | 494 | 34 | 16 | 234 | 11 | 11993.3 | 3502 | 1143 | 262 | Mjolnir (US) |
| 47 | 211 | 71 | 9 | 220 | 10 | 168998 | 97010 | 1644 | 252 | imonfire (UK) |
| 74 | 359 | 65 | 11 | 212 | 11 | 76427.6 | 34252 | 1855 | 231 | ELECTRO (UK) |
| 72 | 281 | 59 | 7 | 203 | 5 | 84976.9 | 13924 | 1806 | 155 | Wirus.Win9x.DòóM (PL) |
| 18 | 100 | 90 | 8 | 199 | 14 | 69127 | 34122 | 1955 | 354 | geum (US) |
| 9 | 49 | 43 | 8 | 199 | 8 | 103865 | 49282 | 1728 | 300 | Ragnar (BE) |
| 61 | 364 | 96 | 10 | 194 | 4 | 214327 | 59814 | 2917 | 137 | Kuha (FI) |
| 23 | 48 | 77 | 15 | 190 | 16 | 165865 | 77555 | 2758 | 210 | Lòónät´iç (AR) |
| 7 | 21 | 30 | 14 | 188 | 8 | 35678 | 43717 | 953 | 159 | q(ô.ô)p (UK) |
| 71 | 207 | 44 | 9 | 185 | 7 | 188298 | 58428 | 1024 | 140 | BaZzY (NL) |
| 29 | 90 | 43 | 11 | 179 | 11 | 133469 | 27691 | 1393 | 143 | Ju5tIC3[RezQ] (FR) |
| 23 | 229 | 114 | 15 | 178 | 25 | 208659 | 87651 | 2621 | 333 | Russ (UK) |
| 98 | 631 | 65 | 11 | 166 | 21 | 128924 | 132161 | 1399 | 386 | cronix (HR) |
| 10 | 115 | 57 | 10 | 165 | 7 | 143607 | 147821 | 1912 | 224 | Ripleye (FR) |
| 14 | 77 | 61 | 16 | 158 | 6 | 273704 | 182489 | 2251 | 221 | noob_Racer (SV) |
| 44 | 150 | 42 | 11 | 157 | 23 | 98712 | 129141 | 1509 | 421 | wito (PL) |
| 29 | 231 | 62 | 10 | 157 | 6 | 133069 | 33239 | 1524 | 225 | Herbal_Mint (CH) |
| 35 | 138 | 22 | 6 | 155 | 10 | 38791 | 59736 | 1353 | 182 | ChocolateChip (US) |
| 14 | 63 | 7 | 2 | 153 | 1 | 1645 | 657 | 504 | 74 | Sabrah (FR) |
| 29 | 112 | 49 | 1 | 152 | 1 | 93847.2 | 48951 | 1117 | 108 | hahahahate (IT) |
| 28 | 417 | 71 | 10 | 152 | 8 | 135487 | 61713 | 1361 | 297 | SA21 (UA) |
| 7 | 64 | 57 | 8 | 149 | 5 | 146513 | 159511 | 1408 | 208 | Bluecat77 (US) |
| 64 | 232 | 50 | 4 | 149 | 2 | 64965.8 | 19601 | 1250 | 228 | Paul (RU) |
| 17 | 169 | 80 | 7 | 144 | 3 | 37111 | 9921 | 1828 | 99 | NanoC (FR) |
| 42 | 259 | 32 | 12 | 138 | 3 | 129429 | 49484 | 1239 | 96 | RonnieColeman (PT) |
| 63 | 458 | 51 | 5 | 138 | 9 | 64692.4 | 23610 | 1216 | 238 | ParadoX (BG) |
+----------+-------+--------+-------+-----------+-----------+---------+-------------------+-------+----------+---------------------------+
([Captures*2] + [Flagkills*2] + frags) / timeplayed
Excluding players with less than 40 captures
Or just Points/Timeplayed cuz the points are already programmed considering the important aspects of the game
This is the list: (points/timeplayed)
Wirus.Win9x.DòóM (PL)
JP (NL)
notthc (HU)
stefanie (FR)
moi (FR)
zath (FR)
Sup (BR)
{V][M}Quadro (BE)
duke (PL)
Kuha (FI)
MrHuhuhu (UK)
Mjolnir (US)
Paul (RU)
HYDRO (IR)
BaZzY (NL)
ThunderCrash (RS)
Antonius (AT)
El_Gato (AR)
tigger (UK)
Little_Johnny (IN)
ParadoX (BG)
Rounin_Napoli (IT)
NONAME_StreetRat
memo (ES)
RonnieColeman (PT)
David (AT)
Kyhado (US)
ScHiSmFeAr (US)
KillaKilla (DE)
-=BL@=- (PT)
ELECTRO (UK)
Mr.Magoo (CL)
MILEYCYRUS{.}{.} (SE)
gerbil (RO)
Flenser (US)
BarnBurner (IL)
corsica_nazione (FR)
Mike (SE)
HELL_FIRE_BACK (FR)
imonfire (UK)
DM4E/DRG (RU)
WïÜè (RO)
James.T.Kirk (AT)
cronix (HR)
wito (PL)
SaintHappening (US)
You made me proud Jp
Quote from: Piglet on October 14, 2021, 10:14
Saving stats for each game makes for a lot of data.
I was talking to a friend of mine who was a DB guy, back around 2000, about tracking some user actions, and whether it was too much data. He said, "what are we talking about, a few million rows? Yeah, that's what databases are good at. No problem." ;D
Quote from: Piglet on October 14, 2021, 10:14
You don't want to end up with all attackers on one team and all defenders on the other. There needs to be a "reasonable" mix of the attributes on each. My gut feel is that if you get the better cappers split between the teams, and then the better defenders split between the teams then you're well on the way.
This seems pretty complicated, or at least more complicated than Sup's "points per time". And again, anything has to be better than what we get now, which is half the games with ALL the great cappers AND defenders on the same team.
Despite my pretty-low rank in Sup's data crunch :'( it looks pretty damned good. I would be happy if the people in the top of the list were evenly distributed between the two teams.
Your position should be better Flenser, just as Jp's should be worse (no offense Jp love u <3). But it's a reference at least
The top 20 players on this list are able to change a game. If some of them play at the same time, they should be distributed among the teams.
The perfect balance is impossible, but if you avoid concentrating the top players on the same team 70% of the problems will be solved in a simple way.
I just think there are some players missing from this list, like Soma, Killer, Joustin, etc.
Quote from: JP on October 14, 2021, 15:00
(https://i.imgur.com/IcgUn6s.jpg)
In this game, for example, Soma and Kuha would probably have the best score/time rate. So the equalizer would put one on each team and the game would be balanced
Quote from: sup on October 14, 2021, 23:18
You made me proud Jp
I can rest in peace now.
Also, this;
Quote from: sup
Or just Points/Timeplayed cuz the points are already programmed considering the important aspects of the game
Assuming the points are already distributed properly during the most recent game, why bother doing additional historical hoopla on top of that.
I'm not even sure if time played should be a factor, given that good players are able to score many points in a short amount of time. So they should be treated like the top dog they are in the next game.
This also takes in account players having a bad day.
Quote from: sup on October 14, 2021, 23:14
([Captures*2] + [Flagkills*2] + frags) / timeplayed
Excluding players with less than 40 captures
Or just Points/Timeplayed cuz the points are already programmed considering the important aspects of the game
This is the list: (points/timeplayed)
Wirus.Win9x.DòóM (PL)
JP (NL)
notthc (HU)
stefanie (FR)
moi (FR)
zath (FR)
Sup (BR)
{V][M}Quadro (BE)
duke (PL)
Kuha (FI)
MrHuhuhu (UK)
Mjolnir (US)
Paul (RU)
HYDRO (IR)
BaZzY (NL)
ThunderCrash (RS)
Antonius (AT)
El_Gato (AR)
tigger (UK)
Little_Johnny (IN)
ParadoX (BG)
Rounin_Napoli (IT)
NONAME_StreetRat
memo (ES)
RonnieColeman (PT)
David (AT)
Kyhado (US)
ScHiSmFeAr (US)
KillaKilla (DE)
-=BL@=- (PT)
ELECTRO (UK)
Mr.Magoo (CL)
MILEYCYRUS{.}{.} (SE)
gerbil (RO)
Flenser (US)
BarnBurner (IL)
corsica_nazione (FR)
Mike (SE)
HELL_FIRE_BACK (FR)
imonfire (UK)
DM4E/DRG (RU)
WïÜè (RO)
James.T.Kirk (AT)
cronix (HR)
wito (PL)
SaintHappening (US)
You sure sup I am not on the list xD You made me proud :p
From the lack of comments on my propositions, I get that no one is interested in the ideas I sketched. Don't get me wrong, I'm still glad that something is done on the balancer front.
Still, not taking into account flag returns seems really strange. You know you can't score if your flag isn't on its post, gents.
Also, i do not think there was a real thought on points value - and certainly no discussion about it.
Quote from: Gil-galad[The REAL one] on October 15, 2021, 16:17
From the lack of comments on my propositions, I get that no one is interested in the ideas I sketched.
Still, not taking into account flag returns seems really strange. You know you can't score if your flag isn't on its post, gents.
Working on that!
Feel free to create relevant issues here https://github.com/ravimohan1991/Equalizer/issues
I will be having/continuing private dialogs with Piglet at relevant times and will be working on what I would like to believe the right collective consensus on how to proceed forwards.
One venue that I didn't explore is the time stamps.
The most obvious case I can think off is to measure the duration of a flag carrier role, to acknowledge the difficulty that can be simply just holding it when the enemy has your team's flag.
I suspect that some other durations could also be used to further improve all the ideas around distances that I tried to present.
Like the duration spent on the journey to the enemy's flag : some, like Darkside or TheEnder, can be VERY fast (running, no vehicle). Perhaps that could be a solution to measure and value these skills... or for that case, flag touches and flag captures counts would be enough...?
I'm not comprehensive at all here, it's just to show the possibilities.
More generally, I 'd really want to find objective values where it's possible instead of having a guess picking an approximate subjective value. I want to have a robust balance mechanism, not something that would prove to be too circumstantial and thus less efficient. Players will adapt their gameplay if the game changes, and we wish the balancer to stay the most pertinent and efficient that is possible nonetheless.
that' how i got thinking in terms of distances and flags.
ON the ELO mechanism that was discussed :
Quote from: Gil-galadFor 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.
I think it's the same thing. I'm very much in favour of such mechanism.
it is in line with this :
Quote from: Gil-galadThe 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. 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.
I was trying to address this concern :
Quote from: PigletIt's a tricky one. You're thinking in terms of flags all the time - however if you watch me in Bloodbath, my aim is to prevent players getting anywhere near the flag. I'm shooting the hordes of players attacking and trying to prevent them even getting there.
How are you going to measure the value of me killing 100 players before they reach the flag, compared to the sniper being nothing more than a nuisance shooting 100 people milling around the spawn points?
How are you going to measure the value of Moi shooting me and preventing me from defending?
I think the simple solution is usually the right one...
Look this game:
(https://i.imgur.com/p2JrPZV.jpg)
Nardaq, Sadly, lol and Kyhado at same team
Just by looking at this I know it's not balanced and the red team's points/time played ratio is much higher than that of the blue team
(this game was 5x1 for the red team quickly)
Since the beginning of this thread, I was introduced to an Assault balancer designed by really good players that intimately know ut2K4
(1), from that pick-up assault server that perhaps some of you will know.
HERE (https://ut2004.best/)for a link to their site. THERE (https://ut2004.best/ranking/) for the ranking.
The algorithm has been active for nearly a year now, I've been told. I did not play on that server recently, and I can't try it now. This server is the only active assault community that I know of.
On the the algorithm they use, that is based on the win rate percentage and an Elo ranking system :
Quote from: Small Assault community
Winning the game: +6
Every additional objective the team completed compared to the opposing team: +2
The resulting points will then be multiplied by the losing team's win chance.
As such, teams that are rated significantly higher than the opposing team won't earn many points from winning against lower rated teams, but will lose more points than usual when they lose against the lower rated team.
also New players will not be ranked immediately. They stay unranked for their first 10 games.
The points given for additional objectives are given to keep people engaged in the match until the end, even if one team has already lost.
This is a glorious day. I dreamt of an assault balancer for years. Now, if I could just get a working battle station... :D
You can hit Pablito on Discord if you want more on this balancer. Do read on their FAQ the content behind the line
how are players rated/ranked?(1)hwnd, rafi and zord
I like it Gil! We just need to translate that assault metric to (v)CTF terminology. Simple stuff really!
To translate the metric to vctf on this server, there's some important differences to consider :
Quote from: FAQGames will be played in 3vs3 and 4vs4 teams which makes the whole thing a lot more competitive than most public servers [...] The games will optimally not have any mid-game leavers or trolls. Everyone is supposed to play their best game
So, we have matches well over those player counts, and players that join and leave mid game. Piglet mentioned this earlier as a point to watch out since a balancer that would work for their server could well not work because of these differences.
What I'd try is to further fine tune this logic, by multiplying the ranking/rating points that this system would give you
- in full (by 1) if you played all the match
- in part only if you've only played a part of it. Like : if the game lasts 30 minutes, and you played only 10 minutes, the
ranking/rating points you would receive (winning or loosing) should be multiplied by 10/30 (
actually, only the +6 part of the points should be multiplied, since the rest would depend on specific actions done while partaking the match EDIT : not true if every player from the winning receive the same ranking points, like the algorithm used in Assault).
Like this, we could also very well take team switching into account, elaborating a bit more on the above, on top of weighting correctly the value of a partial match. We also have the rejoins to consider : the time played in a match should not be lost even if a player leaves and rejoins the server, or goes in spectator mode.
Just a small idea, and not sufficient of course to solve all this translation thing, but it's a step.
The way I ended up trying to translate their value :
If a win=6,
then one flag capture is worth 6/5, since we need 5 flag captures.
Let's cut that in half since you need to control the 2 flags in order to capture a flag, as an objective (?) way to value a full distance flag run or a full distance flag return, and we obtain 6/5/2=0,6 rating/ranking points for those actions : a full distance flag run with capture or a full distance run and flag return.
But since you have to travel often double the distance to capture a flag than to retrieve it, it would be more adequate to give to a flag capture relatively more points than the points given to a flag return. My estimate would be then be 6/5/3=0,4 for a full flag return, and 0,8 for a full flag capture, because of distances of travel.
The most correct way to find a value adapted for a given map map would be to weight the full maximum distance of a flag capture against the same for a flag return, and use the ratio to find the correct divisors to further break the 6/5 that were devised earlier, for the full distance flag capture and the full distance flag retrieval value in ranking/rating points. I proposed a way to measure those distances, - that can probably certainly be improved.
This idea has the following limitation in its conception :
It assumes all the value of the victory is in the flags management, while defending or supporting are in many cases amongst the key elements of what end up enabling the flag captures or the flag retrievals that lead to victory. So there's certainly room for improvement there.
We could probably lower the values again, if we could quantify the other roles/actions that are responsible for a victory.
Why would it be lower? Because the more roles you acknowledge and value, the more distributed the victory's value will be. Perhaps it's obvious that is the chosen logic here, but it's also better plainly written.
One obvious case that pops to mind is the manta/raptor taxying, scorp /bender taxi, ... : if driven or flown by someone, the full value one player on foot would receive would be divided by the number of occupants of the vehicle... or divided between just the driver and the flag carrier, so by 2. Or something better you'll come up with to distribute truthfully the value of the action.
One other option, much simpler :
Quote from: FAQThe rating points awarded to players are calculated as follows:
Points=6+2×(WinnerObjectiveCount−LoserObjectiveCount)
We could write it
Points=6+2x(WinnerfFlagCaptureCount−LoserFlagCaptureCount)
You could if you wanted to ignore everything but the number of caps each team got.
That ignores
The number of captures this player got (rather than some good teammate they played with)
The number of times they grabbed the flag
The number of times they helped the flag carrier
The number of times they returned the flag
The number of times they killed the enemy carrying the flag
The points they got
The frags they did
The times they were driving the flag carrier (this isn't currently tracked)
etc...
I know. I've got plenty of counts that I'm not considering, but...
Has it been tried?
And has it been tried with the time count correction like I pointed out earlier, to at least avoid some of the noise of the midgame joins/quits/spectates/rejoins/switches?
I'm really curious.
If it's very simple, perhaps it could be tried and trained a bit on some recorded match results. If the algorithm really sort out players efficiently, it should at least be efficient to rank the regular players, no?
I think what Gil has found is an abstraction for right translation to vCTF gametype. It is my work to now project/map it to the current state of Equalizer abstraction for robust(?) concreteness (you know with relevant partitions for various gaugable actions 8)). I should come up with something this weekend!
At the risk of freaking you guys I am inscribing the pdf here
https://digital.lib.washington.edu/researchworks/handle/1773/22797?show=full
I am interested in gauging the non linear effects. That is, using meta analysis to generate more meta (which is community driven!).
Let me know how it feels :D
I've tried to read it, but I'm no mathematician and know nothing of game design.
I wonder what you think of the TrueSkill method over Elo. From what I read, it seems to fit better, and it doesn't seem so different than Elo. Since it adds a certainty/uncertainty value to the prediction. If i got that right.
It says this that I found interesting :
Quote from: Alexander Benjamin Jaffe, p. 118 :TrueSkill aims to generalize Elo to games with teams of more than one player, and potentially more than two teams.
That is our case, and we could even argue that it would apparently fit better VCTF4.
For those who would rather NOT read anything of that document :
Quote from: Alexander Benjamin JaffeIt is a Bayesian method which models each player's skill not by a single value, but by a normal distribution of belief. Players are assigned a mean and a variance for their skill. As players win and lose games these beliefs are updated. Wins and losses shift a player's mean skill up and down; outcomes consistent with predictions decrease variance (increase confidence), whereas inconsistent outcomes increase variance
Still have to read the thing again. And to be clear, I have no idea if this would be complicated or hard to implement to our case.
EDIT : it seems there is a
TrueSkill 2, that explicitly "support matches with any number of teams and any number of players on each teams". And it supports players quitting and joining, is very light on the server... it really seems worth it to me.
If you have enough data for every player for every single match, you could actually create some statistics to help you rate skills and contribution to victory.
win rate % for each map for this player
win rate % for this player when in the same team with X,Y,Z player
win rate % for this player when playing against X,Y,Z player
"Flag cap rate per minute" on wins
"Flag cap rate per minute" on defeats
"Average time between flag caps" for this player
"Minimum average time between flag caps" for this player (95th percentile)
"Average time between flag caps" when playing with player X,Y,Z
"Minimum average time between flag caps" for this player (95th percentile) when playing with player X,Y,Z
"Returns per minute" on wins
"Returns per minute" on defeats
"Maximum average returns" for this player(95th percentile)
"Maximum average returns" for this player(95th percentile) when playing with player X,Y,Z
KDR on wins
KDR on wins with player X,Y,Z
I could go on forever.
To achieve team balance you need to keep win rate percentages close to 50% for each team.
Comparing 2 players with base statistics like win rate %, flag caps per minute they might be very close.
You proceed to the next metric "average time between flag caps" which will probably follow "flag caps per minute" in most cases, so that could be a draw too
But then you reach "minimum average time between flag caps"
Player1 has a top 5% of 20seconds while player2 has a top 5% of 40seconds, that means that while both may have the same average skills, player1 has a higher skill ceiling than player2
Although i don't think you would have to reach that deep to balance, you can probably balance teams based on winning percentages of team compositions alone.
You can also try going the other route, placing players that are evenly matched when playing against each other on alternate teams.
So complicated.
The more criteria you add, the more players can game the system.
If holding the flag is "good", then you get players taking the flag and hiding forever. Remember when Cybershock and his buddies would take the flag and then hide in a tree, because being jerks was funny?
Just put in a simple balancer based on player's scores and see how it does. Over-engineering is probably a waste of time, and possibly counter-productive.
I still hold the view that the stats being logged are what we need, and that we should try to spread out the key skills between the teams.
I'm just not sure how you do the calculation to do that spread of skills to get about the same amount of capping/defense/fragging skill on each team
After reading that paper, and then some, I get what Flenser says.
Still, I do not think using the scores is the right solution, because 1. scores are biased and/or simplified representations of skills and 2. the points on vctf could certainly be improved, imo.
Perhaps I got it all wrong since the beginning, and parsimony in criterias choice will do better, all the more in the long run, since it doesn't presume on what gameplay / dynamics will prove to be successful, thus allowing a broader way to achieve victory, and more diverse matches. Only victory truly decides. If it works. Less is more?
On the TrueSkill 2 diagram as seen on the paper I shared (p. 11), it seems that they only consider the kill rate, the death rate, and win or loss to guess the balance and player distribution. Oh, and the duration of the match and time played on the match.
Here the github of a package (https://github.com/EbTech/Elo-MMR) "containing implementations of several rating systems for multi-player competitions: all-pairs Glicko, all-pairs BAR, Codeforces, TopCoder, TrueSkill-SPb, and the new system Elo-MMR". Alas, I didn't find any shared example of a TrueSkill 2 implementation.
All Good! I have started reading the literature and I came up with and idea:
"What if at the end of each game, during mapvote say, we ask for the feedback from all players, essentially if they feel the game they played was balanced?"
Quote from: The_Cowboy on October 30, 2021, 13:59
All Good! I have started reading the literature and I came up with and idea:
"What if at the end of each game, during mapvote say, we ask for the feedback from all players, essentially if they feel the game they played was balanced?"
People will vote anything just for fun. Trust me
Like I said, the simplest and most efficient solution is points/time played
Look this game right now:
(https://i.imgur.com/Z1p55Ba.jpg)
The best ranked players in this game are:
Paul (RU)
Little_Johnny (IN)
Rounin_Napoli (IT)
Kyhado (US)
-=BL@=- (PT)
HELL_FIRE_BACK (FR)
If they were together in the same team the game would last 2 minutes
Coincidentally they were separated 3 for each side, creating a balance (at least acceptable)
I had a look at all the stats captured to date and tried various things. The points/hour average is pretty accurate in spotting the better players.
Duke was the exception. He caps a lot but his scores aren't that high.
Quote from: Piglet on October 30, 2021, 19:09
I had a look at all the stats captured to date and tried various things. The points/hour average is pretty accurate in spotting the better players.
Duke was the exception. He caps a lot but his scores aren't that high.
Yes, I tried a lot of complex formulas too in excel and points/time played was the most realistic based on what I know of player skills.
There are some exceptions, for example Mjolnir. He often plays alone, so he has a high number of caps in easy games, distorting his position a little bit.
Duke never defends, I believe this should make him have a lower score
But, anyway, it's the most accurate way I've found to assess player skills.
The negative points I thought are:
-Skilled new players will take a certain amount of time to be ranked
-Need to track the players by IP (if some player changes his name it doesn't change the balancing system)
-When you have a lot of good players (especially with odd number) it will be difficult to determine which ones should be on each team (but, as I said, separating the good players is already an acceptable balance)
Ok, sounds reasonable. All I need now is to find a graceful way to switch player teams when balance is, you know, disturbed 8)
Could be a 4 second timer notifying about switching action to the individuals, IDK!
Using scores for balance will work for 70-80% of players, add flag caps statistics, that can account for a remaining 10%, but it only works if all games are equal.
The balancer should only work when teams become unbalanced by more than ~10% anyway.
Before enabling any balancer, you should rate players based on data gathered.
That rating needs weighted averages.
In order to pick how each statistic should be weighted, firstly we need to discard data gathered for games with few players(8 players or less) or extreme games(26+).
For each player pick stats from complete games - at least 90% of the map's total duration.
Then, pick 2-3 known top players and compare them to known good or average players, a good way to weight scores compared to flag caps, returns, kills, deaths etc..
Then probably weigh the score rate at 60%, then the next important metric at 20%, then divide the remaining stats equally.
Finally make the balancer use that rating, on every map add/subtract rates.
Hold up, i just invented ELO ranking
COMPLETELY UNEXPECTED, WHAT A SURPRISE
Who needs a balancer? :D ??? :'(
(https://www.dropbox.com/s/8y01d4bl9vdnpm9/balance.png)
https://www.dropbox.com/s/8y01d4bl9vdnpm9/balance.png
If you thought that was bad you should have seen the map before that. Bloodbath, with me on defence and justice and nard on attack,..
sorry did not read the whole chat (So sorry if this sounds totally off). Just thought about api access to gametracker? I thought that site ranks all players? Why not just use that ranking for balancing?
https://www.gametracker.com/server_info/80.4.151.145:7777/top_players/
Yup that should work too. Well, if you don't care about specificity and just the grand total.
It's been really nice actually speaking with players via the Discord voice channels.
Kuha has brought up the fact that I never complain about balance when my team is winning, and after discussing it with Gil, here are my thoughts.
When playing on a winning team, I'm able to get close to the flag, or make kills, or recover the flag, use vehicles, generally play the game.
When playing against a vastly better team, I spawn and die within seconds, one or more enemy raptor is overhead killing everyone and every vehicle, the base is completely overrun, and I'm sniped way before I can get near the enemy base. That's when I think "what's going on?" and look at the teams, to see Gil, moi, Kuha, Justice, Quadro, Piglet and every other top-ranked player on the opposite team. That's when I wish we had a balancer in place.
I believe second phase is complete and perfectly working. In the third phase, I am exhausted/disgusted and/or no longer willing to write team switching code.
Well unless there is some more systemic theological incentive 8) :P
Quote from: sup on October 14, 2021, 23:14
([Captures*2] + [Flagkills*2] + frags) / timeplayed
Excluding players with less than 40 captures
Or just Points/Timeplayed cuz the points are already programmed considering the important aspects of the game
I believe it is time we start tinkering, pondering, and coming up with formulas like this for utilising the complete potential of Equalizer.
BTW Phase III is in action, as you may have noted in other thread (or first hand experience on the server).
I've been monitoring the server following the start of map balancing code going active.
What I've seen is that the highest scoring players are split between the teams. As coded the highest scoring player is on red. The next two most high scoring players are on blue, then all the way down the scoring rate it's one to red and next highest scoring player to blue.
There are two problems with this strategy.
1. High scoring doesn't mean more likely to win. I'm looking at loon when I say that some people get higher scores that probably were a lot of fun... but may not have been particularly helpful to their team...
2. People join and leave at quite a rate at the start of a map. That can throw out the teams. Some people try to get to play together... Which messes up the teams.
For issue 1:
To do a better job of initial balance we'd need to define what a balanced team looks like and how to construct one. That is really hard! I'm pretty good in defence. If I'm defending more of the team can attack. If Duke is attacking with someone covering his back more people can defend. If loon is pissing off the other team by sniping then and they stop playing the game then I can run in and grab the flag despite not being a great capper. Each player has a different style. A perfect balancer would understand those factors and pick two groups that are as near the same as can be done. I suspect this is impossible!
I expect that pph is actually pretty effective.
For issue 2:
Hmm how much to intervene? My gut feel is 'as little as possible'. The old mute code currently active keeps the team numbers aligned as it used to. I'm going to add one more check to it to ensure it doesn't swap the flag carrier... but more than that will take a lot of thought
An how it manage players who join mid-game ? The previous equalizer places the "new" player in losing team (team score) if there is no bot.
The current code places new players in the team with the lower player count, then the losing team if numbers are equal, or if equal and same score then it's randomly assigned
Quote from: Piglet on January 31, 2022, 12:10
but more than that will take a lot of thought
(https://i.imgur.com/fMLUFSU.png)
Ok, was thinking if we were to even consider ELO rating, should that be done PHP side or UScript side?
The contrast be as follows
PHP Side: Global
UScript Side: Contextual
Ok a note of caution: some players seem unhappy with balancer(?). Well I can understand the resentment to play with full concentration instead of just gliding by, by having extremely strong team. But cursing balancer is not going to help anyone.
If you have any problem with it, write in the forums HOW? And then, if your intellect allows you to give suggestion, post it on forums.
Again, blaming balancer is redundant and useless!
I'm still seeing the announcement text and announcement sound telling the wrong team at the start of the map. I can't see any obvious reason for that.
No clue about that mate! Messages are sent from server, so everyone should get same message category. Quadro has verified it several times and I can post hell's video
https://youtu.be/ZsUX3p1mFc0?t=1277
you can witness yourself!
Quote from: The_Cowboy on March 11, 2022, 13:15
No clue about that mate! Messages are sent from server, so everyone should get same message category. Quadro has verified it several times and I can post hell's video
https://youtu.be/ZsUX3p1mFc0?t=1277
you can witness yourself!
My favorite part of the video O:-) ... A little background music :)
https://drive.google.com/file/d/15q_cDezPy8lbLcGA8yfExUUgQvQ5xJAZ/view?usp=drivesdk
;)
Alright so here are the large statistics of all the players (well players with more than 1 hour of gameplay)
http://stats.miasma.rocks/EqualizerBE/SuperDuperLargeStatisticsInformation.html
(http://stats.miasma.rocks/EqualizerBE/SuperDuperLargeStatisticsInformation.html)
The reason I am posting this is two-fold
1. There be transparency in what we are doing and, so, no scope for monkey business!
2. Smart players can make correct predictions in which team they gonna be playing.
Please Note:
1. I will be posting these statistics only once (until required/necessary in future)
2. This is only a static snapshot of database (March 12, 2022) and no sensitive information is present
Now that we have that out of the way, you may have fun viewing the UI.
You may visit
https://www.gametracker.com/server_info/80.4.151.145:7777/top_players/
(https://www.gametracker.com/server_info/80.4.151.145:7777/top_players/)
and compute PPH manually and compare + contrast with the above statistics. Let me know if there is discrepancy.
I tested moi's PPH and almost same! 8)
Why does my name come up 4 times and quadro only 1 time? Can u guys pls just give the list form best to worst player. I want to know if im in the top 10 or how close to top 10.
1. Because quadro is coherent player and you are not!
2. Saint happening is the best and I am the worst. Figure out your place somewhere in between! :D
3. Even without sorting up the tables, I can tell you have more than 60% chances of being in top 10, 30% chances of being in top 5.
Here's the data my app collected over the past couple of weeks.
EDITED:
I found the other thread on "Some data on balancing" and put the info in there.
Johny is second best by PPH
Makes sense
Well if you leave out Hydro (index 361 and the likes) from your list, sure!
Anywho, all the PPHs of players with time <120 minutes are fake. I forgot to take the division by decimal into account (given Indians were the ones to invent decimals in a SENSE and teach that to Arabs). Thanks for that sup!
what did hydro do to you?
Wow this conversation is going in the direction I didn't imagine.
Basic counting principle (along with context recognition) will tell you that if you weed out the upper members in a list, you can elevate yourselves in this context of incompleteness list generation. You may have momentarily satisfaction but that won't last long.
tell me easier? I don't understand English well
i like your balancer
Quote from: Paul on April 20, 2022, 07:01
tell me easier? I don't understand English well
He just tries to turn every simple answer into something complex to look smart, I think it's Narcissistic personality disorder but i'm not sure
I love you too. Just hoping some day you learn to talk without bringing in blame-game and name-calling.
Quote from: The_Cowboy on April 20, 2022, 12:49
I love you too. Just hoping some day you learn to talk without bringing in blame-game and name-calling.
I only name-calling you once. And that was extremely accurate btw
But sorry, I don't want to disturb the thread where you talk about the only thing that keeps you from getting banned from the server and makes you feel like an unbeatable god (NPD)
:*
Get a room you two! Sounds like you need some private time together.
I never claimed to be a god (in the forums or discord). I have never even reached godlike on multiplayer game. So whatever.
I'd like a private time with Joker (Heath) if not too much to ask 8)
Godlike nahhh...HellLike?? Now always remember , it is better to be horny (will add horns to my youtube ) than godlike :P
So no piglet, these two horn-y players won't get a room together. How can the god's enjoy the forum if everyone is in rooms :D
.
Meow
(https://i.imgur.com/HLcF0l9.png)
(https://c.tenor.com/3G2_pgxT4bUAAAAM/stay-cool-nail-file.gif)
That mayyybe true!