Building a New Simulator

There has been a hiatus on tourneygeek in the reporting of simulator results. That’s because I’m comprehensively rebuilding the program, trying to eliminate some of the shortcuts and assumptions that were embodied in earlier versions. This is going to take some time, as it involves my learning a new language – an object-oriented one.

This post will describe some of the basic structure and flow I’m developing for the new simulator.

(Note, please, that all of this is tentative. I haven’t actually built any of this – I’m still learning the language, and I’ve yet to run it by an expert I’ve retained to teach me object-oriented programming and help me get this stuff off the ground more quickly.)

The basic flow of the simulator is this:

1. Set up the structural elements that define the format.
2. Initialize global variables (like the luck factor and the elite threshold).
3. For each iteration of the simulation:
   1. Complete the setup with elements that vary from one iteration to another;
   2. Run each individual match;
   3. Associate, as needed, the results of the entire iteration with individual matches;
   4. Tally the cumulative statistics for the iteration.
4. Report out the results.

The structural elements of the format are contained in a class, where each instance represents a match. Here are the data elements that go to make up that structure:

• MatchOrdinal: an integer that identifies the match, and specifies the order in which they are to be processed.
• MatchIdentifier: a string that give a human-friendly name to the match, e.g. “B7” for the seventh match in the B round of a typical bracketed tournament.
  • This element is not needed to run the simulation, but will make the reports easier to understand.
• TopSeed, BottomSeed: an integer that guides the initial filling of the line.
  This will be zero if the line is to be filled by a result. If the seed number is greater than the number of entries, the match will be processed as a bye.
  • I’m using the Top/Bottom distinction because it will help me keep things straight in bracketed tournaments, where one line is in the top and the other on the bottom. But even in unbracketed tournaments, it might be useful to keep track of the distinction. For example, Top/Bottom could mean White/Black for a chess tournament, of Home/Away for many other kinds of events.
  • This is an important structural element even for blind-draw tournaments – the randomization for blind draws takes place by mapping the random draw onto the static seeds, which makes it possible to do partial seeding, and to keep byes in their assigned places.
• TopWinTo, TopLoseTo, BottomWinTo, BottomLoseTo: pointers that direct where the players to as a result of the match.
  • In my earlier simulators, I simply had WinTo and LoseTo vectors, as most bracketed tournaments don’t distinguish between the two. But there are a number of exceptions. The most familiar is probably the contingent second match in a double-elimination, played only if the survivor of the losers bracket wins the first match against the survivor of the winners bracket. But contingent matches are also featured in many of the more exotic formats I’ve looked at, including those from Joe Czapski’s tournamentdesign.org, and the Big, Peculiar Bracket.
• TopWinMoney, TopLoseMoney, BottomWinMoney, BottomLoseMoney: double precision numbers that give the reward (not necessarily monetary) for each result.
  • Again, these would usually be the same for Top and Bottom, but they’ll vary in many of the same circumstances n which the WinTo and LoseTo pointers vary.
  • These would usually be zero except for the matches that determine a player’s final outcome. But many important tennis tournaments include money for winning each individual round, and presumably there are similar arrangements in other events.

The elements that belong not to the format structure but to each individual iteration will be introduced in the next post in this series.