Doom awaits all of us with today’s tournament software options.
I always hang up on authentication bits. Does every player have a password they have to input to verify scores at the end of the round, or are they going to finger-sign the final sheet, or…? Mistyped scores should be no different digitally than on paper.
I’d say City Champ ran successfully, from an outsider’s perspective, with @haugstrup’s software. Think that was the largest match play tournament outside of Pinburgh, no?
Besides, saving ReplayFX staff from data entry jobs - Priceless
It’s only Kevin doing the data entry, at least for the non-playoff rounds, and he seems to like doing it. There’s just enough typing that it can happen – if Pinburgh doubled in size we would need a different solution. (Easiest solution: two Kevins.)
For City Champ we used volunteer scorekeepers and paper scoresheets. Players would fill out a paper scoresheet and bring it to a scorekeeper who would enter the results. We had one result that needed to be adjusted after the fact. Ironically the results were recorded wrong on the paper sheet and I was the player who wrote them down wrong.
The tournament was only one tenth of the size of Pinburgh and that of course makes a huge difference. We had 7 scorekeepers – one for every three groups. That was definitely more than we needed (only 2-3 scorekeepers were active at the same time), but for Pinburgh it would still be a very large group of volunteers.
I’m a firm believer in paper backups for large match play events. For anything City Champ sized and above I would personally always require a paper sheet first that’s then transferred digitally. There are just too many things that can go wrong.
For SFPD we have an open system where in theory anyone can adjust results of any game in progress. For a couple of seasons each scoresheet would have a QR code with a secret link (again, paper backups since we have 70+ players each night). That worked well. After we expanded from 4 games per night to 5 games there wasn’t any space for the QR code so the four-character code is just printed on the sheet. A Pinburgh style tournament should of course use a much longer code (32 or 64 random characters), but I do like the approach of using QR codes.
Still that would require separate codes for all players. Maybe printed on the back of your badge?
Match Play Events will be going in a different direction. As MHS says huge tournaments have different needs. MP is more tailored to the 10-150 player range and many corners can be cut. In the future I’ll be adding the ability for players to suggest the result of a game using their own MP user account. A tournament director or designated scorekeeper will have to manually approve all suggested scores. I feel this will be a good middle ground where players to the data entry and a scorekeeper verifies.
I’ll do some sort of thing where you can force all players to suggest results and the TD will see a nice big green checkmark if all four players have suggested identical results.
The 24 hour battle at the sanctum that @JSwain ran had fewer players (just over 60) but it had many more games played. That tournament highlighted some performance issues on the live standing pages that I fixed. City Champ showed another problem with a slow calculation for tiebreaker scores (used to determine seeding for finals).
You might have noticed a very slow standings page for CC (4.5 seconds or so). I fixed that this week and the page is back well below 1 second. I try to improve performance in one way or another after each big tournament.
The main problem with match play tournament is that all players (and their friends at home) are all hitting refresh on the same pages at the same time. That can lead to a lot of simultaneous hits even for a modestly sized tournament. One strategy I will be trying to out mitigate this is to provide more notification options in addition to text messages. That way at least players will get their game notifications even if their friends at home are seeing slow response times on Match Play Live.
Each player player enters their score and sends it to the system. Since there would be a 1 to 1 mapping of player to phone number auth takes care of itself. (Plus, this is a great excuse for younger players to finally get a cell phone. You’re welcome Escher. Actually, I’d wager most kids have phones by the age of 10 theses days, but I digress.)
The system then sends out the match results to all 4 players. If anyone objects they take it to an official at that time, or just reply to the system to flag it.
That way you don’t have to rely on the internet or smart phones. Of course, I’m not sure how much that would cost in Twilio fees…
All done in Excel. Scores were entered after each game. It was doable … but we only had 14 simultaneous games. It took between 30 seconds and 1 minute per 4-player game to enter. With a single person entering, we were near the limit, as we generally were finishing up typing in the last scores when the longest-playing game ended. We could probably double that if we had two people entering scores on a shared spreadsheet. But that’s still under 30 matches, nowhere near the scale of Pinburgh.
OCR is the way to go. Take photo, it recognizes scores, then drag&drop scores to player names. Photo saved as backup. Obviously IT connectivity would need to be very reliable, and depending on level of risk organizers are willing to take, probably want the current paper system as backup. But to use it as backup you need to be sure there’s a way to switch mid-tourney. That itself might not be easy or possible. So there needs to be risk mitigation for all the doom scenarios Bowen refers to if this was done. Thus totally understandable why scores aren’t recorded at Pinburgh.
This is provided just a data-point for anyone thinking of how to create software for this. I’d be happy to use it :).
I’m not at all convinced of this. Scores are displayed in a LOT of formats/fonts/layouts, especially if your event includes games of different eras (LCD, DMD, SS, EM)… combine that with variable camera quality, I think there’s a considerable risk of OCR errors. Then the proposed drag-and-drop process. I don’t really see how all that is more efficient than having players enter around 10 keystrokes per player per game. If the players are on top of things (yeah, that’s asking a lot, sometimes ) they could be keying the scores for each game into the system as each player finishes, making the incremental time impact for data entry negligible (just the time to input the last player’s score).
I’m a big supporter of machine score entry into scorekeeping software. There are so many stories to be told with that data: where were the big blowouts, or the super-close games? And of course so much interesting analysis can be done with the data afterwards.
A couple months back I wanted to create an app that save high scores so I looked into the state of the art of OCR tech. Given the amazing things Google can do, translate foreign languages on the fly in video, I figure there should be an SDK or service available. No such luck.
It turns out that doing OCR on pinball scores was very tough and me and a buddy gave up after 7 or 8 hours of trying. There are a whole bunch of factors to take into effect, not the least of which is just getting the image recognition to find text that is often at an angle. Then the dots don’t help since they confuse many of the standard image cleanup methods.
Having said that, Google just announced a new vision API they will be releasing soon:
I’m hoping this might work and solve the problem easily.
As I was saying, keeping the tournament running on time is the primary concern, so we can’t use the NWPAS system
Risk mitigation is key, and anything you want to use has to have a backup plan, and has to have some proven testing at other events – any sort of error or self-destruct would be catastrophic for an event the size of Pinburgh.
) they could be keying the scores for each game into the system as each player finishes, making the incremental time impact for data entry negligible (just the time to input the last player’s score).