What Great Larry Bird Actually Is
I spent about three weeks digging into this after a colleague dropped a link in a Slack thread and nobody could figure out what it was supposed to do. The project sits somewhere between a basketball simulation engine and a fan-made documentary toolkit. It wasn't built by any major studio or well-known organization, which is why you won't find it on the front page of most sites that cover sports tech or NBA history. The core of the project is a set of tools that lets you reconstruct Game 6 of the 1986 Eastern Conference Semifinals between the Celtics and the Pistons using publicly available play-by-play data, basic box score numbers, and frame-by-frame analysis from archived broadcast footage. That sounds narrower than it actually is, because the methodology bleeds into other eras and matchups once you understand how the tracking data gets structured.
Downloading and Getting Great Larry Bird Running
You can find the repository at github.com/larrybird-archive/great-larry-bird. There is no installer. You clone the repo, run the Python dependency script, and point it at a local video file. The whole setup took me roughly forty minutes on a mid-range machine. If you hit dependency conflicts, which you will, downgrade numpy to 1.24 and use Python 3.10. That combination works. Newer versions of numpy break the optical flow calculations. Once it is running, the interface is command line driven. There is no GUI. You feed it a date range, a team pair, and it pulls what it can from the NBA stats archive and merges it with whatever footage you drop into the assets folder. The merge step is where things get interesting. I ran into a specific problem when I tried to load a VHS rip of the 1986 playoffs that I had digitized from a personal collection. The frame rate was 29.97 and the timestamps in the play-by-play data were locked to NBC broadcast time, which drifts by roughly two seconds per quarter due to commercial bumper timing. The alignment tool would place every possession half a step out, making the defensive rotation overlays useless. My workaround was to write a small pre-processing script that recalibrated the timestamp buffer using the known starting time of each period from the NBC TV guide archives. That patched the drift and got the overlay sync within a half frame. Without that, the tool is mostly decorative.
How the Tracking Actually Works
The engine uses a combination of coordinate reconstruction and shot chart regression. It does not have true player tracking data from that era because NBA optical tracking did not begin until the 2013-14 season. What it does instead is interpolate player positions based on known spacing rules, court dimensions, and the positional data embedded in the original box scores combined with frame extraction from broadcast video. The counter-intuitive part is that the interpolation accuracy is surprisingly high for off-ball movement and screening actions, but it completely falls apart on fast break transitions where multiple players are moving at full speed and the camera pans aggressively. I learned this the hard way. I spent an afternoon trying to validate Bird's defensive closeout angles against Game 2 of that same series, and the system kept showing him closing out from eight feet away when the replay clearly showed him at three. The issue was the camera pan lag. The broadcast delay between the actual play and the camera framing caused the coordinate mapping to stretch. The fix was to only trust off-ball data during half-court sets and to exclude transition plays from any analysis you plan to publish or present. If you skip that filter, your numbers will look plausible to someone who has never watched the game, which is worse than being obviously wrong. Another nuance that beginners miss is the shot quality weighting. The tool assigns an expected points value to every reconstructed shot based on distance and defensive proximity. But the model uses a league-average defensive proximity curve, which means it treats every defender the same. That is a significant error source when you are analyzing a player like Bird, who consistently drew double teams and collapsed defenses differently than the average defender. I ended up building a custom weight modifier that adjusted the proximity curve based on the specific defender in the frame. It took me about six hours to calibrate against known possession outcomes, but once it was tuned, the shot quality estimates aligned much closer to what the advanced metrics from actual tracking data show for that era.
Get the Full Details
Practical Use Cases
The most common reason people run this is to create visual breakdowns for film study or content. You can generate still frames with player positions overlaid, export possession timelines as CSV files, and produce video composites that show defensive rotations in real time. The export options are limited to PNG sequences and MP4, so if you need something like Final Cut or Premiere Pro project files, you will have to convert externally. I use it mainly for historical matchup previews when I am working with youth coaches who want to understand spacing concepts that predate modern tracking. Having a visual reference for how Bird manipulated help defense in the mid-eighties gives them a concrete example instead of abstract spacing principles. It takes about twenty minutes per game to get clean output if you have your footage ready and your timestamps calibrated. That is reasonable for the depth of detail it produces.
Known Limitations
The tool fails completely if you do not have broadcast footage for the games you are analyzing. It is not a data-only system. Without the video reference layer, it falls back to rough positional guesses that are not reliable enough for any serious analysis. You also cannot run it on mobile devices or through cloud hosting without significant overhead. The optical flow computations are CPU bound and a single game on a standard consumer machine takes approximately forty-five minutes to render at full resolution. If you need faster turnaround, you will need to lower the frame sampling rate or process only key possessions rather than full games. There is also the question of data sourcing credibility. The play-by-play records from the mid-eighties have known gaps, particularly around assist calls and defensive rebound attribution. The tool does not flag these gaps explicitly, so you need to cross-reference with secondary sources like the NBA official records book or contemporary newspaper game recaps if accuracy matters for your use case. I keep a personal spreadsheet of the known inconsistencies and run a validation pass before exporting any final data. Overall, it is a useful tool if you understand where it is solid and where it is guessing. The methodology is transparent enough that you can audit the output if you know how to read the coordinate files. Most people skip that step and treat the visual overlay as truth, which leads to bad conclusions. Do not do that. Verify against the footage. Check the timestamps. And always apply the transition play filter.
