TournamentAI: Self-scripting bots playing tennis

September 1, 2026

TournamentAI: Self-scripting bots playing tennis

Is TournamentAI worth developing?

What came of the day

Yes. TournamentAI is worth developing far enough to test it in the real world. Today began with a broad idea: use a tennis metaphor to create a machine-learning system where Players train Rackets at home and eventually bring them to public tournaments. By the end of the day, that idea had become a coherent computational model. We defined Balls and Ball Numbers, separated Players from Rackets, designed the beginnings of a purpose-built Racket Language, chose atomic one-operation instructions, explored the Line Library, connected the approach to Linear Genetic Programming, made home CPU/GPU training and massive parallel evaluation foundational requirements, and developed a tennis-style competitive fitness model in which one Ball stays in play throughout a point and each return must predict its hidden Ball Number more accurately than the previous shot. The most important result is not that TournamentAI has been proven to work. It has not. The result is that the idea survived serious examination and became more interesting, technically plausible, and experimentally rich as we pushed on it. TournamentAI has earned another Obsession.

The story

TournamentAI started the day as an ambitious idea built around a tennis metaphor. I had reserved tournamentai.com and imagined people training machine-learning Players at home, then bringing them online to compete. The question for the day was simple: Is this actually worth developing? The breakthrough was realizing that the metaphor could become part of the computation itself. A Ball became 99 sequenced numbers with a hidden 100th number. A Racket became a tiny mathematical program trying to predict it. A Player became the intelligence capable of changing that Racket and its Strings through training. From there, the idea kept getting more concrete rather than falling apart. We initially considered using an existing programming language such as PHP, but that led to a better idea: TournamentAI should define its own tiny Racket Language. Every Racket can live inside the same constrained mathematical universe, built from simple atomic instructions. That led us into the existing world of Linear Genetic Programming and showed that part of what we were imagining already has a serious research foundation. The tennis side changed too. At first, competition might simply have meant comparing two predictions. Then the point itself became a rally. One Ball stays in play. A Player serves with a prediction. To return it, the opponent must make a prediction closer to the hidden Ball Number. The same Ball remains in play, Variable Strings can retain state during the point, and each Player can see the opponent’s previous shot. Suddenly the opponent is not only something to beat — the opponent is providing information. By the end of the day, TournamentAI had become much more than the idea I started with. We had a plausible computational model, a path toward massively parallel home CPU/GPU training, a clearer understanding of what is established research and what may be distinctive about this system, and a concrete next problem to solve. We did not prove that TournamentAI will work or that people will care about it. But the idea survived a day of serious examination and became stronger as we pushed on it. That was enough to answer the original question. TournamentAI is worth continuing.

Discoveries

  • A Racket should not use a general-purpose programming language directly.

    TournamentAI benefits from a tiny purpose-built Racket Language whose valid program space is deliberately constrained and enumerable.

  • Atomic instructions

    One operation per line, with no nested expressions — make Rackets easier to generate, mutate, execute, analyze, and massively parallelize.

  • The underlying Racket representation overlaps strongly with Linear Genetic Programming.

    That gives TournamentAI an existing research foundation instead of requiring every low-level idea to be invented from scratch.

  • Competitive fitness may be much more interesting than simply minimizing prediction error.

    A tennis rally can become a real computational mechanism: one Ball stays in play for the point, and each successful return must predict its hidden Ball Number more accurately than the previous shot.

  • Keeping Variable Strings alive throughout a point

    Along with exposing the opponent’s previous prediction to the Racket, turns the opponent into both competition and information. The Racket can adapt during a rally rather than repeating a static prediction.

  • The simplicity and regularity of the Racket Language make large-scale local training plausible.

    TournamentAI should be designed from the beginning around massive parallel CPU/GPU evaluation on ordinary home hardware.

Results

  • TournamentAI Foundational Concept & Training Model v0.1

    Established the first coherent technical model for TournamentAI: Balls and Ball Numbers, Players, Rackets and Strings, the purpose-built atomic Racket Language, competitive rally mechanics, persistent point state, the Line Library concept, and the requirement for massively parallel home CPU/GPU training.

    Open the file

  • Reasoning Journey

    Preserved the reasoning journey behind today’s work: the ideas we explored, challenged, changed and ultimately kept, including the transition from a general-purpose language to Racket Language and the breakthrough of using one Ball for an entire competitive rally.

    Open the file

  • Handoff For Next Steps

    Created a clean handoff for continuing TournamentAI without reconstructing today’s work, including the current canonical assumptions, unresolved decisions and the recommended next question: “What exactly is Racket Language v0.1?”

    Open the file

Open threads

  • Define Racket Language v0.1: finalize the instruction format, allowed operations, numeric semantics, legal operands, maximum Racket length, and protected-math behavior.
  • Define the first Training system: decide how Players generate, mutate, select and preserve Rackets and Racket Strings across generations.
  • Test competitive fitness: determine whether tennis-style head-to-head evolution actually produces stronger predictors than direct optimization of prediction error.
  • Define training opponents and evolutionary ecology: how Players are paired, whether champions are preserved, how historical opponents are used, and how cycling or loss of progress is prevented.
  • Finalize Racket state: confirm the exact roles and initialization of Variable Strings and Constant Strings, persistence during a point, and whether inputs such as the incoming shot and serve state are sufficient.
  • Design the Line Library: decide whether the complete legal line space should be materially stored, generated mathematically on demand, or combined with a learned metadata/history layer.
  • Build and benchmark the execution engine: prove that large populations of Rackets can be evaluated efficiently on ordinary home CPUs and GPUs through massive parallel execution.
  • Define the authoritative tennis game and tournament rules: points, games, sets, matches, serving, Aces, Winners, errors, ties and other edge cases.
  • Build the public ecosystem: create the path for someone to train a Racket at home, export it, upload it to tournamentai.com, enter a public tournament and receive reproducible public results.