Tournament Directing Software Requirements

Bignose: If you had your druthers, as a Tournament Director, what would be the specification of a program that would assist you in running the tournament?

I have my own set of goals:

• Be implemented entirely with free software. (This goal wasn't on this list originally, because I considered it so fundamental that I had forgotten to make it explicit.)

• Support Go tournaments, but abstract the specifics of Go into a special case so the program can potentially handle other games as well (with their own special cases).

• Support different match pairings and tournament structures, again as specific cases of a general tournament direction functionality.

• Be portable across platforms; I'll be writing for the GNU/Linux platform but I will choose tools that can allow the program to run on Windows and Mac also.

moved an ensuing discussion to Tournament Directing Software Platform Discussion

• Lots of user feedback on functionality and user interface during the design and development, so people aren't limping along with barely-alpha-quality software and horrible interfaces at a real tournament.

Please describe your ideal tournament directing program (within limits of current technology; no AI-complete specifications please :-)

• JohnAspinall: Separate the engine from the (G)UI as much as possible. While this is usually good software engineering practice (clarify the protocol between the two, allow testing the engine against a test-harness interface), I suggest it as a goal for sociological reasons as well: it makes it easier for an alternate engine to compete under the same interface, or for an alternate interface to be prototyped by someone who doesn't want to understand the engine. (Consider as an analogy, the development of alternate window managers for the Gnome desktop, or the use of CGoban as both SGI reader, and server interface.)

• JohnAspinall: Pay attention to robustness in the face of real tournament conditions and constraints. Late arrivals, early departures, ejections for bad behavior -- all the things that give Tournament Directors nightmares. The program has to contribute to solving the problem -- making it easier for the TD to "refactor" the tournament on the fly. (Added later: In a way that the TD decides; we don't get to decide what the TD's policy is.)

Robustness of process

Bignose: Here and elsewhere I've seen people express the desire that tournament directing software allow for, shall we say, "procedure deviations" in the actual tournament events. How, then, do people actually want the software to handle events like the following:

• Player arrives after the supposed cut-off time for the tournament, perhaps after the pairings are made and the match has begun

• Player leaves the tournament partway through, which may be known at the time or may be discovered later

Zarlan: Well that is very simple. No need to wonder what you should do.
Loss by forfeit.

JohnAspinall No No No. That decision should be made by the tournament director. If you write software that enforces your idea of tournament policy, then you will only narrow your prospective set of users. I have no problem with a TD who enforces a forfeit; I have a big problem with software that enforces it, against the wishes of a TD. (Analogy: What do you suppose would happen to the market for MS Word in Britain, should Microsoft decide to enforce American spelling only?)

Bignose: And how should it affect the subsequent rounds? Do people get paired against that player and get an automatic win? Does one person get a bye every round thereafter? What happens to the score for that player? What happens to the score for the player's opponents in previous rounds? (If anyone can point me to tournament-system discussions in this level of detail elsewhere, please do!)

Zarlan: Well my suggestion was simply to keep the pairing and counting the absent player's games as losses, because he didn't show up. That does give the opponents free wins. In an elimination style tournament, then that's no problem. If that isn't the case then it might be a bit unfair but... what if you count it as a loss for the absent player, but don't count it at all for the opponent. That is let the game have no effect the opponent's score. I don't see any need in changeing the pairing, just skip the games that won't be played so that the only thing the do is lessen the absent player's score.

Does anyone know somewere with a lot of info on tournaments and different tournament types? I like to be knowledgeable and this one of the kind of things where I like to know everything (When I played magic I read every word of the 4:th and 5:th rulebook and I think, if I remember correctly, I found a page with tournament rules or something. Didn't read that though as everybody quit playing and with no opponent...).

Charles There's some oldish material at http://www.britgo.org/organisers/oldhandbook.html#s11.

• Players report a result but their match was not the correct pairing

Zarlan: Well one could just say that they lose through forfeit as well. Depending on how serious it is and how much they are to blame for playing the wrong person versus how much you are to blame for them not knowing, a different solution might be preferable. In a round-robin it shouldn't be hard to fix.

Do look at some other software. I have run several tournaments using Godraw by Geoff Kaniuk. http://www.britgo.org/gopcres/gopcres1.html#godraw, and Goeff himself runs the London Open, the biggest tournament in the UK.

Despite being only a DOS program, it has a very well designed UI. (Although, of course, it coule be implemented better these days on a more modern OS, still it works well and is reliable, so why break it?) One of the best bits is the interface for entering results.

Anyway, Godraw comes with a manual, and reading that manual (and perhaps even running a fake tournament with Godraw) would show you a lot of the issues that you need to consider.

Tim.

Bignose: Reading the manual for other programs is an excellent suggestion, thanks very much.

Christoph Gerlach: And take a look at my Program MacMahon - The Program, which has the most complete features and fullfills all requirements stated on this page except it only runs on Windows and it is not Open Source (only Freeware). For those who can read German I also recommend my thesis which is discussing requirements for a pairing program as well. My thesis is PDF, here is the direct link.

Bignose: As shown by previous questions, I'd love to be pointed to existing material on how to adjust the tournament results (past rounds, current round and future rounds) when "outside-the-system" events occur. There is a fair amount of how tournament systems should work, but not much on what should be done when the real world intervenes.

JohnAspinall: At the risk of repeating myself, what should be done is whatever the TD wants. You cannot make your customers' decisions for them. If you do that, you are writing the program for a user base of 1 - yourself. Releasing it under a freeware license is just vanity.

JohnAspinall: Here's a positive suggestion instead. Your users form a population of TDs. There's the mean and nasty TD, and the sweet and kind TD. There's even the schizophrenic TD, who can't be counted on to maintain a consistent policy. They're all different. But they all perform certain basic actions as TD. They register players, with info like entering rank. They organize a set of games into a round. They accumulate results from those games. (Results are members of a fairly small set: say win_for_W, win_for_B, draw, forfeit, board_exploded, whatever....) The TDs take a set of game results and generate a new round of pairings. The first task here is to design this dataflow. If you do it right, I think, most of the policy decisions will turn out to amount to plugging different processing "modules" into the dataflow, and then you can let the user do the plugging.

Bignose: Alright, I've been phrasing this question badly, as I now see from JohnAspinall's comments. I'll try again: When real-world deviations from ideal procedure occur, what does the TD want the program to be able to do in the course of correcting the problem? "Anything", or "Let me change any data", is not a useful response; the program must (a) have some default behaviour in all cases, and (b) be designed explicitly to allow certain things to be changed in certain ways.

So, what specific things to TDs find themselves needing to change, or envision themselves wanting to change, in response to a problem during the course of the tournament? JA is correct in saying that the program shouldn't enforce policy. But if it is to allow differing policies, it is far better to know this in advance rather than retro-fitting it. It is also necessary to determine what a useful default policy would be in such cases; "give up and ask the TD to intervene" is surely not the optimal solution for all problems.

JohnAspinall: Excellent; I think we are in agreement here, and since I've opened my big mouth, I should take a shot at Bignose's questions above. His point about needing a reasonable default in all cases is a key point.

I think the central operation in what I called "the dataflow" is

• given previous results in the tournament, generate a new round of pairings. Let's call a module that performs this task new_round.

The default behavior (when all is going well), when the TD pushes the "New Round" button, is

• program checks that all games of previous round have a result entered against them,

• and, those results are all something that new_round can handle,

• then a new round of pairings is emitted.

Let's conjure up some user-scenarios for when all is not going well.

Scenario 1

AbsentMindedTD: New Round.

Program: You haven't entered a result for Tanaka(3k)-Smith(4k) from the previous round. Do you want to enter a result for that game?

AbsentMindedTD: Oops, they haven't finished yet. Cancel.

Scenario 2

Player Xue has to leave the tournament in the middle of a game. We assume that the TD has entered B_win_by_forfeit in the game.

TD: New Round.

Program: Xue(1d)-Lee(1d) had a forfeit. Is player Xue(1d) going to continue in the next round?

TD: No.

Program: Is player Lee(1d) going to continue in the next round?

TD: Yes.

Scenario 3

Players Dopey and Grumpy get in a fight. In the ensuing melee, another board, where players Sleepy and Bashful are playing, is overturned, and neither player (Sleepy or Bashful) can restore the board from memory. TD ejects Dopey and Grumpy, but wants to allow innocent bystanders Sleepy and Bashful to stay.

TD: New Round

Program: You haven't entered a result for Grumpy(29k)-Dopey(30k) from the previous round. Do you want to enter a result for that game?

TD: Yes. Selects "Double Loss by Forfeit."

Program: Is player Grumpy(29k) going to continue in the next round?

TD: No.

Program: Is player Dopey(30k) going to continue in the next round?

TD: No.

Program: You haven't entered a result for Sleepy(26k)-Bashful(26k) from the previous round. Do you want to enter a result for that game?

TD: Yes. Selects "Draw."

(Note - not being a forfeit, the program doesn't ask about whether Sleepy or Bashful are going to stay.)

Key points.

• All modules that perform the role of new_round insist on having some result entered for each game of the previous round.

• All modules handle common results (win_for_W, win_for_B, possibly draw) without user intervention.

• When a game result requires user intervention (e.g. the forfeits above) the module queries its "policy settings" and then, if necessary, the TD. The goal of the queries is to establish who is playing in the next round, and what the tournament history of each player is.

Policy gets injected by the TD in several places:

• Options to new_round determine which non-standard game results will cause a user query, ejection, etc. The TD who wants to micromanage, sets all non-standard results to query. The mean and nasty TD sets all forfeits to eject both players. And so on.

• The choice of which non-standard game result to use for a particular game is up to the TD.

This is all less-than-half-baked; feel free to critique, edit, modify.

Links

• Go Pair