Fightball Scoreboard & Shot Clocks

Fightball Scoreboard & Shot Clocks

In early 2016, we worked with Technical Producing Group to create a digital scoreboard system for Fightball, a new one-on-one basketball league based in NYC. The first-ever Fightball tournament happened in May 2015, and their scoreboard system was problematic, devolving into a designer creating images manually and quickly putting them up on screen as the game progressed. For a game with an 8 second shot clock, manually updating the scoreboard just wasn’t fast enough to tightly follow the action of the game.

Working with TPG and Fightball, we developed their initial concepts into a complete scoreboard console. The inner workings of the console are reasonably complicated, but they are mostly transparent, giving the end-user a quick and seamless way to follow the game play on the scoreboard. We also built custom wireless shot clocks, which were controlled through the press of a button on the scoreboard console.


The Console

Fightball is a single-elimination bracket, going from 8 players to 1 champion in about an hour of gameplay. The brackets are seeded the day before and loaded into the system the morning of the game; as games are completed, the players automatically progress through the bracket. What the scoreboard operator needed was a quick and simple way to update the scores, start and stop the shot clocks, and switch between bracket and scoreboard views on the screen with the touch of a button; game play and scoring happens so quickly in Fightball that anything more complicated would cause the scoreboard to lag behind.

Console close-up
Console close-up

TPG designed a custom console, which The Scenic Route fabricated beautifully, then shipped to us to install the buttons and electronics.

Here’s what we built into the console:

  • A touchscreen for game setup and game flow (generally used between games)
  • Physical buttons for scoring and game clock start/stop
  • Remote control for the shot clocks
  • Wireless link to the shot clocks themselves
  • HDMI/DVI output to the scoreboard projector
  • XLR balanced line out to sound
  • Ethernet remote video switcher (for switching between bracket and scoreboard views)
  • Internal tracking backup

The combination of touchscreen and physical buttons gives the operator multiple ways to control nearly every component, making it a single-failure proof system.

The Control System

When we looked at platforms to build the system, we quickly settled on building it around the Unity game engine.  We’d used Unity as a 3D rendering engine on a few other projects; this was our first 2D project, but we knew Unity had the capability to do what we needed.  At its core, a game engine renders graphics based on realtime user input, as well as providing tools for building graphical/touch-based user interfaces, since games are frequently played on tablets and phones.

Using a game engine for this project was perfect because it allowed us to model the logic of the game in the system and then produce graphics based on that model.  Because Unity is a video game engine, concepts like keeping track of multiple time clocks (period time and shot clock time) and keeping score are not foreign to it; state machines where there’s a winner and a progression through “levels” of a game were also easy to implement.

The console used a combination of physical buttons and the touchscreen as inputs. The touchscreen operated the “non-realtime” components of game flow (e.g., end the period, switch to a new game, adjust the time clock), while the operator primarily used the physical buttons to make more instantaneous changes during the game (add points to the scoreboard, reset the shot clock, etc.). The touchscreen also acted as a backup to the push buttons.

Using Unity, we created a custom interface between the push buttons and the computers that emulated a keyboard, so pressing the start/stop push button for the game clock was equivalent to pushing the space bar. This created a simple interface (using the keyboard input functions within Unity), as well as providing a backup solution for a physical input if there was a problem with the buttons.

For output to the scoreboard, we took advantage of a new feature introduced in Unity 5.3: the ability to route camera output to specific displays. This allowed us to show Display 1 on the operator’s touchscreen (which is a 1440 x 800 display), while Display 2 (a completely different view) was the full 1920 x 1080 output to the video projector.

The Shot Clocks

Shot clock installed above backboard
Shot clock installed above backboard

The other major component we created was the shot clocks themselves. We looked at off-the-shelf digital displays, but we couldn’t find anything that fit our needs. Instead, we designed 9″x17″ custom circuit boards with 250 LEDs in a 7-segment display pattern, an Xbee radio link, and battery voltage and current sensors to feed data back to the console. The circuit board was fabricated on a super-thick, rigid board and then mounted to a flexible piece of plastic.  The plastic was then attached to the back of the clock frame, serving as a sort of shock absorber; this allowed the rigid circuit board to move around without breaking if the clock got hit directly with a basketball.

Because of the mobile nature of the Fightball installation, we wanted to avoid running wires to the clocks, so we designed each clock to run off of either a battery pack or a power supply. After some deliberation, we ended up with dedicated LiPoly battery packs designed for RC racecars; they carry enough power to run the clocks continuously for about 5-6 hours, which is more than enough to get through an evening’s events.

The shot clocks take a signal via Xbee radios (the same sort we use in our Capulet controllers), and the signal simply tells the clock what digit to display, rather than free-running. This is primarily because the two clocks (one on each side of the court) should always show the same time, and if we relied on the clocks to free-run, they would inevitably get out of sync with each other. By explicitly telling the clock what digit to display, we do run the risk of one clock missing a packet and showing a different time, but it will be remedied almost instantly when the next packet is received.

Being wireless and battery powered, we wanted to be able to monitor both the battery strength and the signal strength in real-time. Each time the clocks get a packet, they respond with the signal strength of that packet and the current battery voltage. It’s not the most reliable system (battery voltage is mostly proportional to load at any given moment…), but it gets the general idea across and warns the operator of potential problems.

All-in-all, this turned out to be a great project. Thanks to Technical Producing Group for involving us, The Scenic Route for their amazing metal work, and Team Epiphany and Fightball for putting together an amazing new experience.

 

No Comments

Leave a Reply