🃏 Classic1926Mesopotamia, roughlyHARDBackgammon rebuild deck
HARD
Twenty-four points and two dice, so the board is an afternoon and legal move generation is a small tree — then the doubling cube arrives, and a bot that plays the checkers perfectly while doubling badly loses money to a bot that does the opposite.
You will get the loop working. Then the real work starts.
The reason this sits at hard rather than fiddly is entirely the cube. Checker play from a decent evaluation function is a weekend and will beat most casual players. Cube decisions require estimating not just whether you win but by how much, since gammons change everything, and that means rollouts. Ask for the cube explicitly and early — bolted on afterwards it will be wrong in ways you cannot see from playing.
- Difficulty
- HARD · 3 of 5
- First playable
- A weekend
- The original
- 1 team-years
- Released
- 1926 · Classic
- Genre
- Strategy
Build backgammon with a competent AI and a working doubling cube. Vanilla JS, Canvas 2D or DOM. Requirements: - Standard board, 15 checkers a side, bear-off, the bar, hitting and entering. Doubles play four moves. Generate all legal move sequences for a roll, including the rule most clones miss: if only one of the two dice can be played, you must play the higher one. - Move input by click or drag with legal destinations highlighted, and an undo within the turn before committing. - Evaluation function over the position: pip count, blots weighted by direct and indirect shot probability, points made in the home board, anchors, and checkers trapped behind a prime. Search one ply with a rollout of a few hundred random continuations for the top candidate moves. - The doubling cube is the part to get right, so build it explicitly. Estimate win probability from rollouts, split it into plain wins, gammons and backgammons, and decide double or take against the standard thresholds — roughly take up to 75% losing chances, double around 70% winning. Show the estimate and the decision reasoning on a debug panel. - Match play to a target score with the Crawford rule, because cube strategy at match score is a different game to money play. - Pip count displayed for both sides at all times, and a per-move equity delta so you can see when you blundered. Definition of done: the bot takes a double it should take and drops one it should drop, and the debug panel shows the win-probability estimate behind each.
- Cube handling that is actually correct — the checker play is the easy half and every clone gets the cube wrong
- Playing for something, which is what the cube exists to express and what makes the game tense
- An opponent at world level, which took neural networks and self-play to reach and is not arriving in one prompt
A stake that either player can raise, and the other can refuse by conceding
The doubling cube is the most underused mechanic in game design. It costs nothing to implement, adds no rules to the base game, and converts a dice game into a game about your read of the position — you are not asking who will win, you are asking whether the other player knows. Any game with a rough sense of who is ahead can carry one, and it makes a losing position interesting because conceding cheaply is a real skill.
ScopeAn evening— build just this, not the game
Build a doubling cube layer over a trivial game as a single self-contained HTML file. No dependencies. - The base game can be nearly anything with a swing: a race to 100 by dice roll is fine. - A cube starting at 1. Before their roll, the player who owns the cube (or either, at the start) may offer to double the stake. The opponent either takes, gaining ownership of the cube, or drops and concedes the current stake. - Track a bankroll across many games so a bad take actually costs something visible. - Show the true win probability from the current position, computed exactly or by simulation, but behind a toggle that is off by default. Log every cube decision against what the correct one was. - After ten games, report how much bankroll was lost to cube errors versus to the dice. Definition of done: the report shows me losing more to bad takes than to bad luck, which is what actually happens.
Not a clone — Backgammon re-themed and cut down to something you can finish. The angle is the important reel: it is what turns a project into a weekend. 5,880 ways to land.
Gumshoe Turn Order
Backgammon, but turn-based instead of real-time, set in a noir city. Rendered in Game Boy four-shade green.
Build a browser game called "Gumshoe Turn Order". The pitch in one line: a strategy in the spirit of Backgammon, but turn-based instead of real-time, set in a noir city. WHAT THIS IS Take the SHAPE of Backgammon — its core loop, and whatever makes that loop good — and rebuild it as your own game in a different world at a smaller scope. Use your own names, art and audio, which you want anyway: a reskin of somebody else's game is less interesting than a new one that works the same way. THE ANGLE — this is the important constraint, honour it above everything else Turn-based instead of real-time. Time only advances when the player acts. Removes every timing, netcode and animation-blending problem and turns reflexes into decisions. This is what makes the project finishable. If a decision would push the scope back towards the original's, take the smaller option every time. THE THEME A noir city. Rain, venetian blinds, and information as the only currency. Everyone is lying by omission and the player must notice which parts. The theme is not a coat of paint. Let it change what the mechanics mean — a reload, a health pack and a locked door should all be things that make sense in this world and nowhere else. LOOK Game Boy four-shade green. A strict four-colour palette, 160×144 internal resolution scaled up with nearest-neighbour, and no anti-aliasing anywhere. REQUIREMENTS - Runs in a browser with no build step. Canvas 2D unless the angle genuinely requires 3D, in which case three.js. - Fixed-timestep update loop with interpolated rendering, so it behaves the same at 60Hz and 144Hz. - Every tuning constant in one CONFIG object at the top, exposed as live sliders in a debug panel. You will find the feel by dragging those, not by prompting. - All content — levels, entities, balance numbers — in JSON or plain data files, never inline in the logic. - Audio generated with the Web Audio API rather than asset files. - Respect prefers-reduced-motion: keep the fades, drop the shake and the parallax. BUILD ORDER 1. The core loop with placeholder rectangles, at the reduced scope the angle demands. No theme, no art, no audio. Make it fun as rectangles first. 2. The angle's consequences. Cutting to bots, or to turn-based, or to one level changes the design rather than just shrinking it — find out how and rewrite step 1. 3. The theme, as content and data. 4. The look, applied last as a rendering layer over a game that already works. Start by writing a one-page plan: the core loop, what the angle removes and what that frees you to do properly, and what you are deliberately leaving out. Wait for me to approve it before writing code.
Half the time one of these already does what you wanted, and the other half it saves you a week of solving a problem someone documented in 1997.
One count per game. No account — it is tied to a salted hash of your IP, which is not stored in a form anyone can reverse. Every build adds 1 team-years to the counter on the homepage.
Then try these
Questions
How hard is Backgammon to rebuild with an AI agent?
Yes — every game is buildable at some scope. The question is how hard, and Backgammon is HARD (3 of 5). You will get the loop working. Then the real work starts. Twenty-four points and two dice, so the board is an afternoon and legal move generation is a small tree — then the doubling cube arrives, and a bot that plays the checkers perfectly while doubling badly loses money to a bot that does the opposite. Reckon on a weekend to something you can actually play — not to something that matches the 1 team-years Mesopotamia, roughly spent.
What makes Backgammon hard to rebuild?
Twenty-four points and two dice, so the board is an afternoon and legal move generation is a small tree — then the doubling cube arrives, and a bot that plays the checkers perfectly while doubling badly loses money to a bot that does the opposite. That is why it sits at HARD rather than a tier either side of it. If you want the idea without the project, the transferable part is a stake that either player can raise, and the other can refuse by conceding — an evening of work.
How long does it take to build a Backgammon clone?
Wrong question, and it is worth saying why. Nobody rebuilds Backgammon — the original took Mesopotamia, roughly on the order of 1 team-years, released in 1926 on Classic. What you can do is reach something playable and genuinely yours in about a weekend, and then keep going for as long as it stays interesting. Any figure that claims otherwise is measuring a prototype and calling it a game.
What do I lose by building my own Backgammon?
Cube handling that is actually correct — the checker play is the easy half and every clone gets the cube wrong. Playing for something, which is what the cube exists to express and what makes the game tense. An opponent at world level, which took neural networks and self-play to reach and is not arriving in one prompt. Those are the parts a prompt will not hand you.
Which AI coding agent should I use to build it?
Any of Claude Code, Codex or Cursor will handle this prompt. Paste it as your first message, let the agent scaffold the project, then iterate on feel — the second, third and tenth prompts are where a game actually gets good. Work in an empty folder or a fresh git branch so you can throw it away cheaply.
One email when new games go on the list. No other reason to email you, ever.