A Game Engine From Nothing

The premise, as it ships, is this. It’s the last day at an IT company. The company’s all-powerful in-house AI has just made all three hundred engineers redundant — you included — and you have until 17:00 to file your final timesheet. There is a sauna. There is a ball pit in the basement. There is a man who lives under a server rack and has never officially been an employee. And somewhere behind a machine is a USB stick with masking tape on it reading DO_NOT_DELETE. What you do with that stick is the only decision in the building anyone will remember. It runs entirely in the browser — for now as a small invitation-only beta.

It began as a favour and a fascination. The original — a former colleague’s text adventure — was too good to leave as plain text. I wanted to see it as a proper point-and-click, the kind I grew up with. So I described that wish to Claude, in Claude Code, and over about ten days it built the whole thing. This first part is about the least glamorous and most astonishing bit: the engine.

What “an engine” even means

When people make a game, they almost never start from zero. They build on top of a big off-the-shelf toolkit — a “game engine” — that already knows how to draw things, move characters, play sounds, and save your progress. It’s the difference between building a house and building a house after someone’s already delivered the bricks, the plumbing, and the electricity.

This game has no toolkit under it. None. Claude wrote the bricks, the plumbing, and the electricity itself, in plain web code that runs in any browser with nothing to install. It draws the entire world onto a tiny canvas — a deliberately small grid of chunky pixels in a fixed palette of thirty-two colours — and blows it up so it fills your screen with that warm, retro, hand-made look. There are no picture files anywhere in the game. Every character, every room, every sunset is described in code and painted, dot by dot, as you watch.

Everything a point-and-click needs, hand-built

An adventure game is a surprising amount of separate machinery, and Claude built each piece. There’s the row of verbs along the bottom — Look at, Use, Talk to — the classic way you interact with these games. There are characters who walk around and get smaller as they move into the distance, so the world feels like it has depth. There’s a whole conversation system, with talking close-up portraits whose mouths move. There’s an inventory, a system of save slots, cut-scenes for the dramatic moments, even a little combat system for one memorable confrontation. There’s a hand-drawn typeface — a tiny pixel alphabet, invented character by character, including the Finnish letters Ä, Ö and Å.

The scale crept up as we went. What started as a handful of rooms became thirty-nine of them, spread across three eras of the company’s history. There are more than twenty side-quests, two dozen speaking characters, and a fistful of daft mini-games. It is a genuinely large game, and it grew mostly because I kept saying some version of “lovely — now what if there were more?”

The robot that plays the game

Here is the part I find almost more impressive than the game itself. Early on I asked a nervous question: how do we know the whole thing actually works — that every ending is reachable, that no puzzle is secretly impossible, that saving and loading doesn’t eat your progress? A big adventure game has an enormous number of ways to get stuck.

Claude’s answer was to build a second program whose only job is to play the first one. Not to check the code in the abstract — to actually drive the real game, automatically, through every ending, every quest, every death scene, every save-and-reload, and confirm none of it breaks. It runs before anything is ever published. If it goes red, the new version simply doesn’t ship.

It proves the game’s logic works — but it can’t see. So we paired it with a second trick: automatically taking screenshots of real scenes and looking at them, because some bugs are only visible to an eye.

That combination — a tireless robot playtester plus the occasional human glance at a screenshot — caught things that would have been miserable to find by hand. Endings that had quietly become unreachable. A mini-game that turned out to be literally unwinnable. Clickable objects so big they hid the doorway behind them. A death counter that helpfully reset itself every time you died. All found, all fixed, and — the important part — each one turned into a permanent check so it could never come back.

Small, sturdy, and self-contained

One thing I asked for early and never regretted: no complicated build machinery. The whole game is just files that a browser opens directly. There’s no installation, no big framework, nothing to update. That sounds like a technical footnote, but it’s really an aesthetic choice — the same spirit as drawing the graphics in code and keeping the palette to thirty-two colours. It’s a small, sturdy, self-contained thing, and it will still run in ten years because it depends on almost nothing.

That’s the machine. In Part 2 I’ll talk about the parts that surprised me most — the art, the comedy, and the small miracle of an AI composing two dozen original songs for a soundtrack it will never be able to hear. And in Part 3, the strangest bit of all: that I wrote not one line of any of it.