On Mon, Oct 25, 2010 at 10:55 PM, Tom wrote:Inspired by how bad the Round Robin (RR) scorecards were at the tournament, I put in a little time and now I think the round robin event scorecards at www.tomveatch.com/tt/RR4.txt and www.tomveatch.com/tt/RR5.txt are the last word in RR scorecards. Old fashioned looking, but I hope these will be (relatively) unbreakable.
--- On Tue, 10/26/10, Kim wrote:Tom,
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.
On Tue, Oct 26, 2010 at 5:03 PM, Terrence wrote:Folks,
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 bracketsHi,
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):
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 www.tomveatch.com/tt/RR4.txt and www.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 www.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.
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 www.tomveatch.com/tt/RR4.txt and www.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.]
On Thu, Oct 28, 2010 at 10:13 AM, Alan wrote:Hi Tom,
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.
--- On Thu, 10/28/10, Tom wrote: From: Tom Subject: Re: draw brackets To: .... Date: Thursday, October 28, 2010, 7:14 PMMy suggestion is: Use no software. Just sort the player registrations/applications by player rating, then go through them putting names on event lists in order of player's rating. No checkin process. Pull off the event list onto RR4 and RR5 scorecards and SE4, SE8, SE16 brackets for draw. I think the minimum paper records are all you need, they are efficient and adequate. Software makes for much study, much work, and many failures. I recommend against software.
Terrence said:I am still lost.
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.
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).Terrence said:
So how could we be sure the players are evenly distributed among the different brackets?Tom said:
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.Terrence said:
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.Tom said:
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 www.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