What it is
Domesday is a grimdark life-simulation game: you head a peasant household on an English manor in the years after the Norman Conquest (1068–1086), trying to keep your family fed, warm, and free through eighteen brutal years until the Domesday survey. It runs in any web browser as plain static files — vanilla HTML, CSS, and JavaScript, no framework, no build step.
The mission: history you can feel
Beneath the game is a teaching purpose: to convey, honestly and without romance, what life was actually like for an ordinary household under the Norman manorial system — the open-field farming, the dues and the yoke, the hunger gap of late spring, the Harrying of the North, the slow slide from a free man to a bondman, and the texture of faith, law, and rumour that framed it all. You don’t read about the period so much as live inside its constraints, and learn it by being subject to it.
The teaching is built into the systems, not bolted on:
- Every event and rumour carries a real footnote. Behind the story moments sits a teaching note — the actual history the moment is drawn from — surfaced in the journal so you can check what was genuinely so (and, for the deliberately garbled rumours the vill believed, what really happened).
- A built-in encyclopaedia. A living Codex of 200+ entries explains the manor, the open fields, the ranks and dues, the calendar and the beliefs — each with a “how we know” note, and each honest about where a detail is uncertain or simplified for play.
- A real chronicle running alongside. A timeline carries genuine Anglo-Saxon Chronicle entries year by year, so your household’s small story plays out against the recorded history of the realm.
- Historical integrity over convenience was a hard rule throughout: period accuracy was chosen over an easier mechanic again and again, and anachronisms were hunted down and removed (right down to the shape of a peasant’s house and the glaze on a window).
The short version
The game was designed and directed by one person, who used AI coding agents as the build team. The vision, the historical subject, the grimdark tone, the mechanics, the difficulty, the writing’s voice, and every judgment of “is this good enough” are the creator’s. The AI did the typing, the testing, and a great deal of the legwork — but it was building someone’s game, to someone’s standard, the whole way through.
The interesting story here is really about how a single creator can direct a tireless, self-checking build team to produce something far denser than they could alone — without losing authorship of it.
The human’s role — the centre of it
Everything started and ended with the person directing it. Concretely, they:
- Conceived the whole thing — a peasant life-sim set in the Harrying of the North and the Domesday survey, grim and historically honest rather than romantic. That premise, tone, and ambition are the design.
- Made every design and balance call. How hard should it be? (A skilled player should survive this often, and the real game is the slow slide from freedom to bondage, not just staying alive.) What’s the heart of it? What’s worth building next? The AI proposed and implemented; the creator decided.
- Set the standard and held it. Hundreds of small judgments — “this advice contradicts my full larder,” “the gallows is floating in front of the castle, put it here,” “this reads as a muddy list, commit to one thing” — came from the creator playing the game with a careful eye and refusing to let things slide.
- Playtested continuously and drove the iteration — often by sending an annotated screenshot of the exact problem, which the AI would then trace, fix, and prove with a test in minutes.
- Designed the working method itself — the parallel-agent setup, the roles, the rules that keep the AI honest (below).
- Owns the taste and the history — the sober tone, the refusal of anachronism, the hundreds of period details, the editorial voice. That is a person’s, not a model’s.
In short: the AI is the labour and a lot of the mechanism; the authorship, the direction, and the quality bar are human.
The build team they directed
To execute that vision quickly, the creator ran several Claude Code agents in parallel, each in a defined lane — one for the simulation and writing, one for the visuals, one for testing and playtest, one for preparing the artwork. Some run locally, on the creator’s own machine (so they can render and screenshot the game as it actually runs and check it by eye); others run in the cloud.
They coordinate entirely through GitHub — there is no central server. Each agent commits small, reviewed changes to one shared code repository, and writes what it has done and what it needs into a coordination file kept inside that repository. So GitHub does three jobs at once: it is the version history, the shared “board” that lets independent agents act as one team, and the deploy trigger — every commit to the main branch automatically publishes the live site. The local agents take on anything that needs the running game in front of a discerning eye (rendering the scene, catching a misplaced sprite); the cloud agents grind through logic, content, and the thousands of test playthroughs. All of it works toward the creator’s direction, which sits above the whole team.
What makes a build team like this trustworthy is a handful of engineering choices the creator insisted on:
- A core that tests itself. The whole game simulation is kept free of browser code — pure, deterministic JavaScript whose every random event flows through one seed and whose whole state is plain saveable data. This lets the team run the game thousands of times headlessly to verify it: 1,000+ playthroughs checking for zero crashes and zero broken rules; “bot” players of varying skill measuring difficulty against the creator’s targets; and every line of generated text checked against the real game state, so the game never says “your stores run low” while your larder is full.
- A “render gate” for the visuals. Because a coding agent can’t look at a picture, the scene is drawn to an image file and handed to a separate AI critic — given only the image and a checklist — to describe what it actually sees and flag anything broken. Find, fix, re-render, re-check.
- Living memory. A few always-current documents hold the architecture, the current state, and the hard-won lessons, so a fresh AI session reads them and picks up exactly where the last left off.
The art — the styles, and how each is made
The look is deliberate: hand-painted, medieval-illuminated-manuscript style, period-accurate and grim, never glossy or modern. It’s built from five distinct registers — four AI-generated to a locked style, one sourced from real manuscripts — combined into the in-game scene below.
How the scene itself is built. The vill you see isn’t a single picture — it’s assembled live every time you look at it. The game draws the bare landscape in code (the three open fields and their furrowed strips, the stream, the ground and sky tinted for the season and the weather), then places the hand-painted sprites on top — each croft, the church, the lord’s castle, the mill, the beasts, and the folk — according to an authoritative layout model: one data file that fixes where everything sits in the vill, in proportional near-to-far coordinates, guarded by machine-checked rules so a building can never drift into the wrong place or overlap another. What actually appears is driven entirely by the live game state: your croft shows its real condition (sound, failing, burnt, mid-rebuild); the castle and church show their true stage of construction; the right number of neighbour households stand in their crofts; the field-workers turn out only in the season’s working field. Because it is all data and deterministic code, the same state always draws the same scene — which lets it be rendered headlessly and put through the render gate (above) to catch a floating sprite or a misplaced gallows before it ever ships.
1. Oil paintings — the hero, the endings, the forced choices
AI-generated (Gemini) full painterly oil scenes, used for the title key-art (at the top of this page), the ending splashes, and the banner over every hard moral choice. The painterly register is enforced on purpose; the photo-real generators were banned for breaking it.
2. Flat scene sprites — the buildings and beasts
AI-generated in a flat, Bayeux/wool register, then cut into clean transparent sprites and placed on the scene by the data-driven layout. Form-accurate: real archaeology and reconstruction photographs (West Stow, Wychurst, Butser, Guédelon) are fed in so a hut comes out as a correct earthfast timber-and-daub building, not a later cliché.
3. Painterly vignettes — the building tap-cards
AI-generated small impasto-oil scenes — each building shown in its believable in-vill context — that pop up when you tap a structure. A middle register between the flat sprites and the full hero oils.
4. Codex emblems — the glossary marks
AI-generated small flat emblems, one consistent symbolic hand across the in-game encyclopaedia, illustrating each historical term.
5. Real medieval manuscript illuminations — the journal
Genuine 11th–14th-century manuscript images (public domain), used to illustrate each event
in the journal. Sourced from public digitisations — chiefly the British Library’s
IIIF image service (much digitised under the Polonsky Foundation’s England and
France 700–1200 project) — cropped to the scene and credited by shelfmark and date
in CREDITS.md. The corpus spans the Bayeux Tapestry, the Old English Hexateuch, the
Anglo-Saxon “Labours of the Months” calendars (contemporary with the setting), the Harley
and Eadwine Psalters, the Old English Herbal, and the great later picture-books (Luttrell, Queen
Mary, Smithfield, Holkham, Morgan).
Everything generated (styles 1–4) is then put through the render gate above, so nothing ships with a floating sprite, a stray halo, or an anachronism the building agent couldn’t see.
The tools, briefly
| Tool | Role |
|---|---|
| The creator’s direction | The vision, design, balance, taste, and quality bar — the actual authorship. |
| Claude Code (Anthropic’s AI coding agent) | The build team — several parallel agents, some run locally on the creator’s machine (visuals, screenshots) and some in the cloud (logic, content, testing). |
| GitHub | Version control, the shared coordination “board” the agents sync through, and the auto-deploy trigger. |
| Vercel | Free static hosting for the live site (domesdaygame.vercel.app). |
| Node.js | Runs the browser-free game core headlessly to test thousands of playthroughs. |
| A headless canvas renderer | Draws the scene to image files so an AI critic can “see” and check the visuals. |
| Gemini image models | Generate the manuscript-style artwork (the photo-real generators were avoided on purpose). |
| Public-domain manuscripts (British Library IIIF, etc.) | The real illuminations behind the in-game journal, fully credited. |
| Plain web stack (HTML/CSS/JS, ES modules) | No framework, no bundler — the whole thing is just static files. |
Why it works
The trick isn’t “AI writes a game.” It’s a human author directing an AI build team that can verify its own work — a deterministic, testable core; automated robustness, balance, and coherence checks; a render gate so the visuals don’t slip; agents that review one another; and, above all of it, a person setting the vision, playing the game, and deciding what’s good. The machine supplies the labour and much of the judgment; the creator supplies the vision, the taste, and the standard — and stays the author of the thing.
The result is a dense, historically careful game — hundreds of hand-written events, a real manorial economy, a freedom-slide at its heart, and an art style built from real medieval manuscripts — made far faster than a small team could, because the team building it could also continually test what it built, and because one person knew exactly what they wanted it to be. And under all of it sits the point of the thing: to let a player feel a piece of history from the inside, and come away knowing it.