Three arcade classics in a weekend, no libraries, no sprites

What Claude Code nailed first pass on Asteroids, Space Invaders and Galaxian, and what took several goes.

Three illuminated 1980s arcade cabinets side by side: Asteroids on the left with its vector ship and rocks on the screen, Space Invaders in the centre with yellow pixel aliens and green shields, and Galaxian on the right with multi-coloured aliens and a diving flagship.

After the oldkindle.com weekend build I wanted a contrast piece: no commercial deadline, no Stripe checkout, no fact-checking. Just the question I had been carrying around for a while: how well does AI-assisted development handle a tightly-specified reproduction job? The test I picked was rebuilding three vector arcade classics from scratch, with one strict rule. No libraries, no sprite sheets, no ROM peeking. Every line drawn at runtime, every behaviour reasoned from public descriptions of the originals.

The three games are live and playable on this site. There is no install, no sign-in, no analytics. Open the page, click start, play. Total runtime code is 3,709 lines of vanilla HTML5 Canvas and JavaScript, written across a weekend with Claude Code at the keyboard and me as the director.

Asteroids (Atari, 1979)

1,061 lines. Vector ship, momentum physics, screen wrap, splitting rocks, hyperspace, flying saucers.

Play →

Space Invaders (Taito, 1978)

1,271 lines. Marching rows, destructible shields, mystery UFO, the tempo curve that built the genre.

Play →

Galaxian (Namco, 1979)

1,377 lines. Full-colour, formation aliens that peel off in dive-bomb attacks, flagship escorts, scrolling starfield.

Play →

The constraint

The rule I gave myself, and Claude Code, was that the games had to be built from descriptions, not from the originals. No MAME ROM disassembly, no decompiled sources, no copy-paste from existing browser clones. Public documentation, Wikipedia pages, period gameplay footage, my own memory of playing them in coastal arcades in the early eighties. That was the spec.

The reasoning was twofold. First, I wanted a fair test of what Claude Code knows about these games from general training, rather than what it can copy. Second, the resulting code had to be something I would be happy to ship under my own name. If the only way to get an accurate Galaxian was to lift somebody else’s engine, that is not a case study, it is plagiarism.

Asteroids: the easy one

Asteroids landed almost intact on the first pass. The physics is unusually clean for a 1979 game: thrust adds to a velocity vector, friction is zero, rotation is decoupled from heading, screen wrap is just a modulo on x and y. Claude Code wrote the ship class, the asteroid splitter, screen wrap, bullet lifetimes and the basic collision detection in a single pass. I started the game, the ship drifted the way I remembered, and the rocks split into the right number of smaller rocks at roughly the right speeds.

The bits that took iteration were not the physics, they were the feel. The first version’s thrust was too punchy and the rotation was too fast. I asked for the thrust to feel “like the ship is heavy and the engine is small.” That single sentence got me three quarters of the way there. The remaining tuning was sliders: maximum velocity, drag, rotation rate, asteroid spawn cadence. Twenty minutes of back and forth.

Hyperspace was the only behavioural detail Claude got initially wrong. The first implementation just teleported the ship; the original had a chance of materialising the ship inside an asteroid as punishment for using it. Once I described that, it added the random fatal outcome and a brief screen flash, and it felt right.

Space Invaders: the tempo problem

Invaders was where the spec actually mattered. The first build looked correct, marching rows, dropping bombs, four destructible shields, a mystery UFO crossing the top of the screen, but it played wrong. The march was a steady metronome from the first invader to the last. The original is not like that.

The famous quirk of Space Invaders is that the speed-up is not a designed difficulty curve. It is a hardware accident. The 8080 CPU could only redraw a fixed number of sprites per frame, so as you shot invaders the number of sprites went down and the redraw loop went faster, and the march sped up. The closer you got to winning the round, the more frantic it felt. That accidental tempo is the reason the game was a phenomenon.

Claude Code had not modelled that. I described the hardware origin in two paragraphs and asked for the step interval to scale inversely with the number of invaders remaining. The next build had it. The last invader on screen scuttles at a pace that, even forty-eight years later, still works on the nervous system the way it was meant to.

Galaxian: the AI problem

Galaxian was the hardest of the three, and not for the reasons I had expected. The visuals came easily: aliens in formation, a scrolling starfield, a player ship that fires single shots. Full colour was, in 1979 arcade terms, the unique selling point. In 2026 browser terms it is just a different fill style.

The hard part was the dive-bomb AI. In Galaxian, aliens do not simply walk down the screen in rows like Invaders. They peel off from their formation, fly a curving attack path toward the player, drop bombs, and either return to the formation or get shot down. Flagships lead small escorts of two drones. Each dive is a small piece of choreography.

Claude Code’s first attempt was a straight line dive from formation to a point near the player. It looked nothing like the original. Its second attempt was a sine-wave path that looked more interesting but had no awareness of the player’s position. Its third attempt, after I described the way real Galaxian dives feel like a Bézier curve that bends toward where the player is right now, was the one that clicked. Add a small random offset so it does not feel mechanical, and a flagship that recruits two adjacent drones into an escort run, and the game suddenly plays like the one I remembered.

The honest split

The AI wrote every line of HTML, CSS and JavaScript. The Canvas drawing routines, the game loops, the collision detection, the input handling, the score tracking, the start screens, the responsive scaling, and the page metadata.

I made the decisions: which behaviours had to be authentic versus close-enough, how the games should feel under the hand, when to stop tuning, and when to call out a behaviour that was wrong. I also handled the dev environment, the directory layout, deployment, and the publishing of these pages.

The ratio is similar to the oldkindle.com build: roughly 90% AI-generated code, 100% human-directed taste. Nothing shipped without me playing it for several minutes and saying yes or no. The interesting work was not writing the code, it was knowing what felt wrong and being able to describe why.

The wider lesson

AI-assisted development is strongest where the target is well-documented and the behaviour is well-specified. Vintage arcade games are the canonical example: forty-eight years of articles, books, retrospectives, and YouTube playthroughs. Claude Code does not need to invent Asteroids; it needs to assemble it. The only place it stumbled was where the documented behaviour conflicted with a hidden hardware quirk, the Invaders tempo, or where the documented behaviour was qualitative rather than mechanical, the Galaxian dives.

That maps directly onto the day job. A Drupal 11 site is a well-documented system. Stripe’s checkout API has a public reference. Salesforce JWT OAuth has an RFC. Playwright has an exhaustive guide. The closer a piece of work sits to a well-specified target, the more leverage AI-assisted tooling gives you. The further it drifts into qualitative judgement, taste, tone, brand fit, ethical limits, the more the human director still has to do the work.

The case for AI-assisted development is not that AI does the job for you. It is that AI does the documented bits with no friction, which leaves you free to spend your attention on the bits that actually need it.

The numbers

Play them

The three games are linked at the top of this article. They run on every modern browser, no install, no account. If you grew up in the seventies or eighties they will feel familiar. If you did not, they will feel surprisingly hard. Forty-eight years of accumulated game-design lessons stripped out leaves you with the original loop: shoot, dodge, survive, get a slightly higher score than last time. It still works.

If the rebuilding job sounds like something you would like to apply to a more commercial problem, the contact details below are the right place to start.

© 2026 Graith Internet.

Graith Internet is a UK web development company specialising in PHP, Drupal, and AI-assisted development.