Labels and Counters

The label class (lines 408-430) represents an arbitrarily labeled value on the scoreboard. The label and its value can have separate fonts and colors. The Pygame surface is created on line 418.

The render function starts by clearing the surface (fill) with black then rendering the value, calculating its center point, and drawing it. Lines 426-428 do the same thing for the label text before returning on line 430.

Lines 432-454 describe the counter class. Counters are identical to labels, except their self.value is expected to be an integer.

The Board Class

Everything comes together in the board class (lines 456-538). All of the modules that have been defined to this point are initialized here, starting with pygame.display.init, which starts the Pygame engine. The pygame.display.set_mode creates the drawing surface, setting the window size. display = 1 makes the Pygame window default to the second monitor, and flags = pygame.FULLSCREEN is self-descriptive.

Because this program uses Pygame's font capabilities, these are initialized on line 460, after which all of the fonts are loaded. In Pygame a font is the face itself and an associated size, so the same font file may be loaded multiple times with different sizes.

Line 466 loads self.logo, which is the logo displayed along the bottom of the scoreboard. The convert at the end of the line makes the image's internal format match Pygame's initialized display format so the logo blit onto the screen is faster.

Line 468 creates an instance of the clock class, with a reference to self.screen passed in so that it can draw the updated clock directly.

The final lines of the program (not shown) initialize five different instances of the counter class for the home and visitor's scores, number of timeouts for each team, and the game period. In each case, valueFont and labelFont are set to one of the font/size pairs initialized earlier. A label indicates which court each scoreboard is tracking.

A Typical Game Day

When the crew arrives on game day, the first task is to set up the scoreboard operator's console (two Raspberry Pis, one per scoreboard). Once that's done, robotically controlled cameras are placed around the court and everything is tested. The youngest teams play first in a half-court model. Halfway through the day, play switches to full-court games (Figure 5).

Figure 5: Depending on the age group playing, the game may be on full or half courts. Each scoreboard must be routed to follow the current court configuration.

At halftime of each game, video messages play onto the screens, and the scoreboard returns to normal operation (Figure 6). At the halfway point of the day one scoreboard system is routed to both score displays because a single court is now in use. This switching is accomplished with a matrix video router.

Figure 6: The scoreboard display as seen on the large, audience-facing monitors.