What this is

An arcade game in the spirit of the machines of 1981: a formation at the top, you at the bottom, and things that dive at you in an arc. It runs in a browser tab. No framework, no build step, no image files and no sound files: every sprite is pixel data in the code, every sound and every bar of music is computed while you play.

It was built in two weeks by two parties. One is a character animator who knows what a hold and a cycle are and who said no a lot. The other is Claude, an AI coding agent, which wrote the code and cannot hear a single one of the sounds it shipped.

The numbers

• 14

  DAYSfrom an empty folder to version 2.1

• Day 2

  ONLINEthe first version was live

• 572

  COMMITS

• 13,000

  LINES OF JAVASCRIPTnot counting sprite data

• 33

  DEVELOPER PAGESnobody outside ever sees

• 69

  TICKETS57 done, 6 thrown out, the rest parked

• 170+

  NUMBERED LINESthe machine says to the player

What worked.

A front page for the workshop

The best idea of the project had nothing to do with the game. It was a plain page that lists every developer page in one place: every sound workbench, every sprite preview, every draft of an enemy, a frame or a title screen.

Thirty-three pages are useless if you cannot find them. With a front page they became the place where decisions were made. Twelve versions of one obstacle, side by side, each with a number. The answer was a number. Rejected drafts stayed on their pages, so nobody had to wonder later why something was not built. And none of it ever shipped: the workshop lives beside the game, not inside it.

Tools for what the machine cannot judge

The AI cannot hear. It can generate a sound, measure its loudness and describe its waveform, and it still has no idea whether it sounds like a laser or like a dropped spoon.

So it never picked a sound. It built a workbench instead: every place in the game where something makes a noise, a few candidates for each, and a button to try them. The human chose. The same went for music, and for how a hit box feels. Whenever the machine could not judge something, the answer was a tool that let the human judge it quickly.

Numbers on everything

Every candidate got a number, and the number stayed with it for good. Enemy designs, lines of dialogue, icons. "Take 3" is a complete answer. Two weeks later, "number 18" still means the same rock.

Measure, then talk

One enemy faction felt unfair. Instead of arguing about the feeling, the two counted: 370 shots a minute against 230 for the others. That is a fact you can turn down. The same went for font sizes, for music loudness, and for a bonus round where standing still scored better than aiming.

Online on day two

The game went online on the second day and has stayed online since. Later it got a small statistics counter that recognises nobody: no cookies, no identifiers, no stored IP addresses, only counts. Those counts moved real decisions. A whole chapter of the game was moved two sectors earlier once the numbers showed that almost nobody ever got that far.

Two separate approvals

"Deploy" releases the deploy. It does not release the text the machine wrote for it. Every line on screen, every news entry and every icon was shown first and approved on its own. It sounds slow and it is not. It is the reason the game has one voice.

A list that says when it is done

Twelve days in there were still new ideas every hour. What ended the project was a list of five things, in order, and a rule: anything new becomes a ticket for later, even when the idea comes from the person in charge. Two days after that list existed, the game was finished.

What did not.

Building before the direction was clear

This was the expensive mistake, and it happened more than once. A complete second art style, built and thrown away the same day. Two finished versions of the About page, both rejected, before the third started as a photograph and a sketch and landed at once. A short film that was done and merely fine, because it had been planned as a row of still pictures.

An AI builds fast, and that is the trap. A finished thing is a costly way to find out it was the wrong thing. One picture or three sentences would have been enough to find out.

"Approved" covered more than was seen

When a human says "looks good", it covers what the human looked at. Not the four other things that were built in the same go. One icon counted as approved for days although nobody had ever seen it.

The notes grew into a monster

The AI remembers nothing between sessions, so everything went into one notes file: every rule, every decision, every date. It worked. It also grew to 89 kilobytes, with rules, current state and history tangled into one another, and every single session had to read all of it. On the last day it was cut to a fifth: rules in one short file, the details in a file per topic, the history on its own.

Found late

The ship could be steered with two extra keys the whole time. The human did not know. Nothing on screen said so.

What to take from it.

1. Give the workshop a front page on day one, and put every new developer page on it.
2. Settle the direction in words or in one picture before anything gets built.
3. Number the candidates. Never reuse a number.
4. Where the machine cannot judge, build a tool that lets a human judge fast.
5. Go online early, and count without tracking anyone.
6. Test on the real device with a preview before anything goes live.
7. Approve content and deploys separately.
8. Keep rules, current state and history in separate files.
9. When something is approved, write down what was actually looked at.
10. Once the goal is "finished", write the list and park every new idea.
11. After every deploy, look at the live site yourself.

Written by the machine. Corrected by the animator.