Cowboy Coding at the Indy Open

A few weeks ago I decided that I was in too much of a rush to get my Tau ready for Adepticon much less even earlier for the Indy Open.  I still wanted to be involved, so I let Spag know that if he needed any help running the tournament my services where available.  I thought I would end up helping judge, building terrain, or playing as the ringer.  Of course, I ended up as keeper of the spreadsheet.

It started when Spag emailed me asking if I had a laptop.  I told him I didn't have one, but I did have Numbers on my iPad.  After explaining to him what that meant, I had him email me the Excel spreadsheet he had created for managing the tournament.   Luckily the only thing that didn't load into Numbers was Microsoft's default font.  What I didn't think about at the time was that there was no scripting in the spreadsheet to generate parings, or to output ordered rankings.  That realization was an unfortunate "Oh Sh*t" moment.  Especially since the stripped down version of numbers available in iOS doesn't support scripting.  I certainly didn't want to do pairings for a 64 person tournament by hand.  Especially since I was also going to be the designated ringer.

I've been planning on getting a new laptop for a while.  I've also been wanting to learn Objective C programming since mobile development has become an increasingly demanded skill these last few years.  I had settled on buying a Mac Book Pro in April. Ostensibly as a present to my wife because she's letting me go to Adepticon on her birthday weekend.  So I dropped by the Apple Store in Castleton the weekend before last and finally pulled the trigger.

Spag left it up to me on how to pair up the players, so I set about writing a script to handle just that.  I mostly program windows desktop apps and web apps, so I wasn't familiar with Apple's AppleScript or Objective C languages yet.  I have used a little Ruby before, and Ruby has interpreters for OS X.  It even ships with one installed, but I had to be a geek and go pull down the latest and greatest.

Last Wednesday night I spent a few hours coding up a script to perform the pairings.  It could read in a CSV export of the spreadsheet and generate a random pairing in the first round or pairings based off of win/loss record and battle-points for any other round.   It was not my most elegant coding work, but it was good enough to get the job done.

I was all ready to go Saturday morning.  After getting the spreadsheet updated for last minute additions and no-shows, my script spit out the first round pairings without a hitch.   Second round was where things started to go off the rails.   I had made the assumption that I would not have to worry about players playing each other more than once.  Since the tournament was strait winners vs winners, you couldn't have a looser come back and play someone who beat them.  That would be true if there where an even number of winners after each round in the tournament.   Otherwise you need at least one winner to play a looser.  In this case, it's a possibility that the one winner who has to play a looser could play a person he already beat.   So we needed to do a few manual player swaps to overcome this in a few rounds.

The next hurdle had to do with ever changing requirements.  I had written my matcher to not just operate off of the number of wins, but the order of wins. So only a person with a 'wlw' would only play someone else with a 'wlw', not just a 2 and 1 player versus another 2 and 1 player.  I didn't know when I wrote the script that Spags wanted to put everyone with the same number of wins in individual brackets on the second day.  I had to update my script to try and pair all the people with the same relative records together. This was easy enough; I changed my script to count wins instead of match a concatenated string of 'w's and 'l's.  This gave me a list that was ordered close enough to the individual brackets that Spag wanted.  Some people got bummed up to higher brackets to make sure that we only had one bracket with an uneven amount of players. I had to do much more player swapping as we ended with many more players playing former opponents.

My script couldn't have been changed so easily to do the 6th round pairings.  I needed to pair players who had been placed into the 4-1 bracket with other players in the same 4-1 bracket.  I was the ringer the fifth round, and didn't have time to write a new script.  I had to do the final round's pairing by hand.  Fleshy humans are not very efficient at that sort of thing.

Luckily, we had a player drop from the final round. This freed me up to add a method to my script.  It could now crunch the numbers one last time and generate the final results.  I ordered by record and then by overall score for the bracket prizes, and then just by overall score to get the RenMan winner.

It would be nice if there was some tournament software out there that could tackle some of the issues that we faced.  You need to use something other than spreadsheets to handle the complexity and variations on player pairing in larger tournaments.  A more purpose oriented user interface would also help prevent data entry errors, and could automatically sanity check results.  I believe Battlefront has something for running FoW tournaments, but I think its tailored to their style of tournament play.  I would like to see something that was generic and could also leverage mobile devices.   Tournament software that could be distributed and allow any tournament staff member with an iPad or iPhone to enter results or painting scores would be very cool.  It would be a cool project to work on, but a lot of effort for something that would only potentially be used by 2 or 3 events in a year.