Skip to content
Games / Bash League
In development Free Builder Notes 100% AI while playing

Bash League

Like fantasy football, but the players are monsters. A private league for a friend group, run by a dice engine that an LLM only narrates.

by keytonw Django SimulationSportsStrategy Browser notes confirmed Sep 16, 2026
0props 0 comments

We never sell games. Links go straight to the maker's store page. Something wrong? Report it.

Bash League

Cover from bashleague.com, the maker's own public art. Yours and you'd rather it weren't here? Say so.

A fantasy-sports league for one group of friends. Everybody drafts a team of dungeon creatures, sets a card of three bouts a week, and Friday night decides it. The fights run on a deterministic engine with every die published, and the replays are public. The men, the picks and the trash talk are private to the league.

The rule I kept coming back to: the engine owns truth, the model owns flavour. Dice, state, legality and outcomes are code. The LLM calls the fight, plays the confidently-wrong heel, and answers rules questions in the asker's own words. It never decides a turn. It used to, for a while, and taking that away was the best decision in the project.

It is in development and invite-only, because it is for people who already know each other. The exhibition on the site is open to anyone who wants to see a fight.

Builder Notes

How it was made

DisciplineLevelTools · notes
CodeMostly AIClaude Code · Almost all of it, from a written spec. I read every diff and every test.
DesignAI helpedClaude Code · The rules are mine. Claude drafted alternatives, argued edge cases, and kept the decision register honest.
Writing and dialogueMostly AIClaude Code, LiteLLM · Fight narration, the heel and the rules bot are generated at runtime. Site copy is mine, with edits.
2D art and spritesAI helpedClaude Code · Fields are procedural SVG drawn by scripts the agent wrote. Creature art is licensed, not generated.
AI inside the gameMostly AILiteLLM · Commentary and the heel persona, over one LLM facade with per-call cost accounting.
Testing and toolingMostly AIClaude Code · A mutation-testing roster: break a rule on purpose, confirm the right test fails.
Pipeline
  1. 01Write the system reference document by hand: mission, design laws, every product rule.
  2. 02One implementation round per document section, against the document, with tests for each rule. (Claude Code)
  3. 03Break a load-bearing rule on purpose. Run the suite. Watch the right test go red. (Claude Code)
  4. 04Measure: fight batches, side bias, cap fit. Written up, dated, kept. (Claude Code)
  5. 05Narration last, over one model facade, with the engine already final. (LiteLLM)
What AI was great at

Implementing against a document. Given a spec that says exactly what the dice do, Claude Code wrote the engine, the tests, the migrations and the pages, round after round, and kept the conventions. Also: writing the procedural field art as scripts rather than drawing it.

Where it let me down

A green test suite is not evidence. Five review passes found nineteen real defects in the engine that the tests never caught: the fight still ran, still named a winner, and the log read perfectly. The habit now is to break a rule on purpose and watch the right test go red.

Human work

The product itself. Two system reference documents written by hand before any code, a register of every design decision, and the rule that the documents win when the code disagrees. Reviewing measurements, ordering the roadmap, playing the fights and reading the logs.

Advice

Write the spec first and make it the authority. Decide early what the model is allowed to own. Here it owns flavour and nothing else, and the day it stopped deciding turns the game got better and the bugs got findable.

What I'd do differently

Start with the narration plan instead of adding it after the engine. And keep the working notes short from day one; the first version of the traps file was 1,600 lines before it got rewritten.

Artifact · a real prompt
A green suite is not evidence here, and this is the single most expensive thing this project has learned. So the check is never 'do the tests pass'. It is: break a load-bearing rule on purpose. Run the suite. Watch the RIGHT test go red.
The one rule in the project's working notes for agents
Notes

The process log


on this site
The day the model stopped deciding turns

For the first two weeks the LLM picked the action each turn from a menu the engine enumerated. It was legal and it was legible and it was still wrong in ways nobody could see: a fight read perfectly and the tactics were nonsense.

So it lost the job. The engine picks now, with a playbook that is matchup-aware and measured. The model calls the fight and plays the heel. The fights got better in a week, and every remaining bug became something a test could name.

Comments 0

Say what you used. No tool-shaming, no scores, no drive-bys.
Ask how it was made, or say what worked for you.
Comments and props are for members. Joining takes a minute and costs nothing.