[gblake]

Like Jesse, I too have written a scheduling program. I took the brute force & heuristics approach. It wasn't too hard even for someone like me who does software work mostly as a hobby. Mine was for 2-team matches because I was focused on FVC (FTC/VRC) at the time.

Truth in advertising - The heuristics still need to be tweaked to avoid getting "trapped" by early arbitrary choices that force a bad choice later; but the overall results are pretty good.

A couple of points to make:

1) I have written this before, but it bears repeating; there is no such thing as a scheduling algorithm that is simply "fair". Algorithms are only fair in some "sense(s)". In conversations like this thread, if you don't pair the word "fair" with a description of the sense(s) in which you are using it, the conversation falls apart.

When the word is used you have to clarify whether you mean fair in the sense of putting all teams at each of the red and blue alliance station positions evenly, or do you mean fair in the sense of ignoring the expected skill level of their allies, or do you mean fair in the sense of attempting to give each alliance a similar expectation of winning each match, or...

In this and many other contexts, I recommend banishing the word "fair" from your vocabulary if it isn't paired up with more information.

2) I remain surprised that the scheduling algorithms at STEM robotics tournaments aren't drawn from open source descriptions and code. The scheduling problem isn't that hard. Tournament organizers (either at a worldwide HQ level or at local levels) should choose the heuristics they want to employ, proudly announce them, pluck a tried-and-true implementation off the shelf, and then get on with the rest of the season.

In the scenario I outlined above, folks (participants) could certainly suggest different heuristic choices (and certainly would), but once the choices are made, there shouldn't be any mystery about them or about how they are implemented.

Blake