Basketball Possession Simulation in Basketball Coach

Basketball possession simulation can sound straightforward at first. Players have attributes like shooting, passing, and defending, and those attributes drive gameplay in Basketball Coach. You build teams from groups of players, then match those teams up to play games. Easy enough, right?

But here’s the thing: a possession isn’t just a shot. It’s a chain reaction of possibilities.

Player A brings the ball up the court and passes to the wing, to Player B. Then, Player B runs a pick-and-roll with Player C. Player B doesn’t gain an advantage, so they pass it back to Player A. Player A shoots, now more open because of the attention drawn by the screen action on the other side of the court. It’s a good look, but a miss. Player D grabs the offensive board, and suddenly we’re back at the top of the decision tree.

And we do it again. And again.

---

The While Loop That Runs Basketball

In Basketball Coach, a possession is represented as a while loop. A while loop is a control-flow structure that repeatedly executes code while a condition remains true. In this case, the condition is simple: the possession is still alive.

A possession ends on terminal actions like:

• a missed shot recovered by the defense,
• a turnover, or
• a shooting foul that leads to free throws and closes the sequence.

Here’s a heavily simplified snippet of that logic for demonstration:

Each loop iteration is a discrete action: a pass, a dribble move, a screen, or a shot. In real life, those actions blend together. In the sim engine, they resolve as a sequence of choices.

Let’s break that sequence down.

---

Action Selection: The Brain of the Offense

Every possession starts with a player choosing an action. Shoot, pass, or run a pick-and-roll? If they shoot, is it a mid-range jumper, a three, or an inside attempt?

Originally, I modeled tendencies with flat numbers representing the relative chance of each action. Here’s what that looked like for a base archetype:

That approach worked as a starting point, but over time I added more layers to player identity. Manually tuning raw tendency values became too brittle and too labor-intensive for proper basketball possession simulation. Like many other parts of the codebase, this system wasn’t scaling.

Then it clicked: players don’t think in percentages – they think in preferences.

Now, each archetype uses a ranked action list instead of a flat probability table. The list order captures what the player prefers to do, and it maps better to real hoopers. I’m a pass-first player in pickup. After that, I’m usually looking for an open three. Other actions still happen, just less often.

This constant dictates how ranked actions are weighted in a more fluid way than raw percentages:

That’s how you get a stretch 5 who prefers to swing the ball, or a rim-runner who barely considers threes. Here are sample preference profiles:

On each possession, the ball-handler selects the next action based on personal preferences plus game-state conditions not covered in this post. We also store preferred inside-shot orderings and ineligible actions by archetype.

The goal: every action should feel tailored to the player taking it.

---

The Roll: Offense vs. Defense

Both sides generate a roll from attributes, fatigue, traits, team effects (temporary and permanent), and shot quality. There are a lot of inputs, and each one matters in deciding whether the offensive action succeeds.

Here’s a look at that complexity:

Having many levers is critical in a coaching simulation, because it gives users meaningful ways to optimize offensive and defensive success.

I’m constantly tuning this logic. The newest concept is spacing as either a boost or a deterrent to offensive success. Sharing the floor with shooters should materially help a ball-handler, and now that effect exists in code.

Branching Outcomes: One Roll, Many Roads

The real fun begins after the roll.

If a player takes and makes a shot, the possession ends. But what if they miss? What if they pass?

A miss doesn’t automatically end the possession. It can trigger a block, a foul, a rebound, and then either end or reset the loop. A successful pass can open an assist window and hand control to a new ball-handler.

Shot Miss → Block Check → Foul Check → Rebound → New Possession (or reset)

Pass Success → Assist Window Activated → Pass Completed → New Ball-Handler → Next Action

---

The Shot Clock as Narrative Engine

Funny enough, it took me about two years of development to implement shot-clock functionality. Now it’s a critical part of every basketball possession simulation.

In Basketball Coach, the shot clock isn’t just a timer – it’s a pressure system.

• Early clock: passes and setups are encouraged.
• Late clock: forced shots become the only eligible actions.

Forced shots happen programmatically. Here’s what that logic looks like:

Tempo, which the coach can change during a game, also affects the maximum number of actions per possession:

---

Walkthrough Of an Example Possession

Let’s break down one full possession from Basketball Coach to show how this logic for basketball possession simulation unfolds step by step:

1. Luguentz Dort brings the ball up the court (GET_BALL)
   • GET_BALL always triggers live‑ball steal logic.
     • Modifiers: Dort’s dribblingAbility + offenseIq vs defender steal + perimeterDef.
   • Shot clock advances (GET_BALL consumes time).
2. Luguentz Dort passes the ball to Jalen Williams successfully
   • Pass outcome uses:
     • Offensive roll + dynamic pass buffer vs steal roll.
     • Pass buffer scales with passer IQ and turnover‑resist traits (if any).
   • Pass result effect triggers: temporary bonus to insideShot and threePoint for the offense (scaled by roll margin and passer rating).
   • Assist window activates; Dort becomes possible assister.
3. Jalen Williams passes the ball to Shai Gilgeous‑Alexander successfully
   • Same pass logic; assist window refreshes to Jalen Williams as possible assister.
   • Pass effect again applies temporary bonuses to insideShot and threePoint.
   • If Jalen has playmaking traits (common for lead wings), this would raise pass success rate and reduce turnover risk.
4. Shai Gilgeous‑Alexander pulls up from mid‑range
   • Action selection uses Shai’s archetype preferences (likely mid‑range favorable) but no play forcing here.
   • Shot quality uses midRange vs defender perimeterDef, plus any open/contested modifiers.
   • Assist window is active: Shai is shooting off a live assist window, which increases shot consistency and boosts certain traits.
   • Roll compression applies (soft cap at 78, falloff 0.3).
5. Cade Cunningham commits the shooting foul on Shai Gilgeous‑Alexander
   • Foul check uses:
     • Shai’s offensive roll + offenseIq + foul‑draw trait multiplier (if present)
     • minus Cade’s defensive roll + defenseIq, with foul‑commit multiplier if Cade has a physical trait
     • plus a constant value SHOOTING_FOUL_BUFFER.
   • If Shai has the FOUL_DRAWER player trait, foul‑draw chance is explicitly boosted. He does, of course.
6. Shai makes the free throw (1 of 2)
   • Free throw success rate is based on the free throw attribute.
   • Outcome is random roll vs that percentage.
7. Shai misses the free throw (2 of 2)
   • Same free throw logic.
   • Miss on last FT triggers a rebound action.
8. Tobias Harris rebounds the ball successfully, ending the possession
   • Rebound contests use rebound attribute on both sides.
   • Defensive rebound wins if: defensiveRoll + DEF_REBOUND_BUFFER > offensiveRoll.
   • Possession ends after DREB.

---

Closing Thoughts

A basketball possession is a system, not a moment. That’s the point of this architecture.

The possession loop provides structure. Preferences provide identity. Rolls provide variance. Branches provide realism. Together, those components create a narrative arc that makes each possession feel meaningful. Even when it ends in a brick.

That balance is the heartbeat of Basketball Coach, and it’s why I keep tuning the system until it feels even more right.