5x5 Go
Two playable 5x5 Go demos: a self-contained 2-ply minimax bot in one HTML file, and the same UI fronted by KataGo running on a small VPS.
Overview
A pair of single-page Go demos at go-5x5.danieljohnmorris.com (custom 2-ply bot) and go-5x5-katago.danieljohnmorris.com (KataGo backend). The full rules engine, scoring, and rendering live in one HTML file each. The KataGo version adds a FastAPI subprocess wrapper and a multi-stage Dockerfile that compiles KataGo from source for the ARM VPS the rest of the site runs on.
A 5x5 Go game playable in the browser, built in two parts. Part 1 is a self-contained 2-ply minimax bot in a single HTML file. Part 2 keeps the same frontend but replaces the local bot with a server-side KataGo backend.
Part 1: 2-ply minimax in one HTML file
index.html holds the SVG board, the rules engine (capture, suicide, simple positional ko), Chinese area scoring with 2.5 komi, and a 2-ply minimax bot. For each candidate move the bot simulates Black’s best reply and uses that score as the move’s value. Pass is treated as a candidate move, so the bot resigns naturally whenever no real move beats passing.
The first version was 1-ply and placed stones directly into capture because static evaluation cannot tell the difference between a future-captured stone and a stone in real territory. The second ply of lookahead fixes that in about 30 lines of code.
Part 2: KataGo behind a FastAPI server
Play · Server · Frontend · Post
Same frontend, with aiTurn() swapped for an HTTP POST to a FastAPI server that fronts KataGo’s JSON analysis engine. The server is a 60-line subprocess wrapper: spawn katago analysis, spin up one reader thread that pulls JSON lines off stdout and routes them by id, and synchronise stdin writes behind a lock.
The Dockerfile is multi-stage. The first stage compiles KataGo from source with the Eigen backend (the GitHub releases only ship linux-x64 binaries, and the VPS is aarch64). The second stage starts from python:3.11-slim-bookworm and copies just the binary across so the toolchain does not end up in the deployed image. Build time is about 4 minutes per Dockerfile change.
KataGo on the ARM CPU with 32 visits takes 2.5 to 4.5 seconds per move, depending on tree depth. That is slow enough that the frontend shows a “KataGo thinking” indicator on the board. The same calls take ~150 ms locally on an M3 Max with the Metal backend, so the post-deploy latency is dominated by the lack of vector instructions on the box rather than any inefficiency in the wrapper.