Learning to Play
A chess prodigy's handbook, three old games and one laptop: rebuilding the ideas behind game-playing AI in Rust for a browser on my phone, and measuring them.
| Duration | 22 minute read |
|---|---|
| Published | |
| Topics | Game AI, Machine learning, Reinforcement learning, Games, Rust, WebAssembly, History of technology |

This month I have been reading The Infinity Machine, Sebastian Mallaby’s biography of Demis Hassabis, the chess prodigy from North London who founded DeepMind, the laboratory behind AlphaGo and AlphaFold. I picked it up because I wanted to understand one of the early architects of the AI we now live with, told by someone who had thirty hours of his time, and because almost everything that interests me, games, simulations, the question of what a machine can learn on its own, runs through his story. A hundred pages in, there is a scene I have not been able to put down.
It is 1988 and Hassabis is twelve. He has bought a Commodore Amiga 500 with his chess winnings, and in Foyles, the big bookshop on Charing Cross Road, he finds a slim paperback: The Chess Computer Handbook by David Levy. He reads it in one sitting. Levy explains how a chess program is built from three parts. The board has to be turned into numbers. A function has to look at a position and say who is better. And a search has to try moves, and the replies to them, and the replies to those, cutting off the branches that are obviously bad because the tree grows faster than any computer can follow. Hassabis tries to build it, finds that the Amiga chokes on chess, and writes an Othello program instead, which beats his five-year-old brother.
I put the book down at that point, partly because I recognised the boy a little, and partly because I realised two things. The first is that those three parts are still the whole of a chess program. Thirty-eight years later, the strongest engines in the world are a board in numbers, an evaluation function, and a tree search with pruning; what has changed is that the evaluation function is now learned by a machine rather than written by a person, and that the machine learned it by playing against itself. The second is that the laptop on my desk has thirty thousand times the memory of that Amiga, and I had never built the three parts myself.
So I did, this month. I wrote three game engines in Rust, for chess, for Japanese shogi, and for Go, compiled them to WebAssembly so they play in a browser on my phone, and built the training loop that is supposed to make one of them stronger than I could make it by hand. The app is at kishi.raskell.io and the code is on GitHub. This is an account of why those three games, why those tools, and what happened when the ideas in the books met one ordinary machine.
The book, the man and the lab
Mallaby is not a technology writer by trade. He is a former contributing editor of the Financial Times, twice a Pulitzer finalist, now a senior fellow at the Council on Foreign Relations, and his earlier books were about money: hedge funds in More Money Than God, Alan Greenspan in The Man Who Knew, venture capital in The Power Law. That turns out to be the right background. The Infinity Machine is a biography and a company history at once, built on about thirty hours of conversation with Hassabis and more than a hundred interviews around him, and it takes the question of why someone would build a technology they believe to be dangerous as seriously as the question of how. It came out earlier this year. I am reading it slowly, and the AlphaGo chapters are still ahead of me, which I find I do not mind, because I would rather meet them with my own version of the thing running.
Hassabis, if you do not follow the field, is the person it now treats as its elder statesman, at fifty. Born in Finchley in 1976 to a Singaporean Chinese mother and a Greek Cypriot father, he was a chess master at thirteen and the second-strongest player of his age in the world. At sixteen he was co-writing Theme Park at the games studio Bullfrog, a game that sold millions. He read computer science at Cambridge, ran a games studio of his own for seven years, and then went back to university for a doctorate in neuroscience, because he thought the only way to build an intelligent machine was to understand the one existing example first. In 2010, in an attic on Russell Square, he founded DeepMind with Shane Legg and Mustafa Suleyman, at a time when almost nobody in the field believed that what they proposed was possible. The first real money came from a Peter Thiel fund whose partners rated the science A-plus and the business model an F.
DeepMind was conceived as a Manhattan Project for artificial intelligence, and its method is what connects the book to this article. The bet was to combine two branches of the field that were both unfashionable in 2010: deep learning, the layered neural networks Geoffrey Hinton had spent a quarter of a century defending, and reinforcement learning, in which a program learns from the consequences of its own actions rather than from labelled examples, with ideas from neuroscience on top. The proving ground was games, because games have rules you can write down and scores you can read off the board. The first result, shown in 2013, was one agent that learned to play Atari games from the pixels alone. Google bought the company in 2014. In 2016 AlphaGo beat Lee Sedol in Seoul, and in 2017 its successor, AlphaZero, learned chess, shogi and Go from nothing but the rules and games against itself, with one algorithm, and beat the strongest existing program at each. Those are the three games in this article, in that order, and self-play is the loop I built. AlphaFold followed in 2020, then the predicted shapes of two hundred million proteins, then the Nobel Prize in Chemistry in 2024. Even the name is a triple nod: to deep learning, to Deep Blue, and to Deep Thought, the computer in The Hitchhiker’s Guide to the Galaxy that was asked for the answer to everything.
Why am I reading it? Partly for the obvious reason: I work on AI platforms for a living and wanted the story of one of the architects of this revolution from the inside, and the book is exactly that and more. Partly because of the parallels, which kept catching me off guard: a games designer who smuggled a simulation into a theme park, a competitor who cannot pass a board game without wanting to win it, a man who thinks of the world as information and of the mind as something that builds reality rather than records it. I recognise more of that than is comfortable. And partly because of the belief. Hassabis believed in artificial intelligence when almost nobody did, with a conviction the book is honest enough to call close to religious, and he was right. There is a strand of transhumanism running through the story, from the Iain Banks novels he read at Bullfrog to the Singularity Summit where DeepMind found its first investor, and he keeps a dry British distance from the Californian version of it. I have a strand of my own, with a different spin and from a different direction, and that is a subject for another piece. It is enough to say here that I did not come to the book as a sceptic.
What hooked me in those early pages, more than the prodigy story, is how often games are the way in. Hassabis learns programming through chess. His first intelligent program plays Othello. At Cambridge he learns Go from a professor and takes shogi far enough to reach the top of the English rankings. His friend David Silver, who will later lead the AlphaGo work, finds his way into the field through a textbook on reinforcement learning, read in the south of France after their games company failed. Mallaby traces the thread back to Claude Shannon’s 1950 paper on programming a computer to play chess, which Levy’s handbook had introduced to the twelve-year-old. Shannon wrote that chess programs had no practical importance, but that mastering a game might serve as “a wedge in attacking other problems of a similar nature and of greater significance”. That sentence is seventy-six years old and still the best one-line justification I know for spending a month on board games.
My own games
My own chess is a smaller story. I joined a chess club in my early teens, played the regional tournaments, and did well in a few of them: nothing that would have sent a chess columnist across the hall to talk to my father, as one did for Hassabis when he was six, and nothing I would put in the same paragraph as his career if the book had not put the two of us in the same bookshop. But the game stayed. I do not turn down a game when one is offered; the last one was against a coworker and friend on Union Square in San Francisco, this year. I have a weakness for the big outdoor sets with knee-high pieces, and there are two I like, one in Lucerne and one beside the Rhine here in Basel. On trains I play on lichess on my phone. And I have enjoyed, more than I expected to, the odd second life the game found in the 2020s, when a television series about a fictional prodigy sent people out to buy boards and grandmasters turned into streamers with audiences no tournament hall could hold. I did not see that coming, and I am not complaining.
The other half of my gaming life is what German calls Aufbauspiele, the building games: Anno, Die Siedler, the whole tycoon genre, anything where you lay down a world with rules and watch it run. Hassabis’s Theme Park is one of them, which made that chapter feel personal. The visitors who get thirsty when you oversalt the fries and buy more drinks, the riders who are sick when the coaster is too fast, are exactly the kind of mechanism I play these games for. I like games best when they try to mimic reality and let a thick ruleset generate stories nobody wrote, which is why I love Dwarf Fortress, and it is why I keep building simulations of my own, from a dish of neurons that learns under stimulation to a terrarium left to evolve. A chess engine, seen from that side, is the smallest simulation worth building: a complete world with rules, and inside it an agent that has to learn.
Why games, and why these three
Shannon’s point is practical. A game like chess has rules you can write down completely, a result you can read off the board without argument, and a depth that no amount of study has exhausted. That combination is rare. Most real problems have fuzzy rules, contested outcomes and no yardstick. A game gives you a laboratory where a new idea can be tested in an afternoon, against centuries of human knowledge, and the answer is a number.
Chess, shogi and Go also happen to be the three games along which the history of this field unfolded, in that order, and each one broke what had worked on the one before. That is why I picked all three rather than one.
Chess came out of northern India around the sixth century as chaturanga, travelled through Persia into Europe, and took its modern form, with the long-range queen and bishop, in Spain and Italy at the end of the fifteenth century. It is the game Shannon chose, the game Levy’s handbook teaches, and the one the classical method of search plus evaluation was built for. In 1997 IBM’s Deep Blue beat Garry Kasparov by searching two hundred million positions a second on purpose-built chips, with an evaluation written and tuned by people. It was a triumph of the three parts and a disappointment to anyone hoping for insight: the machine won by looking further, not by understanding more. The interesting question, from Levy’s chapter onwards, was whether the evaluation function could be learned instead of written. For chess, that question was answered between 2018 and 2020 with a small neural network that lives inside the engine’s inner loop. It is called NNUE, and it was not invented for chess.
Shogi is the Japanese branch of the same family. It arrived in Japan by way of China and Southeast Asia by the eleventh century, took its present form by the sixteenth, and became an institution under the Tokugawa shoguns, who put the best players on stipends; the first Meijin, the title that still crowns a shogi champion, was awarded in 1612. Today it is played by millions in Japan, with a professional system, televised title matches, and a young star, Sota Fujii, who in 2023, at twenty-one, held all eight major titles at once. The board is nine by nine, each side has twenty pieces of eight kinds, and most of them promote when they reach the far third of the board. One rule makes it a different game. A captured piece changes sides, goes into the captor’s hand, and can later be dropped onto almost any empty square as a move. Nothing ever leaves the board for good, so the game never simplifies the way chess does. There are about eighty moves to choose from at a typical turn against chess’s thirty-five, the games are longer, and the endgame is a mutual race rather than a technical grind. For a programmer, drops make the evaluation function much harder to write by hand, which is why the learning happened here first. Computer shogi was transformed in 2006 by Bonanza, the first program whose evaluation was fitted to professional games rather than tuned by hand. In 2017 Ponanza beat the reigning Meijin, Amahiko Sato, and in 2018 Yu Nasu published the network design that Stockfish adopted for chess two years later. Shogi is where the idea I was chasing came from.
Go is older than both and simpler than either. It comes from China, where it is at least two and a half thousand years old and was counted among the four accomplishments of a cultivated person alongside music, calligraphy and painting; it reached Japan by the eighth century, where the Edo-period houses of professional players were funded by the shogunate, and it has deep roots in Korea, where it is called baduk. The rules fit on a card. Two players alternately place black and white stones on the intersections of a nineteen-by-nineteen grid. A group of stones with no empty points next to it is captured and removed. At the end, whoever surrounds more of the board wins, with a few points’ compensation to white for moving second. From those rules comes a game with around two hundred and fifty choices at every turn, games of two or three hundred moves, and positions that nobody has been able to score by hand. Levy’s three parts fail here. A search that looks four moves ahead in Go sees almost nothing, and there is no formula for who is winning to apply at the leaves. Go was the game that everyone in the field, including Hassabis, called the grand challenge, and it was the one DeepMind chose when it wanted to show what it had. The programs of the late 2000s had replaced the chess method with Monte Carlo tree search, which plays thousands of random games out to the end and counts who wins; that got to strong-amateur level and stuck. AlphaGo kept that search and gave it two neural networks, one to suggest moves and one to judge positions, trained first on human games and then on its own, and in March 2016 it beat Lee Sedol four games to one.
So: one game where the classical method works and the network replaces the evaluation; one where the same method strains and the network was invented; one where the method fails and the network has to guide the search itself. The three together are a short course in forty years of the field, and each one can be measured against opponents anyone can download.
Why I built it rather than read about it
Hassabis likes to cite Feynman’s line about not understanding what you cannot build, and it is the honest reason for this project. I have read the AlphaGo paper and the Stockfish NNUE write-ups more than once. I could explain the diagrams. I could not have told you what K is, or why a network that wins at equal search depth can lose at equal time, or how many hours of a laptop’s life a generation of self-play costs, because those are the things the papers leave out and the only way to learn them is to pay for them. Reading the book made the gap uncomfortable, and the same itch that makes me build terrariums wanted the world with the rules and the learner inside it running on my own machine.
The other reason is that the ingredients are, for the first time, all on my desk. The ideas are published and the reference implementations are open source. The laptop is a MacBook Pro with an Apple M4, ten cores and sixteen gigabytes of memory, which is not a research machine and has more general computing power than Deep Blue had. The browser on my phone can now run compiled code with vector instructions and real threads. And the writing of the code itself, which would have been a winter of evenings, took days with a coding agent, with me deciding what to build and the agent typing most of it. That belongs in the method: the agent wrote code, a match between two engines decided whether the code was any good, and the match does not care who wrote it.
Why Rust, and not PyTorch
The obvious way to do machine learning in 2026 is Python and PyTorch, and if the goal had been a model that answers questions on a server, that is what I would have used. The goal was an opponent on my phone, in a browser tab, offline, and that changed everything downstream.
A chess evaluation is called inside the search, about a million times a second, on one core, with no batching, rather than once per request. A network that lives there cannot be a model behind an API. It has to be a few hundred lines of arithmetic in the engine’s own language, run on integers, and updated incrementally as moves are made rather than recomputed from scratch, which is the whole trick of NNUE. The inference, in other words, had to be hand-written anyway. Once it was, the trainer was the same arithmetic run backwards, over a million parameters and inputs that are almost all zero, and it fitted in a few hundred lines too. Writing it is also how I found out what the framework would have hidden from me: the one constant I guessed instead of fitting turned a winning network into a losing one, and I would not have known why.
Rust is the language I write everything on this site in, from the neuron culture to the fantasy console, and it is the right tool for an engine for the usual reasons: no garbage collector in a loop that runs a million times a second, control over memory layout, and a compiler that produces WebAssembly with vector instructions from the same source as the native binary. One language runs from the self-play games on the laptop to the move on the phone, in one repository, and the web app has no build step. The trade-off is honest too. Training a small, sparse network on the CPU is fine. If the Go network ends up as a convolutional net with millions of dense parameters, Rust on ten cores will be slow, and I will have to decide whether to write a Metal kernel or admit that this is where the laptop study meets a GPU.
Why WebAssembly
Because the phone is the point. An opponent that lives on a server is not mine; an opponent in an app store is somebody else’s to approve. A web page that I add to my home screen, that works on a plane, and that runs the identical binary to the one on my laptop is the version I wanted, and in 2026 the browser can do it. WebAssembly has had 128-bit vector instructions for a while, and Safari now lets a page share memory between threads if it is served with the right isolation headers, so the chess engine on my phone searches on four cores. Lichess, the free chess site, runs Stockfish the same way for its analysis board, which was my proof that the approach was sound before I started.
The constraint also shaped the design more than any paper did. A network that has to be downloaded with the page and run on a phone has to be small; Kishi’s chess network is 820 kilobytes and is compiled into the engine binary. A search that has to run in a browser tab has to be frugal. Every decision that looks like taste in the code is really the phone saying no to something.
What happened
The chess engine came first: bitboards, a search with the usual family of pruning heuristics, and a hand-written evaluation borrowed from a well-known set of piece-square tables. Against Stockfish configured the way lichess configures its computer opponents, with twenty games a level on one core, it beats level 4 nineteen games to one, beats level 6 thirteen to seven, and loses to level 7 nineteen and a half to a half. If you have played the lichess computer, that places it: a solid club player, nowhere near the top.
Then the loop. The engine played itself from random openings for fifty-two minutes, which produced 5.6 million positions from fifty-seven thousand games, each labelled with what the search thought of it and how the game ended. A network trained on those positions in under twenty minutes beat the hand-written evaluation it replaced by 85 rating points, plus or minus 32, when both sides were allowed the same number of positions to look at. When both sides were allowed the same number of milliseconds, they came out even, because the network costs two and a half times as much per position. That is the whole problem of this kind of learning in one sentence, and I did not understand it before I had the numbers.
Shogi got its own engine with the same shape and a hand-written evaluation, which beats Fairy-Stockfish’s weakest setting twenty games to none and loses to a middling one eighteen to two. Go got the method of the late 2000s, Monte Carlo tree search with the shape patterns from the old MoGo program, and against GNU Go at its lowest level, with a second a move, it wins three games in ten. All three play on the phone. The chess one is the only one I would call a satisfying opponent at the top levels, and that is with the hand-written evaluation, because the trained network has not yet earned its place on the clock.
What this opened up
I started with one question, whether I could build Levy’s three parts, and I have ended the month with five better ones.
The chess network wins at equal search and draws at equal time. Does that change after more generations of self-play, as the games it learns from get stronger, or is a laptop-sized network always going to be paying for its own cost? The loop is running as I write this, at low priority, so the laptop stays usable. Why did one constant swing the result by 176 rating points, and what does that say about the contract between a learned component and the hand-tuned system it plugs into? Does the same loop work for shogi once the network can see where the kings are, which is what Nasu’s original design did and mine does not yet? Go needs the second kind of loop, where the search teaches the network which moves to look at, and I do not know what a laptop can train on a full nineteen-by-nineteen board; the AlphaGo chapters of the book, which I am about to reach, will tell me what it took in 2016, and I want to know what it takes in 2026 on a machine from a shop. And underneath all of it: how much of an engine’s strength survives the trip from a native binary to a browser tab on a phone, and what threads buy back.
Each of those is a few days of work and a few numbers, and I have started keeping a notebook in the repository so that the numbers are written down as they arrive, failures included. If the answers turn out to be as interesting as the questions, this may become the first of several pieces, one idea at a time, chess first, then shogi, then Go. Let’s see.
References
- Sebastian Mallaby, The Infinity Machine: Demis Hassabis, DeepMind, and the Quest for Superintelligence (Penguin Press, 2026), chapters 1 to 5.
- Claude Shannon, Programming a Computer for Playing Chess, Philosophical Magazine (1950).
- David Levy, The Chess Computer Handbook (Batsford, 1984).
- Yu Nasu, Efficiently Updatable Neural-Network-based Evaluation Functions for Computer Shogi (2018, in Japanese); Stockfish, Introducing NNUE Evaluation (2020).
- David Silver and others, Mastering the game of Go with deep neural networks and tree search, Nature (2016).
- Kishi: the engines, the training loop, and the notebook of every run.