PUG autodraft program?

You know, drafting for PUGS takes so damn long, and people dread to do it so much that additional time is wasted just because people would rather sit and talk than start the process.  Then there's deciding who the captains are gonna be (not me!  not me!  etc.) which takes up even more time, yadda yadda.  It occurred to me that I could sit down and write a program that would automatically choose the teams "fairly," based on the records you input.  I could kick out the program in a day if people thought it would be useful, and would use it.

The way I envision it working at this point would be, you hit windows key while in-game to go to desktop, you run the program and enter the player records on a line.  Then it comes back with teams.  For instance, if you are going by number of games played, for 3v3 you might enter 50 300 24 14 0 98.  Then the program would come back with team numbers 1 1 2 1 2 2.  Actually, that outcome is a little stacked, but all I did was flip a coin for the player with 300 wins and the player with 98 wins.  The 300-win player won so he got to choose first, and he chose the 50 win guy.  This is what would happen in real-life as well.

I could even envision using several different algorithms to balance out the teams, depending on what you want to do.  One is the way I just did it, which simulates how actual PUGS are drafted currently.  Another way might be to try to add up the total number of wins on each side to match them up as evenly as possible, which could result in 2 1 2 1 1 2.

Anyway, if anyone would find this useful, and would actually use this to draft PUGs, post here.  If enough people want it, I'll write it.

17,692 views 13 replies
Reply #1 Top

Yeah, that actually is a pretty good idea...  Just make the program decide based on number of games and percentage lost.  So from there you could divide the total by the number of losses, getting a value which you would would be larger for consistent winners and smaller for losers and those who don't play often.

Then, you set aside the two highest scores and ask the computer whether or not the next one added to team captain 2 would be large enough to overcome team captain 1.  If so, captain 2 gets the third best player.  If not, then captain 2 still gets the player, but then receives the next best player (ranked #4).  

If Captain 1 is higher than all of team 2, then captain 1 receives the lowest rated player.  If not, he receives the next highest player (ranked 5).

From there, it is a simple difference engine where you go down the line of skill until the end.

 

I am honestly surprised that there is nothing of this sort already in the game...

Reply #2 Top

Great idea agent.

I only see three potential problems.

1) Number input: In a big 5v5 you've got 10 players numbers to input, I suppose if you wanted you could write them all down before minimizing, but I see a potential problem for people who dont have a pen and paper handy, having to minimize and maximize repeatedly to input numbers. That could get a little cumbersome for some, and for me, well, my computer doesn't quite like repeatedly minimizing and maximizing Sins and tends to crash it if I put to much strain on it (just me, but maybe a few others too).

2) The previous aside, there's also the problem of SMURFS! While your system would work fine for secret smurfs (ie ones you dont KNOW are smurfs) it could create a problem with those who are Obviously smurfs, or known smurfs. Your program would have problems adjusting for this and people would certainly cry foul if teams were stacked with smurfs, creating longer delays and kinda defeating the whole purpose of streamlining the pug process with a program.

3) The third problem is getting players to accept the results. While it may not be a huge issue, I've noted that people don't often like the teams as they are picked by a single person, even if the teams seem fair. The whole pug process allows everyone to be involved in the decision making, leading to players being more comfortable with the results even if teams are a bit stacked.

Sorry to be such a naysayer, just trying to point out potential snags. I'd certainly use the program as much as I could if you made it.

It would help with the smurf problem I think if you did Games played to win ratio, or at least for players with less than 100 games played. (More than that you can expect skewed ratios based on older versions of the game and all the bugs associated with them) That way someone with 10 games played and 9 wins is rated much higher than someone with 30 games played and 16 wins.

Eitherway I think a program could give game hosts a general idea of the teams even though they may need to make an adjustment or two to adjust to noobs and smurfs.

Reply #3 Top

2) The previous aside, there's also the problem of SMURFS! While your system would work fine for secret smurfs (ie ones you dont KNOW are smurfs) it could create a problem with those who are Obviously smurfs, or known smurfs. Your program would have problems adjusting for this and people would certainly cry foul if teams were stacked with smurfs....
End of quote

Are you saying that with a known smurf, the pug captain doesn't just look at the record of the smurf when he drafts, rather he mentally inserts his real (non-smurf) record, or an estimate of it?  I guess the solution there is to insert the real record or estimate into the program.  Use the same number the drafter or drafters would use for the guy.

Thanks for the algorithm ideas, Volt.  I say the program should have several different algorithms for the host to choose from.  Yours could be one of them.

If there are more people interested in this, could those people post algorithm ideas here?  A simple one is doing it like pugs are done today - just flip a coin to see who gets first pick, and then have each captain draft the highest ranked player he can.  A more sophisticated version would give the program the ability to defer his first pick if he can benefit by doing so.  Then there is my idea to add up all the scores on each side and try to balance teams as fairly as possible that way.  Then there are Volt's ideas.  Anybody else have a scheme?

Reply #4 Top

I got bored during a blank period during school today, so I wrote up some data for an example of my previous idea and what would happen.  I put in a wide range of skill sets from a player with 9 games, to a simulation of JJ.  This featured 8 players for a 4v4.

The result was that one team had a skill rating of about 9700 while the other was about 6000.  The thing is though, almost all of the 9700 is JJ, and he can only expand so quickly.  Because of the way this system works, while he is the best, he is also stuck with the two worst players, which means that while he will win his individual, his allies could lose, which means that he will be outnumbered later in the game.  That means that his supreme rule over the game would be neutralized by superior numbers.

I'll post a screenshot of the spreadsheet I used to figure this out with later.

Also, another thing I was thinking about earlier, but didn't have time to post would be one that deals with Diplo specifically.  It requires input of the player's race as well as the above factors.  This is designed to account for the effect of pacts.  The reason for this is that by pact swapping, the TEC can increase the fleet capacity of all its allies by up to 40%.  The same principle can apply to other pacts.  Some pacts are just flat out awesome. 

For this reason, the computer would have to estimate any players with similar skill ratings (within 10% of each other) as identical to begin with.  It would then take into account their race and would attempt to fill both teams with equal amounts of the races so that one side doesn't dominate the other by being TEC, Vasari, and Advent while the other is just one or two races.

In either case, it would be nice if this sort of thing would work inside Sins itself.  That way, all players would have easy access to it and would be more convenient as it could easily pull data from their profiles.  It could also allow balancing of teams when players use random races so the game could know which race to place the player as.

Reply #5 Top

Much of this could be solved if the pugs were organized on Internet Relay Chat (IRC) with a good pugbot.  The pug channel could be set up so that you cannot join the channel unless you are logged in to the server under your player name and there could be penalties for smurfing (1 week ban, etc.).  A good pug bot keeps track of where players get drafted and can choose random captains after a set amount of time if no one captains up.  The random captains are chosen in an attempt to match up players who are drafted at about the same spot in every draft (player with a draft rating of 2 vs. one with a rating of 2.5).

It would make the player draft a little smoother but it' not going to happen.  I've tried to get people to come to IRC before.  If we were really serious about it there would also be a voice comm server players would join where they then divide into separate team channels.  This is how it works for Unreal Tournament capture-the-flag pugs.

Reply #6 Top

Okay, I actually have an alpha version working.  I've run a few test cases, and it seems to work well with those.

The algorithm I use is this (my own custom):

1) Add up all player records (number of games played) and divide by 2.  This represents the theoretical "midpoint score" you would want both teams to have, ideally.  For example, say you are doing a 2v2.  Say the number of games played is 50, 100, 100, and 50.  The total is 300.  Divided by 2, that's 150.  So you'd want to make teams who's sum total records are as close to 150 as possible.

2) Generate a matrix of ALL POSSIBLE TEAMS, and add up all their records.

3) Grab all team configurations who's records are equally close to the "midpoint score" which was calculated earlier, and present them as solutions.

Here is the program output for the above "toy" example:

pug 50 100 100 50

1 1 2 2
1 2 1 2
2 1 2 1
2 2 1 1

Another "toy" example:

pug 100 200 300 400 500 600

1 2 1 2 2 1
1 2 2 1 1 2
1 2 2 1 2 1
2 1 1 2 1 2
2 1 1 2 2 1
2 1 2 1 1 2

A more realistic looking example (this wasn't contrived - I literally just threw some numbers down off the top of my head):

pug 78 34 56 233 366 500

1 2 1 2 2 1
2 1 2 1 1 2

If you add up the scores for those teams, you get 633 and 634.  The program was trying to balance around the theoretical midpoint of 633.5, and it nailed it.  It found 2 solutions out of all possible solutions which are closest to 633.5.  Since both of those solutions are equally close to 633.5, it presented them both.

Any interest out there to develop this further?

Reply #7 Top

That's actually a pretty good system.  Perhaps you could use that system combined with my idea for achieving a skill rating by dividing the total number of games by the percent lost.  That way, the computer would know that someone who has won 18/20 games is likely better than someone who has played 35, but lost half of them.

 

Honestly, I hadn't even thought of a matrix as I was thinking of conventional team picking methods, but that would be almost perfect.  But the biggest problems are:

  1. Smurfs
  2. Inconvenience
  3. The Ultra good players (with super high play counts)

1 and 2 were explained earlier, but three is also important.  The super good players out there such as JJ would simply get paired up with the worst people in the PUG without a doubt, unless you also had Amish, Tyr, Vasari, etc in there.  They would get paired up with the weakest allies.  Sure, in a 2v2, this probably wouldn't be bad as any of them could take two enemies (and in some cases three enemies), but there comes a point that you simply do not have the fleet capacity to push back against enemy waves totaling to 6000 FC.  So the elite players would end up with all enemies against them after their allies were crushed.

 

The key here to remember is that a skill value is likely not going to influence all aspects of the game.  Anyone with +/- 15% of your skill value has a pretty good shot at beating you or losing to you.  So, really the only time it matters is in 1v1s at the beginning.  If outside that tolerable range, one will be a nearly guaranteed victor.  From there, a player will gobble up his enemy's planets and then turn to the next target.  This means that even with a perfect balance of players, the map will still choose the winner.  If the worst person on one team is pitted against the best of the other, then the latter player's team will likely win.  That player will defeat his enemy quickly and then move against his next target with twice the empire, economy, and military that he had previously.  That means that he suddenly has the ability to slam his opponents more quickly than they can attack his allies.

 

I don't really know what to do about that as that is just a random number generator.  I guess we can't really do anything in that regard.  The computer will choose who it picks, and we have to live with those decisions.  The above case would be rare, so I guess its not too much of an issue unless the devs hand over the code for choosing who gets assigned to what planet...

Reply #8 Top

As far as 1 goes, you'll have the smurf problem whether you pug normally, or pug with a program.  If you know who the smurf is, you could use a number that is closer to his real record.

As far as 2 goes (inconvenience), I actually tested this in a couple of real pug games tonight.  As soon as all the bickering started as far as "who's gonna cap?" and "pick a number!" and "let's just do tvb" blah blah, I grabbed my cell phone, entered all the player records into it, spawned out, loaded up my program, entered the data, ran it, and came back.  They were still bickering, and hadn't even started drafting yet, and I already had results.  This was for both games I tested with.  Basically, it is more convienent and faster to just spawn out and run my program than sit there for 20 minutes talking.

As far as 3 goes, yeah a super-high ranked player may get paired with bad allies.  I'm not necessarily sure this is a bad thing.  But one thing you could do is just cap a guy's record down somewhat if it's just ridiculous.  Like if there is a JJ with 1000 games, and an Agent of Kharma as next-highest with 500, you might want to call JJ 700.  The program would also work if you just called anyone with 100-200 games a 1, 200-300 a 2, etc.  There are lot of ways to input the data, the program will work regardless.

We can't really do anything about these other aspects you mention (map variations, etc), nor should we.  We just want a "fair" pug program that is as fair or fairer than a bunch of people picking teams, and more convenient.  I can write the program, I already have a working alpha version.  I can include other algorithms besides the one I created.  At the end of the day, I'm just doing this out of the goodness of my own heart.  If people show interest I'll make it available.  If they don't, they can just keep pugging the way they are doing it now.

Reply #9 Top

1. Yeah, I know, I'm just saying...

2. I don't really play PUGs, so I had no idea that this took so long...  So, I guess that any time it would take would be even less than normal..

3. Yeah, some cap might be in order.  Perhaps cut it off at 5000 or so...  Beyond that, everyone ought to know you are freaking awesome...  In my simulation, JJ had about 8800, so...

Example

By the way, here is the example I made earlier...  You can can see how it calculated skill level on the left and how it arranged teams on the right.  I suggest we combine the skill calculation with a cap of ~5000 and your matrix system.  That way, the computer will yield extremely balanced teams.

Reply #10 Top

Nice spreadsheet work.

You and Deceiver (I believe it was him) have both suggested using wins/losses ratios in the calculation.  Frankly, I don't care either way, but just so you guys know, most pros that I know don't do that.  They say the wins/losses don't count, because there can be minidumps, disconnects, map fucks, and about a million other things to make that data unreliable.  They just look at pure numbers of games played.  The rationale is, if you've played a ton of games, you're probably good.  If you haven't, you probably aren't.

Having said that, like I said, I really don't care either way.  I'll program in whatever people want.

I'm willing to make the program utilize several different methods to generate the pug.  That way, you can just choose whatever option you want.  Something like:

1) Standard (basically how it is done now)

2) Agent of Kharma style

3) Volt_Cruelerz style

4) other...

What does everyone think?  We really need more comments from the pug players out there who would use this.

REQUEST FOR INFO:

I've done these things a million times, but I'm too bored to pay attention.  Can someone tell me EXACTLY how these pugs are drafted currently?  The information I want is how many picks the captains get on each turn.  I think that for 5v5 it's 1 2 2 2 2 1... right?  Is it ALWAYS done that way?  And what about for games with less players?  How is it done?

Reply #11 Top

Fair enough...  That does make sense then.  Perhaps ask the player a group of questions so that it knows which mode to use.  For instance, you could have a question ask, "Are there any veteran players in this game?"  If the player answers yes, you just go with games.  If not, you go with the ratio.

Also, make sure to have a line of code in there if you do mine that prevents someone without any games from causing a divide by zero error.  I'm sure you'd find it, but I was thinking through it and found it, so I figured I'd post it.

 

And since I don't play pugs, I don't know for sure, but I remember elementary games where that was the system we used (I was always picked last so I had time to wait around and listen).

Reply #12 Top

Well, weirdly enough, there seems to be no interest in this from anyone.  I would think people would be beating down my door to get their hands on a program like this.  Go figure.

I did code up the "standard" pug where you just flip a coin, choose whether to defer or not, etc, and it works fine... but I guess since so one seems interested....

Reply #13 Top

Perhaps try reviving this thread during the summer when more people are on...