Against Tournament Software

On Mon, Oct 25, 2010 at 10:55 PM, Tom wrote:

Tom

--- On Tue, 10/26/10, Kim wrote:


From: Kim
Subject: Re: draw brackets 
To: Tom
Cc: Alan, Terrence
Date: Tuesday, October 26, 2010, 3:19 PM 

Nice work. This solves 2 problems. There are no duplicate boxes because it is only a half matrix, and there is a clear way to record the score of each game. My only suggestion would be to leave out the "PLACE" section or put it in the grayed out "For Tournament Director" section (obviously not on this ASCII version). This is because in the case of 3 or 4 way ties (or apparent ties), the control desk will not just accept what the players write in, but will figure it out themselves according to the proper rules. Along these lines, we need have the resolution rules posted, and at least a few people understand them clearly. We got tripped up on both days due to partial defaults.

Kim

On Tue, Oct 26, 2010 at 5:03 PM, Terrence wrote:

I suggest we take a serious look into getting some software that could handle the following tasks:

...

-----Original Message-----
From: Tom
Sent: Wednesday, October 27, 2010 10:45 PM
To: Terrence, Alan
Subject: Re: draw brackets

Sorry for this being so long.

I've studied zermelo and another system or two and also put some effort into sw development in this area in the past.

Zermelo did not allow RR groups larger than 4, so it was useless in our area where RR groups of 5 and more are not only common but also preferred. It may have changed since, check it out.

Several kinks have made me no fan of the natural approach of a software developer to the problem of tournaments, namely, building and deploying software to solve it. What if your printer doesn't work? What if it *suddenly* doesn't work? What if it's not used to printing out 40 copies of match.card.txt and runs out of ink or breaks because it's not actually a high-volume printer with plenty of toner left in it today? Well, in that case, then, you'd be up a creek and you have to back off to the manual approach anyway. On the other hand, the ease and near-perfection of a (relatively) low-tech solution make me a fan of what we actually did. So allow me to describe the one-sort spreadsheet solution I more or less followed. See (1)-(10) below.

(1) Send out applications, receive applications.

(2) On Tournament Day minus 3, enter most of the applications, then on Tournament Day minus 1, enter the rest of them, into a spreadsheet which contains the following columns (optimized for display on paper for use during tournament day):

• "Name" (not first name, separately last name, no. Just Name, and write it how you like. Noone needs to sort on last name or on first name alone because if you want to get to the player's record you can go find it based on whatever the sort is already, rating or whatever name is available, because you have both names available when searching. Extra columns is extra pointless work and we have no time for that.)
• "Contact-Best Way" (not separately phone, cell phone, address, email, etc. in separate columns, No. Just a single field with the best way to reach the person, which is normally either an email address or a phone number. Then you don't waste screen space on unnecessary extra stuff. Remember you can go back to the papers in emergencies and access everything. I recommend that tournament application forms should include a checkmark for "Best Way" for entrants to indicate their preferred way of being contacted, then you can enter that one here.)
• "Rating". I write a zero before ratings lower than 1000, so that an alphabetic sort will have the same result as a numeric sort. 0500 is lower than 1500 but 500 is higher than 1500 in an alphabetic sort. If the person gives an estimate, use it, but mark it with a "?" afterwards so it can sort (now alphabetically not numerically, because it has a non-number in the string). For example, 0800? means Estimated Rating of 800 while 1804 means confirmed USATT or CTTA rating of 1804. If no rating is given, check the WA state USATT ratings list and you will often find it. If a USATT rating is given, check the state USATT ratings list to confirm the given rating. If the person is truly unrated, give them a fake rating. I have written that garage players are seldom above USATT 800, so an optimistic fake rating for an unknown player who has none would be around 800. I have also noticed that garage players who are kids are generally significantly lower, so a reasonable fake rating for such a player might be around 600. Finally, if there are a lot of such players, be sure to give them slightly different ratings around that target number, so that a ratings based sort can use that fake rating to put them somewhere in a playing order or a pre-event ranking order for the event. Ranking unrated players in the order of their application being entered is equally as rational as any other method, so go ahead: 0801?, 0802?, 0803?, 0804?, etc. Even though the rating is fake, it is useful because it helps make the later processes that depend on rating sorts to operate normally and smoothly. Noone complains because it is all equally arbitrary and complimentary, and everything works fine. This could be made into a big issue, but I recommend minimizing it by following the above procedure: give unrated players a fake rating.
• $. This is the amount the player should pay in total.
• Pd. This is the amount the player has paid so far. Note that when one player pays for another (e.g., in a doubles event where that's their only event), $ is equal for both players but Pd is double for the one who paid and zero for the one who didn't. Then you the spreadsheet user can look at the names and tell what is going on. It would take a fancy program not to raise an alarm when a player hasn't paid, this is why it's fine to use low-technology and human knowledge to make it easy.
• Next are columns for each of the events. Do not order them rationally, order them according to whatever order in which they are listed on the tournament application form, so that you can enter them into the spreadsheet in the order a person helping you can easily read them to you. If a person entered an event, put a Y in that spot. If you want to reserve them a place in case they might enter it, put an M in that spot. If they didn't enter it, leave it blank.
• After each doubles event column, put a column named "with" in which the doubles partner's name is typed in. Now you know what the partners are.

Okay, so much for your database. Created very quickly without special software development, and it does everything you care about.

Here's what you care about:

(3) A sort of the list based on the player's names. This is used to soothe players and control desk people for example to check the player is entered in an event if you don't have the event list or the player's rating either of which will answer the question and both of which are normally immediately available. But people like a name sort. Oh, for checking in, yes, that is the primary thing I believe. So go ahead make one and print it, keep it at the registration desk, and move on to the other thing you care about:

(4) A sort of the list based on ratings. This is the primary tool for running everything.

(5) For each event you run through the whole list looking for marks in that event's column, and you copy those onto a separate sheet for that event. You can do this in spreadsheet software somehow but I'm just as happy to do it in pencil. It takes about 4 minute to write down 20 names which is a decent sized event. Anyway, for each event, create that list This is a sublist of the whole list and since you sorted the whole list by rating, the sublist is also, automatically, sorted by rating.

(6) Next, for each event, decide your format: how many round robin groups (I like to have four in a group, 5 is fine, I STRONGLY DISLIKE an RR with only 3 players because it makes players feel cheated -- certainly that's how I have felt, and often someone doesn't show anyway, and then you're really cheated, noone wants that). Decide how many come out of the Round Robin -- people feel a lot better if it is two than if it is one and the cost to the tournament schedule of allowing that is only 4 (or N if there are N groups) additional matches for that event, typically insignificant. I never do double elimination in the next phase, they got their chance in the RR to lose one but still come out.

(7) Next, the draw itself: write A, B, C, D, etc., next to each player's name in the event list so you know what RR group they will be part of. This is the moment of doing the draw. Writing each RR group letter in sequence, A, B, C ,D ,D ,C, B, A is the way I sort players into their RR groups, this makes life easiest in the RR group for the top-rated player.

(8) Next, create match scorecards by copying the names for each group onto the scorecard. Scorecards are either RR or SE (Round Robin or Single Elimination). Four RR4's and one SE4 will run a 16-person RR event with one player advancing. Four RR5's and one SE8 will run a 20 person RR event with two players advancing. (See tomveatch.com/tt/RR4.txt and tomveatch.com/tt/RR5.txt.) One SE8 will run a single elimination doubles event with 5 pairs registered. Just put the players that come to an SE level on the form in order of ratings, and let the tree take care of the rest.

(9) Alan Lee said it's good to have a file folder for each event to keep the event's paperwork together and let one person be in charge of the event separately from another event. This has proved useful. Into that folder goes the event's player list, the RR scorecards and an uncompleted SE bracket if it's an RR event, or a completed SE bracket if it is an SE event.

(10) Finally, for SE matches, have a fat stack of match cards (like tomveatch.com/tt/match.card.txt) to send out with a pair of opponents to record their results for transfer onto the SE bracket.

That's the pre-tournament draw work that I would expect.

There you go.

Tom

On Tue, Oct 26, 2010 at 5:03 PM, Terrence continued:

1. Pre-tournament registration, with inputs for events entered and rating for each player. A data field for fees paid would be helpful.

[Tom replied: that's part of the spreadsheet, yes.]

2. On-site registration, when people walk in and wanta to sign up.

[Tom replied: Minimalist treatment is perfect: If there is space in the event, ask them to fill out an application and pay. Then add them to the bottom of the event player list in the event folder, and copy them to an open spot in the least-populated RR scorecard or the next blank in an SE event. Rarely you may have a higher-rated player whose placement requires a re-draw. Refuse such a request unless you have ten minutes and plenty of blank RR and SE forms to do the re-draw. But with lower ranked players, any order is a good order. They just want to play.
No record of such day-of-event registrations needs to appear in our spreadsheet, I'm working from paper alone at this point.]

3. On-site check-in so we know who have showed up, and add new player or change brackets as necessary.

[Tom replied: See my comment above about check in: check in is unnecessary. See my comment above about adding a new player on the same day.]

4. Construct the bracket in real time ...

[Tom replied: Real-time re-draw would have been in my experience been a benefit in only one case out of the hundred or so events I have drawn, and that just took the necessary ten minutes to re-draw it by hand including writing up four RR5 scorecards.]

... and print out a form for each group to keep score

[Tom replied: The time delay of writing names on cards is approximately the same as the time delay of my computer thinking about and printing out a new page. Maybe my computer is slow, but most seem to be pretty slow.]

- having an example on how to keep score on each form would be of great help.

[Tom replied: I intended for my new tomveatch.com/tt/RR4.txt and tomveatch.com/tt/RR5.txt scorecards to be solve this problem. ]

5. Record game scores, or at least win-loss ratio for each pair of players,

[Tom replied: These are the players' responsibility to record and also to check.]

and construct the next bracket for single elimination or double round robin.

[Tom replied: Again the least anyone would ever reasonably think to do, is plenty to do a great job. Constructing a new bracket means simply copying names from the results of one round to the scorecard or brackets of the next round. It's just a matter of where to put them, and the bracket itself should make that obvious -- the SE bracket should be labelled in advance with which player is to go in which slot. For example 2 RR groups advancing 2 each into an SE4 bracket should have A-1 play B-2 on one half, and B-1 play A-2 on the other half, with A-1 expected to play B-1 in the finals if ratings predict results. Generally, of course, when two players advance from each group, round robin winners should be paired with round robin second-place finishers in the SE round.]

Having a computer and printer on site so the forms and brackets could be printed is critical, especially if we want to consider doing sanctioned tournaments down the road.

[Tom replied: I have found printers and computers to be highly questionable devices to depend upon during the heat of events, beyond the ratings sorting, which could itself be done manually with the stack of paper registrations, in the first place, but at least can be done at a time when the printer can go down and it doesn't ruin anyone's day. What's better?: Having one reliable method? Or having two, of which the first has very, very slightly better efficiency yet substantial unreliability, while the second is that same old reliable method. In the latter case you have to be ready with two systems and it's more study and preparation and work, all of which are unnecessary work in the name of a few minutes efficiency in the rare case of a re-draw.

[Tom continued: The software developer's natural approach of replicating all tournament processes inside software means a whole committee has to learn a whole set of computer processes any of which can match up badly to reality at any number of points, then typically there's one person who's the brittle point of failure for the whole social system, that being the one person who knows the program better than the rest and hopefully knows how to respond to complex new breakdown situations, and maybe he isn't helping or isn't there at the moment. Simple paper everyone can equally understand and process with or without directions, works super well instead, and better to plan for that in the days before than after a breakdown has occurred in the heat of things.]

I believe this is the software used by the IDCCC staff at the Chinatown tournaments: http://www.lilyyip.com/usattts.htm I think this is the same product used by the Bellevue club - could someone ask Tommy?

Other one I found on the net: http://www.tournamentsoftware.com/product/download.aspx?id=16&s=2 Could Tom V pursue the computer/software issue while the iron is hot? Better now than 2 weeks before the next tournament.

[Tom replied: I guess that was my answer, above ;-)]

We will need at least 2 people trained to use the software, where 1 would be available at all times during the tournament. So a total of 3 people will be needed at the control desk: one just for the computer system and two to face the music.

[Tom replied: Computers are job security for computer experts.

[I basically told Kim all this before the event, and he let me run with my prejudices. My problem, which kept me up late Friday night, was not having a printer or a copier, and maybe just maybe I would have benefited from a spreadsheet smart enough to make player lists for each event. Entering the data was faster when someone read the applications to me out loud. And after the sort and print, if I'd had other people to make event lists or copy names onto RR scorecards that could have helped. But I'd rather not get hooked on a complex software system that just makes our task much more complex. Also I'd like to have a little more time in my own schedule to actually carry out my responsibilities like this: I couldn't touch it Thursday, nor before 5pm Friday, which is why I had to stay up late on it.

[Okay enough. Bedtime.]

Terrence

On Thu, Oct 28, 2010 at 10:13 AM, Alan wrote:

Yes this is a long.....long email. I only understand part of it from your intensive research. Are you able to locate any reliable software to run tournaments in the future? I am also exploring the option for future tournament at my club. Will share with you what I found in the future. Pac Rim tournament should be the one we should learn from.

Have a great Thursday.

Alan

--- On Thu, 10/28/10, Tom wrote:

From: Tom
Subject: Re: draw brackets
To: ....
Date: Thursday, October 28, 2010, 7:14 PM 

Tom

Terrence said:

Without a check in process, how do you know how many players you will actually have at EACH event, especially if you are taking in last-minute walk-ins, as we did.

Tom said:

I don't see the problem. If people want to join and there's no space, tell them wait until we see who shows up when we call the event. If the call for a group shows someone didn't appear, then a person who is waiting can play in that group. This is default procedure, doesn't need to be expressed specifically, happens without discussion or high levels of abstract thought through simply being reasonably cooperative. No problem. What's the problem? Is it this: you can't always tell a walk-on at 10am if they can join at 2pm? but the player whose space they might take might show up after all at 1:55 so you can't decide it generally until the last minute, so having a checkin process doesn't eliminate this problem, unless the non-attendee says definitely they're not coming (some did, and that produced some shuffling, again, no problem).

So how could we be sure the players are evenly distributed among the different brackets?

The zip structure of assignment of (especially the top level) players to slots 1 vs 4 but 2 vs 3, etc. solves this problem. You can always redraw any event of 36-or-fewer in 5 or 8 minutes anyway.

For those of us going down to the Pac Rim event next weekend, please think HARD about how anyone could run it without computer help, especially if we aspire to do sanctioned events eventually, even with half the entries.

To run it sanctioned, and save the results, you're talking a different level of work and yes it is possible software can reduce some of the burden. It is also certain that software will give us a lot of headaches and cost us a lot of time which with small volunteer resources we can ill afford. On the other hand, with Yazel, Terrence, Kim and other technophiles eager to join the evaluation-selection-deployment-usage-review-upgrade-repeat committee(s) (not to mention debugging) and with plenty of backup from the other volunteers needed for the other jobs in running a tournament, I'm sure we can even achieve a process that might save a few minutes of time while four or eight people are awaiting their draw once or twice in a weekend tournament. Also it'll make it easier for people not having to read my handwriting ;-)

Forgive my curmudgeonliness. Go find something wonderful, fix it up so it works for us, and I will cheer, really I will. Uploads to a database like USATT or David Marcus's "RatingCentral.com" would be a beneficial feature.

Hey did you know the #1 link for "Table Tennis Tournament Software" on Google is tomveatch.com/tt? Wow!

I've added lilyyip.com/usattts.htm to tomveatch.com/tt so you can click through if you want to try it. David Marcus's zermelo has strong and persuasive pro- testimonials on its webpage. Am I just rationalizing my lack of a printer?

Copyright © 2000-2010, Thomas C. Veatch. All rights reserved.
Modified: November 7, 2010