Tournament Directing Software Requirements

    Keywords: Tournament, Software

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:

moved an ensuing discussion to Tournament Directing Software Platform Discussion

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


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:

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 [ext] http://www.britgo.org/organisers/oldhandbook.html#s11.

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. [ext] 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 [ext] 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

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

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.

Policy gets injected by the TD in several places:

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


Links


This is a copy of the living page "Tournament Directing Software Requirements" at Sensei's Library.
(OC) 2004 the Authors, published under the OpenContent License V1.0.
[Welcome to Sensei's Library!]
StartingPoints
ReferenceSection
About