🃏 Classic500China, roughlyBRUTALGo rebuild deck
BRUTAL
Two rules and a grid, and both of the things you need are hard: scoring a finished board requires deciding which groups are dead, which is a judgement humans make by eye and machines cannot do reliably, and a strong opponent needed neural networks and self-play because the position count defeats search outright.
The hard part is not game design at all.
Brutal, but not for the usual reason. The board is genuinely a weekend and the rules are two paragraphs. What makes it brutal is that the two remaining pieces are both research-grade: scoring needs life-and-death judgement that servers hand back to humans, and strength needs self-play neural networks that took a lab to produce. The right build is a beautiful client that speaks GTP, and then you get a professional opponent for free by running someone else's engine behind it. Trying to write the engine yourself is the trap.
- Difficulty
- BRUTAL · 5 of 5
- First playable
- A project
- The original
- 2 team-years
- Released
- 500 · Classic
- Genre
- Strategy
Build a Go board and client. Vanilla JS, Canvas 2D. Be explicit that the engine is a separate concern from the board. Requirements: - 9x9, 13x13 and 19x19 boards. Stone placement, group detection by flood fill, liberty counting, capture on zero liberties, suicide prevention, and ko via positional superko — hash every board position and refuse any move that recreates one. - Territory counting under both Japanese and Chinese rules, with komi. Show the two scores side by side, since they differ and players will assume a bug otherwise. - Dead stone marking at the end is a manual, agreed step, exactly as it is on real servers. Offer an automatic guess by running a fast playout from the final position, but let either player override it. Do not pretend this is solved. - SGF import and export, move tree with variations, and navigation through a game record. - For the opponent, define a GTP interface and speak it. A local engine binary such as KataGo drops in behind it and plays at professional strength. Ship a weak built-in fallback for offline play and label it honestly as weak. - Board rendering that respects the conventions: wood grain, star points, stone shadow, the last-move marker, and a subtle indicator for stones in atari on a toggle for beginners. Definition of done: superko correctly refuses a repeating position in a triple ko, Japanese and Chinese scoring agree on who won, and KataGo plays through the GTP interface without the board knowing anything about it.
- A strong opponent, full stop — this is the one game on the list where the AI is a research programme and not a weekend, and the honest move is to embed an existing engine
- Automatic scoring you can trust, since life and death of unsettled groups is genuinely ambiguous and even servers ask players to agree
- Handicap and rank matching, which is what makes Go playable across skill gaps and needs a rating system and a population
- Any hope that a hand-rolled minimax will play above beginner level, no matter how deep you let it search
Ship the interface, speak a protocol, borrow the intelligence
The reflex on any AI-heavy game is to build the AI. Go is the clearest case where that is the wrong call — an existing engine is decades ahead of anything you will write, it is free, and it already speaks a documented text protocol. Design the boundary first and your client becomes engine-agnostic: you can swap in something stronger, run two engines against each other, or fall back to a weak local one, and none of it touches your board code. Most games with a hard AI problem have an equivalent protocol sitting there — chess has UCI, Go has GTP.
ScopeA weekend— build just this, not the game
Build an engine-agnostic board client as a single self-contained web page plus a thin local bridge. JS on the front, any runtime for the bridge. - Pick a game with a standard engine protocol — GTP for Go, UCI for chess. - The client knows only the protocol: it sends positions and receives moves, and holds no evaluation logic of its own. - The bridge is a tiny WebSocket server that spawns an engine binary and pipes text both ways. - Support hot-swapping the engine mid-game from a dropdown, and an engine-versus-engine mode where two different binaries play each other while you watch. - Display whatever analysis the engine volunteers — win rate, principal variation, candidate moves — without the client knowing what any of it means. Definition of done: I swap engines mid-game from the dropdown and the client neither notices nor cares.
Not a clone — Go 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.
Static Flatland
Go, but 2D instead of 3D, set in a cyberpunk sprawl. Rendered in 16-colour pixel art.
Build a browser game called "Static Flatland". The pitch in one line: a strategy in the spirit of Go, but 2D instead of 3D, set in a cyberpunk sprawl. WHAT THIS IS Take the SHAPE of Go — 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 2D instead of 3D. Canvas 2D and sprites. The mechanics survive the dimension drop; the asset budget falls by an order of magnitude. 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 cyberpunk sprawl. Permanent night and rain, neon as the only light source, and wet reflective surfaces doing most of the visual work. 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 16-colour pixel art. A fixed 16-colour palette (start from a Lospec palette), a hard pixel grid, and no sub-pixel movement — snap all rendering to whole pixels. 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.
- KataGo — a top open-source engine; run it and talk to it over GTP rather than writing your own
- Sabaki — an open board GUI and SGF editor to learn the interface conventions from
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 2 team-years to the counter on the homepage.
Then try these
Questions
How hard is Go to rebuild with an AI agent?
Yes — every game is buildable at some scope. The question is how hard, and Go is BRUTAL (5 of 5). The hard part is not game design at all. Two rules and a grid, and both of the things you need are hard: scoring a finished board requires deciding which groups are dead, which is a judgement humans make by eye and machines cannot do reliably, and a strong opponent needed neural networks and self-play because the position count defeats search outright. Reckon on a project to something you can actually play — not to something that matches the 2 team-years China, roughly spent.
What makes Go hard to rebuild?
Two rules and a grid, and both of the things you need are hard: scoring a finished board requires deciding which groups are dead, which is a judgement humans make by eye and machines cannot do reliably, and a strong opponent needed neural networks and self-play because the position count defeats search outright. That is why it sits at BRUTAL rather than a tier either side of it. If you want the idea without the project, the transferable part is ship the interface, speak a protocol, borrow the intelligence — a weekend of work.
How long does it take to build a Go clone?
Wrong question, and it is worth saying why. Nobody rebuilds Go — the original took China, roughly on the order of 2 team-years, released in 500 on Classic. What you can do is reach something playable and genuinely yours in about a project, 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 Go?
A strong opponent, full stop — this is the one game on the list where the AI is a research programme and not a weekend, and the honest move is to embed an existing engine. Automatic scoring you can trust, since life and death of unsettled groups is genuinely ambiguous and even servers ask players to agree. Handicap and rank matching, which is what makes Go playable across skill gaps and needs a rating system and a population. 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.