Let's talk about PPR! PPR Changes on Freon 1

[Piglet]

That's certainly doable, and makes a lot of sense. It takes me a few rounds to get up to speed. If it used my initial PPR rather than something closer to my average to assign teams that wouldn't be right for long.

I'll have a think... Maybe make it configurable

I upped the percentage to 30% yesterday to see how it worked... I'll find a screenshot showing how it worked last night when holy spam and wife were both playing really well

[holyspam]

Like i said it makes no sense to have the PPR shown be anything other than (your_points/rounds_played), visually PPR should remain as is.
Now it's just weird, first few rounds i get 10 points with 15 ppr, then round 10+ i get 100 points and 8 ppr

The balancer does need a change. Average PPR is useful for the initial balance, but someone might play much better or worse depending on a lot of factors. A static percentage doesnt help, when you're under/overperforming.

The downside with using more of current PPR is that anyone over/underperforming will probably be switched or swapped.
Forcing everyone to play near their average by bringing good players down and bad players up, making the game much more competitive for all players.

Using a dynamic weight for current_PPR based on Played_rounds is much better.
First round/Initial balance will always use (1 x AVG_PPR) for balancing.

The 3SPN formula is
BALANCER_PPR = (A x AVG_PPR + B x CUR_PPR)
Where A + B always equals 1, for every player, round and game.

Using this instead:

Code: [Select]

Lerp( FClamp( Played_Rounds / RToBal , 0, AutoBalanceCurPPRWeightMax/100 ), PRI.AvgPPR, PPR )we can ensure that teams will be balanced depending on each player's current PPR up to AutoBalanceCurPPRWeightMax %, after "RToBal" rounds passed

Now you get perfectly balanced teams (as all things should be, let's call this Thanos!!)

[Piglet]

In your example, you only get 15ppr showing if you get those 10 points in early in the round, the round doesn't go to overtime and  you don't score any points towards the end of round.

Look again at the problem I posed with the old current PPR:

a) if you scored 10 points in the first round and another 10 points to the point of overtime in the second round then the old calculation would show you a PPR of 20, while my calculation would show a PPR of 10

b) if you scored 10 points in the first round and another 5 points at 60 seconds into the second round then the old calculation could show you with a PPR of 15, while my new calculation would show a PPR of 10

Of course, my calculation assumes that the current round will go to overtime: if the second round ended at 60 seconds in then my calculation would immediately drop your PPR from 10 to 15/2 = 7.5 at the start of the next round - and if you didn't score any points over the round your PPR would start to slowly drop as the round went on, until at the end of the round you would have a PPR of 15/3 = 5. The old calculation could leave you at 7.5 all the way through to the start of the 4th round....and at the that point would reset you to 5 PPR. You'd be balanced by the old balancer logic as if you were playing at 20 when you were actually playing at 10, or 7.5 when you were actually playing at 5 PPR. My version uses the more accurate numbers.

The assumption that rounds last until overtime affects all players equally.

In practice most rounds reach overtime or close to overtime so the calculations are pretty sensible. This is a snapshot part way through a high scoring map. The bot is playing badly - and has reduced PPR. The players are playing above their average PPR (due to the map) the ones who are doing particularly well are showing that the balancer considers them to be the better players. The better they are playing "now" the more the average PPR is raised:

The downside with using more of current PPR is that anyone over/underperforming will probably be switched or swapped.

The balancer aims to swap players to get as close to the same average team PPR as it can. The times I saw it swap yesterday it picked exactly the right player to fill the gap. Once it was you! I don't think there is any correlation between playing better or worse and being picked for the swap. It doesn't know whether you're playing better or worse at the point of choosing. It's just working with the numbers in the last column (well - not exactly as it doesn't take current PPR into account until you've played at least 24 seconds).

[holyspam]

PPR = points per round
New_PPR = points per 120seconds

[Piglet]

PPR = points per round
New_PPR = points per 120seconds

No. It the new calculation assumes only that the current round will last 120 seconds.

Old PPR is:

a. "Points scored so far", when in round 1
b. "The total of (all points scored in round 1 and all points scored so far in round 2)", when in round 2
c. In round 3 onwards "(The total of all points scored, including the ones scored so far in this round) divided by (one less than the round number you're in).

(Yes, I know b and c are the same calculation - but the impact is greater in round 2).

New PPR is:

Your total points in the game / (number of rounds played + "the proportion (up to a whole round) of this round played assuming that the current round will last 120 seconds")

[holyspam]

PPR = points per round
New_PPR = points per 120seconds

No. It the new calculation assumes only that the current round will last 120 seconds.

Old PPR is:

a. "Points scored so far", when in round 1
b. "The total of (all points scored in round 1 and all points scored so far in round 2)", when in round 2
c. In round 3 onwards "(The total of all points scored, including the ones scored so far in this round) divided by (one less than the round number you're in).

(Yes, I know b and c are the same calculation - but the impact is greater in round 2).

New PPR is:

Your total points in the game / (number of rounds played + "the proportion (up to a whole round) of this round played assuming that the current round will last 120 seconds")

So if i get 70 score in round 1 but the round lasts 240 seconds, my PPR is still 70 right?
it changes nothing for twice the duration just for partial rounds.
So it's points per 120 seconds with an asterisk, where overtime is not included.
My ppr after a 30 second first round becomes 10 score divided by 30/120 = 10/0.25 = 25 New_PPR
So when we have overtime it should drop but it doesnt.
So it's not Points per round, it's not points per 120 seconds, it's something arbitrary that has no meaning

[Piglet]

I think you need to read my posts above a little more carefully.

[hagis]

there is another area in balancer that is flawed (or could be better)

The balancer aims to swap players to get as close to the same average team PPR as it can.

yeah and for match starts - especially on a full server it works fairly well

where it breaks and is very noticeable is mid or late joining "A" players, say match is 7 players Vs 8 players,. new A player joins in the slot available (balancer is called automatically for players over avgPPR 6)

what happens is it doesn't do the same balancing as it would at match start,. the team the A player joined they typically aren't switched - so you can end up with multiple A players on that same side

I added in some randomness on the balancer option to help shake things up when clearly things aren't right

need to look at the balancing code again because it has an idea of 'sticky players'

what it should do (it might already do some of this but I'm not sure)

increase likelihood for switching players who joined - so the more round you played the less chance of being switched (I mean the reason the call the balancer mid-game after player joins is because they are on the wrong side)


the other thing,.. the balancer doesn't care about the score,. it's trying to make the PPRs equal,. however - the reason you call the balancer mid game is generally because either an A or B player joined on the wrong side or it's very obvious one side is like 5 rounds ahead

How about make the balancer care about the score in some situations,.,

example idea (perhaps this is overly complicated!)

step 1 - if the PPR difference between teams is less then 1 PPR (if PPRs are more than 1 do the normal balance for PPR/avgPPR)
step 2 - look at the scoreline - if the scoreline is more than 3 different then switch a midPPR / C player on leading side with a lowPPR / C player on trailing side

(if the scoreline is within 3 difference just do the normal PPR balance stuff)

[holyspam]

I think you need to read my posts above a little more carefully.

I think you need to join ingame and see what's displayed.

[Piglet]

I think you need to read my posts above a little more carefully.

I think you need to join ingame and see what's displayed.

I have done - and not seen anything odd, except for where the numbers are inflated (for everyone) where the first round ends before 120 seconds.

Other than the example above, detail another example of where you see a problem worse than the old code which reported up to double the actual PPR and was only updated once a round.

You said "The downside with using more of current PPR is that anyone over/underperforming will probably be switched or swapped." - which isn't true, so I'm genuinely interested in the issue you see that actually exists.

[Piglet]

there is another area in balancer that is flawed (or could be better)

Yeah - I've not made changes to the balancer itself in this revision. What I've done is make the values it use more accurate when current PPR is included in the mix.  Rather than using current PPR which includes all of this round's score, but not the fact that this round is being played I've included this round's score estimated to what you would get if you carried on scoring at that rate to overtime.

Hmmm...while I was typing that I had a thought. We could get round Holyspam's concerns by totally ignoring all points from the current round:

In round 1, show score as PPR (and use AVE PPR in balancing in place of current PPR as there isn't enough data to say what PPR people will be playing at)
In round 2 onwards show PPR = average score in all completed rounds so far. (Start to use that in balancer after n rounds...where n>0)

That might be better, and removes the need to make any assumptions about how long a round would go on.

need to look at the balancing code again because it has an idea of 'sticky players'

Sticky player code isn't actually used. It's there in the code. It's meant to work - but it doesn't. I fixed the bug in it a while back and it was rubbish. It meant that players weren't swapped more than once in a game - leading to the wrong player being picked to balance. I backed out the fix and left it how it was!

[Piglet]

I'm going to try the stategy in orange above.

That removes the problem in trying to work out how far through the round you are. Instead, just ignore the current round.

Old code includes the score from the current round, but still divides by the number of whole rounds which have been completed.

This orange strategy updates current PPR once a round, but based on whole rounds and only on points that have been scored in those rounds.

[Piglet]

Yeah. That works. I'm happier with that. Removes the old problem without introducing a new one.

[Piglet]

need to look at the balancing code again because it has an idea of 'sticky players'

The code I think you're talking about is in Team_GameBase->FindBestAutoBalanceCandidate():

Code: [Select]

  // move player that closest matches the required PPR gap / number of players needed
  for(C=Level.ControllerList; C!=None; C=C.NextController)
  {
   
    // Skip players who are on the don't switch list.
//Note: (Piglet) This is the code as I found it. Surely the "continue" on this iterator has no effect!
    for(i=0; i<DontAutoBalanceList.Length; ++i) {
      if(DontAutoBalanceList[i] == C)
        continue;
    }

  ....more stuff around checking the player and seeing if they are the "right one" to move...
  }

The problem with that code is that it's pointless. It doesn't work. The "continue" just tells the code to skip to the next item in the DontAutoBalanceList and not the next controller in the ControllerList.

To make it work as intended this is the code I tried and then commented back out as it meant that a worse player was selected for swapping:

Code: [Select]

...same stuff...


  // Skip players who are on the don't switch list. Note:(Piglet) Made this change to make the code work, but the players hated it. The 'wrong' player was swapped leaving the teams unbalanced. Reverting to investigate further some time.
    for(i=0; i<DontAutoBalanceList.Length; ++i) {
      if(DontAutoBalanceList[i] == C)
        break;
    }
if(i<DontAutoBalanceList.Length)
continue;



...same stuff...



[holyspam]

Players are sorted by their PPR for balancing, not sure about dontautobalancelist, so if you do for i=3 it will skip the 3 highest pprs, in the balancelist
I think it would be better to remove all the balance code from 3spn and split that on a standalone mutator, but i have no idea how mutators hook with each other, maybe a standalone class.