I recently built a tool for constructing all possible NBA trades involving players and two teams. My inspiration came during the NBA trade deadline and mock fan trades were flying left and right on my timeline, but it felt like a lot of the discussions kept coming back to the same general trade structures. There’s good reason for this since NBA media reports on which teams are trying to make deals and in the market, but it also creates an anchoring effect.
I wanted to counter that effect by starting with the entire space of possible NBA trades according to the players you want to trade, filtering the results according to the NBA’s trade rules, and presenting the combinations to the user. It’s at that point that the user picks the trades that seem reasonable based on the involved teams.
It is currently a proof-of-concept and seems successful for that level as it shows all of the trades and has options for trade returns of 1 to 4 players, running fairly fast for each of the options. It needs to be more robust for handling more of the NBA’s trade rules to be considered “production-ready”, as well as improving the presentation and adding more contextual information. The data is currently scraped from Hoops Hype’s team salary pages, which don’t include all of the relevant information (i.e. bought out contracts, no-trade clauses, date-based restrictions for deals signed the previous offseason, etc), making it difficult to reach that level of functionality.
The way it works is fairly straightforward - the user selects a team to trade players from, then the players themselves, and finally the number of players to receive in return. The code sums up the outgoing players’ salaries, generates all combinations of players on other teams, and filters the results to legal trades based on the teams’ subsequent cap status (cap team, tax team, 1st or 2nd apron team).
Improving the usability of the tool, primarily in output presentation, is one of the main targets in addition to fleshing out the handling of NBA trade rules and contracts. I envision each team having a collapsible section with a header listing the number of possible trades for them. The section displays all of the possible trades when expanded and, for cases where there are and many options for “filler” players, that the “filler” players are grouped together to reduce the number of results one has to scroll through. Here is a rough mockup.
I initially chose Streamlit because of my familiarity with the platform and, after some experimentation with their “forms” feature, I was able to get a basic version running. Going into the project I was worried about the code running slowly for combinations of 3 or 4 incoming players, but that soon proved to be a non-issue. The collapsible nature of the results, basically returning the data in a JSON-like form, also suited my needs. However, as mentioned earlier, the customization of the results became an issue as I wanted to fine-tune their presentation.
I tried Panel as well, in combination with PyScript, but ran into the same issues and found the functionality of inputting teams and then picking from their players more difficult to implement than it was with Streamlit. I may try Shiny for Python, too, though I think it getting the desired functionality might be a job for JavaScript.
The last step for improving the presentation is bringing in information around player quality and impacts to a team’s cap, similar to existing NBA trade machines.
You can find the tool (in its current iteration) here and see all the code here on GitHub.