RFC 2021 – The Broadcast Racquetball Scoreboard Project

RFC 2021 – The Broadcast Racquetball Scoreboard Project

There are many criticisms of racquetball broadcasts that mention the difficulty encountered by the production team to keep the score up to date. This request for comments will address some of the needs of the solution. Please feel free to add input as to physical devices that can assist in solving the problem (specific tablets that can run for 12-15 hours on a charge), specific technologies that can be used to implement the solution (hosted web data with multiple interfaces for the three primary consumers), and even specific languages or no code packages that would be ideal to solve the problem quickly.

1) The referee is often 30-50 feet from the production team and cannot be asked to shout the score once for the players, once for the live audience, and a third time for the production team. The ideal solution will involve the referee who is already keeping score updating both a screen for the audience/players and layout that the broadcast team can add to the production without manually reproducing the score. i.e., one scorekeeper, the referee, keeps the only score which is displayed everywhere needed.

2) The players need to know how many timeouts they have used or have remaining, and how much time they have left in those timeouts. This should be displayed by the solution, and a countdown timer should be displayed showing the remaining time in the current timeout.

3) The players need to know the number of appeals they have used or how many failed appeals they have remaining. This should be displayed by the solution.

4) The current server’s name or their score should be a larger size, so that there is no confusion at the end of a rally as to whether there should be a point or a side out. This larger size will also help ensure that the correct player returns to the service box after a time out.

5) The player’s names or the names of the team of players, should be input by the broadcast team (not by the referee).

6) The number of time outs per game and the length of those timeouts should be input or selected by the broadcast team.
6a) LPRT/IRF = 2 one-minute timeouts per game
6b) IRT = 1 one-minute timeout per game
6c) USAR = 3 thirty-second timeouts in a game to 15, and 2 thirty second timeouts in a game to 11

7) The time between games should be input or selected by the broadcast team. When a game ends, the time until the next game starts should be displayed for the players and the live audience. This can also be made available to the broadcast team but should not be displayed on the broadcast itself. The end of the game shall be marked by the referee to start the countdown.
7a) LPRT/IRF = 2 minutes between all games
7b) IRT = 2 minutes between all games
7c) USAR = 2 minutes between game 1 & 2, 5 minutes before game 3

8) The player/team that served first in the first game shall be recorded and visible at all times for the referee and the live audience.

9) The scores of both players shall be visible at all times (referee, audience, broadcast team), and the ability to increase or decrease the players score will only be available to the referee.

10) Technicals. The number of technicals assessed to each player will always be visible to the referee and audience. This should also be available to the broadcast team but should not be a part of the broadcast scoreboard.

———-

What am I missing?

Is there something a referee keeps track of that isn’t on this list?

Is there anything the broadcast team or live audience would want to know that isn’t on the list?

Is there a quick and dirty solution that would let production teams deploy something like this with minimal investment in new hardware? Which hardware?

———-

Some additional discussion took place on Facebook.

 465 total views,  1 views today