Causal Blocks: A Causal Inference Game, Built with AI and Shaped by Playtesting

Solution Overview

“Correlation is not causation” is one of the first things anyone learns about data. What to do instead usually isn’t taught at all. Most analytics courses teach estimation in depth, then leave students with a rule of thumb: when in doubt, control for more variables. That rule can quietly change the question being answered, or create bias that wasn’t there.

Causal Blocks is a game that teaches the alternative, causal inference, to anyone aged 12 and up. Every case starts with a claim that one thing causes another. Players draw a map of what they think is going on, test it on the data, and catch the characters who make fake links. Those characters are the causal roles, given personalities: Mr Confounder, a puppet master who pulls two strings at once; Ms Mediator, who carries the message from cause to effect; Mr Bouncer, who decides who gets into the data. Players collect them in a casebook and start spotting them in their own lives.

The curriculum runs to 28 cases across four tracks, from made-up puzzle worlds where the right answer is known to real research data. Nine are playable today.

How It Was Built

The whole game is written by a coding agent (Claude Code, running Opus 5.5). I don’t write the code. I decide what gets built and in what order, and I play every version. The order was deliberate: settle what is expensive to change first, then automate what is cheap to repeat.

The interaction. First, drawing a causal map had to feel good: dragging blocks, drawing arrows, seeing the estimate respond. Nothing else matters if that isn’t fun.
The steps of a level. With drawing working, each idea got its own screen: naming the role each block plays, then a separate screen for freezing (holding a variable fixed so you compare like with like). Before any of that, an introduction and a short animation turn the dataset into a real place in the player’s mind. Each level ends with a concept-checking question: a short question that shows whether the idea landed, not just whether the answer was right.
Mini-games. Short games between levels practise the main moves on made-up examples and keep the game from feeling samey.
Two reference levels. I finished one medium level and then one expert level in full. The expert level settled the console: the data packet, the casebook and the controls every level shares.
The curriculum. Then I mapped the whole game, idea by idea, to make sure everything I wanted to teach could be taught, in order, one new idea per level.

In parallel, I had already reviewed 15 to 20 public datasets as Jupyter notebooks, each with candidate causal diagrams and DoWhy estimates, then matched them to the curriculum. Some are simplified to fewer variables so they stay playable.

Both of those workflows are now Claude Code skills: one turns a new dataset into a reviewed notebook, the other turns a notebook and a curriculum slot into a level. Generating a level takes three or four minutes. Twenty or fifty more levels is a playtesting question, not a building one.

Where AI Helps, and Where It Doesn’t

The agent is very good at building. It can try an idea in minutes, and rebuild a screen as many times as it takes. A second model (Fable) reviews the curriculum, and its review shaped the version of the maths written for older players.

What AI can’t yet do well is pedagogy. It doesn’t know what a 12-year-old doesn’t know, so it skips steps, uses a word before it has been taught, and puts two new ideas on one screen. Early on, one level asked players to “freeze” a variable before the game had shown them what a fair comparison looks like, and a first-time player had no idea what to do. The fix wasn’t code. It was a curriculum rule, “scaffold before jargon”: players now compare look-alike twins before they ever hear the word “freeze”. Rules like that are written into the curriculum the agent works from, so each lesson learned in play changes every level built afterwards.

The Playtesting Cycle

Every level goes through the same cycle before it ships:

Generate. The agent builds the level from its notebook and its slot in the curriculum.
Expert play-through. I play it as the learning designer, bringing ten years of curriculum and course design. I look for jumps in difficulty, ambiguous wording, and places where the scaffolding runs out. The hard levels, like the ONS towns data, meant exploring the dataset with the agent: freezing different variables, watching the estimates move, and working out exactly what each character in the map was doing. I learned a great deal of causal inference this way.
Cold play-through. Someone who has never met causal inference plays it without help. Wherever they get stuck is a gap in the design, not in the player.
Fold it back. Fixes go into the level, and anything general goes into the curriculum and the skills, so the next level starts better.

The cycle is getting faster. With a finished medium level and a finished hard level as models, new levels arrive with far less to fix. The next step is a small team of playtesters across ages and backgrounds, so each level is tested by more than one beginner before it ships.

The Analytics Underneath

The game looks playful, but the numbers are real:

DoWhy in the browser. DoWhy, the open-source causal inference library started at Microsoft, decides what a causal map says you must control for. Its rules were ported to JavaScript, and automated tests check the port against DoWhy itself on 600 randomly generated graphs.
Every answer worked out in advance. Each level’s estimates are computed ahead of time, so the game answers instantly and needs no server to do statistics.
Tests that check the teaching. Every level is tested for fairness: the right map always wins comfortably, and every trap the level sets clearly loses, so random noise can never decide a level.
Built to scale. Each level’s content is served separately from the game code, so levels can later be put behind a login without touching the game.

Inspiration

The project started with a dataset. In July 2023 the ONS published Why do children and young people in smaller towns do better academically than those in larger towns? The title asks a causal question; the article answers it with correlations. Drawing the causal map shows something else: the small-town advantage runs almost entirely through deprivation, and among equally deprived towns, larger ones come out ahead. That gap, between the question people want answered and the methods they are taught, is why I built Causal Blocks. The towns are now an expert level in the game.

What’s Next

More levels. Filling the remaining cases on the learning journey, at the pace playtesting allows.
A playtesting team, as above.
The same characters, other subjects. The cast is a way of teaching reasoning, not just statistics. The same approach could teach logical fallacies, chance and probability, or how to think about investing.