← Courtside Crew Play Courtside Crew →Free on itch.io. Runs on Mac, Windows and in your web browser.

A Pickleball Player's Illustrated Primer

31 October 2026

Whatever results from AI, one hope is a patient, personal teacher for anyone learning anything. In The Diamond Age, Neal Stephenson imagines the Young Lady's Illustrated Primer, a book that teaches a girl named Nell by making her part of its stories and changing as she learns. We may already be at a point where anything a person can learn can have its own Primer. It would adapt to the learner, make sure the basics are solid before building on them, teach the main strategic ideas, find and drill each learner's weak spots, space practice out, ask for recall rather than rereading, give feedback at once, mix kinds of practice, and give far more decisions to make than real life does.

Courtside Crew is an experiment to see how far an AI coding agent, Opus 5.5 in Claude Code, can get at building one for pickleball. I chose it because it is essentially a turn-based strategy game, with physical components that can be simulated faithfully: the ball's flight, bounces and footwork. The result is a free 3D pickleball game made with the Godot engine, with no ads, collecting no data.

At each shot the game stops, and you pick the shot, where to aim and where to go after.

Between 12 September and 17 October 2026 the project grew to about 1,500 commits, 225,000 lines of game and tool code and 85,000 lines of tests (GDScript, Python, shell and shader files, counted with wc). By the Claude Code transcripts, the model read 24.2 billion tokens of input, 23.6 billion of them from Anthropic's prompt cache, and wrote 18.6 million tokens of output. About 22% of its replies came from Opus 5, before I switched to Opus 5.5 on 23 September, and 1% from Fable 5.1 by accident. At Anthropic's published API prices that would have cost about $10,500, but was covered by my $200-a-month Claude Max plan. Handing the simpler jobs to Sonnet 5.5 and Haiku 5.5 subagents would likely have worked well and cost less, but for this experiment I chose not to.

I wrote none of the code, but it wasn't made from one big prompt either. The game grew a small change at a time: I played it, said what was wrong, and turned each thing I cared about into a check that every change had to pass before it was committed. Every warning is an error, each folder may only use the ones below it, the chances the game shows are tested against how often things actually happen, and a screenshot tour checks every screen at 57 sizes. Those checks, rather than my reading of the code, are what kept a project this size maintainable.

This article covers:

  1. Applying the research on learning
  2. How the work was checked
  3. What the game is
  4. How it works

Applying the research on learning

The research on learning suggests practices that were incorporated into the game:

A strategy card, played out on court, with Why, When and a quiz behind it.

How the work was checked

What the game is

Courtside Crew teaches the 2026 USA Pickleball rules and the strategy behind good play. Its 254 rule cards explain the rulebook in plain language, with 445 quiz questions between them. Every call comes from the game's own referee code, and a "Why?" beside a call opens the rule behind it. The Strategy school has 54 cards on playing well, and the Form school 15 cards on how to hit each shot.

A rules lesson: the answer comes from the referee code, not from a typed-in key.

Drag is computed from the ball's size and weight, so a dropped ball settles at about 17 m/s outdoors and 14 indoors, as real balls do. Spin bends the ball through the Magnus effect, which grows with the square of speed, so a drive dips while a dink barely curves. The ball skids on a bounce, then grips: topspin kicks forward and slice checks up. Outdoors, gusts build and fade over several shots, and the trees, flags and the sound of the wind follow the same gusts the ball flies through.

In turn-based play, for doubles, singles or mini-singles, play pauses at each of your decisions. You choose the shot, the aim, the pace and spin, where to meet the ball and where to move next. Each option shows its chance of landing and of winning the rally, worked out by flying the shot many times with a realistic wobble on the strike, and tests hold every shown chance to how often it comes true. The computer players learned their strategy by playing against themselves. Opponents have styles (bangers, dinkers, lobbers, poachers), a form of the day, nerves at game point and fatigue, all visible on court. They notice your habits and lean toward them.

After every shot the game says why it landed or missed ("long: hit while the ball was still rising"), how cleanly you met it, and what had lowered the odds before you chose. At the end of a game it shows how your shots did against their chances and names the point where the game turned.

The season: a club ladder, then a road trip to the other courts.

You can also watch a narrated game, or referee one and call the faults. There's a score-calling trainer, ten-ball target drills, and puzzles such as saving a game point or spotting the decision that lost a point. A season takes one character up a club ladder, on a road trip to ten venues from a school playground to a ship's deck, and into the finals: twelve courts in all. Rivalries build, a close loss earns a rematch, four newcomers join as partners once you've beaten them, and winning the finals sets off fireworks.

Eight characters, each with their own voice, share one animation rig. Their faces have fifteen expressions, and they wear outfits and accessories won at the season's venues. An announcer names signature shots and calls game point.

How it works

Structure

The game is written in GDScript for Godot 4.7. Its folders are layered so that each uses only the ones below it, and a test fails the build otherwise:

main/  ->  modes/  ->  ui/  ->  world/  ->  audio/  ->  save/  ->  rules/

rules/ is pure logic: scoring, the referee, the ball's flight and both rally engines, with no scene tree, saves or sound. save/ keeps progress and syncs it through iCloud with a pure merge. audio/ plays every sound. world/ is the 3D court and the playback of what the rules produced. ui/ is the shared look and a layout fitted to each screen by its size alone. modes/ holds one folder per screen.

Because rules/ is pure, every right answer in a lesson is worked out by the referee code, and the logic can be tested alone, replayed exactly from a seed and run thousands of times in self-play. A screen only animates what the rules decided.

Ball physics

A rally on the ship's deck: every flight is worked out from drag, spin and the bounce.

The ball is flown in pieces at most 0.05 s long. Drag uses separate coefficients for the outdoor and indoor balls, measured from how fast real balls settle when dropped. Spin is a Magnus push that grows with speed and spin. Wind is a vector the air moves with, and gusts come from two Ornstein-Uhlenbeck processes, along and across the wind, seeded from the rally so a game code replays the same weather. A bounce keeps a coefficient of restitution vertically; along the court the ball skids against friction until it grips, and a hollow sphere's moment of inertia decides how spin trades against speed. A shot is aimed by correcting its launch until the flown ball arrives on the target, through the same air.

Shot tables and the chance a shot lands

A decision weighs dozens of shots and their replies, too many flights to fly while the player waits, so the flying is done once at build time. Every shot is flown in each shape (pace and spin) from a grid of contacts to a grid of targets, for both balls. Each entry stores the ideal landing and net clearance, how small errors move them, second-order terms for larger errors, and how the wind changes all of it.

The launch wobbles across, up and in speed by a three-way normal distribution whose width is the player's skill for that shot. An awkward contact (late, jammed, stretched, on the move) widens it, and so do a harder pace, a disguised shot, pressure at game point against the player's composure, and a low sun. The chance of landing moves the landing at 1,024 fixed points of that distribution, taken from a Halton sequence (quasi-Monte Carlo), and has the referee call each. It draws no random numbers, so looking at a chance can't change a seeded game. The dice the game rolls use the same distribution, physics and referee, and a test holds shots in real rallies to landing as often as their chances said.

The strategy engine

Every player is a body moved by one law: react, brake whatever isn't toward the target, then run, within sourced reaction times, accelerations and top speeds. The minimum time to any point is closed-form, so reach is cheap to ask. An intercept search walks along the flight to find where a body can meet the ball, respecting the two-bounce rule and the kitchen, so no plan is a fault. A contact model then describes how the ball meets the body: height, lateness, stretch, balance, time to be set and incoming pace.

After a point, the breakdown says what cost it and what the better choice was.

For each of your options the engine finds every reply open to the opponent who meets it, forecasts where all four players will be, and combines it two shots deep: the chance the shot lands, times the chance nobody reaches it plus, for each reply, its likelihood times the opponent's chance of missing or the value of the moment if it comes back. Beyond two shots it uses a learned value of the moment, a logistic model over features such as time to spare, where all four stand, the ball's pace and height, wind, fatigue and pressure. As a weighted sum it splits exactly into what each feature contributed, which the Breakdown uses. The chance of winning the game from any score is solved by value iteration over side-out scoring.

The computer players use a softmax policy over each option's features, trained by expert iteration to imitate the look-ahead, sharpened or flattened by difficulty and leaned by persona, so a choice costs a table lookup and a small sum. Two-shot patterns, such as a soft ball to the backhand followed by a speed-up off the high reply, come from the look-ahead.

What each side knows

Each opponent has hidden traits for the game (backhand, footwork, composure, pace), drawn from their persona. The dice use the true values. Your side holds a belief about each trait, updated by Bayes' rule with every shot and run of theirs you see, and every number you're shown comes from the belief. Opponents learn your habits the same way: once they've seen enough, they start early toward your usual shot and stand a step toward it.

Learning the numbers

The game learns its numbers by playing itself, offline, with fixed seeds, so the same code always learns the same numbers. In order: the animation clips and shot tables are baked; rallies with a simple policy give a first value model; the full look-ahead on sampled decisions trains the policy; rallies with the learned policy refit the values with a two-shot temporal-difference term; and a calibration step corrects the look-ahead so a shown chance wins as often as it says. The long steps take 35 to 90 minutes on a laptop.

Real time

The game holds 60 frames a second on a phone. Work too big for one frame is split into slices under a 6 ms budget: a new rally is worked out up to your first decision before it is shown, and your plan cards are weighed step by step while the incoming ball is in the air. Players and courts are built ahead and pooled, so changing screens stays under 50 ms a frame, and every court effect is played once out of sight at startup so its shaders compile before anyone sees them.

Animation

Clips are data. Keyframed poses keep planted feet on their spots with two-bone inverse kinematics, keep the paddle arm clear of the body by measuring the paddle against elliptical sections of the trunk, and are baked into one binary file that loads in milliseconds. At runtime a foot lock pins planted toes and releases them smoothly, each swing is fitted to where the ball really is at contact, and inertialization blends the last pose into the next action so nothing snaps when one action cuts off another.

Look and sound

Everything is lit with one toon ramp: three steps from a cool shadow to a warm highlight, a rim light, and outlines scaled with camera distance to keep one width on screen. Colour regions painted into the models let one model take any skin, hair, eye or team colour. The cameras shift and widen so the court stays framed in whatever the panel leaves open.

Hits, bounces and footsteps are synthesized in code, and so is the music: a theme for the menu and one for each of the twelve courts, played in three layers that come in as a rally gets longer and peak at game point. The short cues for game point, a streak or a showpiece winner use recorded notes of a public-domain upright piano. The background sounds are public-domain field recordings, and the wind among them follows the gusts the ball flies through. Each voice line, the announcer's included, was recorded offline with an open-weight speech model copying one reference recording per voice. A limiter keeps sounds that pile up from clipping, including on the web, where browsers skip the audio engine's effects.

References