Fun Is Not a Spec

The Pong build that violated the spirit of my request was the one I wanted to keep playing.

That was inconvenient.

The first experiment had already taught the management lesson: a vague prompt is not a specification. Ask three AI systems for "Pong" in one sentence and you do not get three copies of Pong. You get three histories of the word "Pong" expressed as software.

One model built the 1972 original. One built the web-tutorial version. One built an arcade cabinet it found in a dream: neon, sound, trails, particles, screen shake, power-ups, demo mode, AI opponent, the works.

The casino build was guilty. It added things I did not ask for.

It was also the only one with a pulse.

Fun-arc evidence

Then the second experiment made everything disciplined. I wrote an engineering spec. I required deterministic physics. I required a fixed-step test API. The lottery collapsed. The builds became small, correct, and machine-checkable.

Even that was not clean. The verifier lied twice, and I had to debug the judge before I could trust the PASS. But after the falsifier was hardened, the result was real: correct Pong, verified by mechanism instead of vibes.

Then I played the disciplined builds.

They were correct.

They were not the one I went back to.

That is the layer neither the first Pong post nor the falsifier autopsy settled. A spec can remove scope lottery. A verifier can protect objective invariants, if you inspect the verifier too. But neither one answers the question that appeared after Pong became correct:

What makes the game worth another rally?

My first theory of fun was wrong

I reacted to the accidental casino like a chastened manager.

No more vague prompt lotteries. If the messy build had won on fun, I would write a better design document and make fun deliberate.

The design pass selected five mechanics: spin on paddle contact, a charge shot, a destructible center wall, multiball, and bullet-time on near misses. This looked serious. It had systems, interactions, variation, and the flavor of game design.

Gemini Pro built it. The result ran. The tier-one checks passed. The deterministic layer held. The test API survived. The center wall could be broken. From the objective side, the harness did its job.

Then I played it, and the diagnosis changed.

More mechanics had not produced more life. The additions were present, but they did not all become readable play. The charge shot behaved like a hidden modifier: hold a key, wait for the ball, hope the charged paddle happens to matter. Spin changed the return, but without enough sensory tell it felt more like a calculation than a physical touch. The wall existed as a system, not yet as an event I wanted to cause again.

The model had implemented the contract.

The problem was the contract.

I had written a design document that treated fun as a list of mechanics. The idea generator copied my bias: it produced transferable systems because I asked for transferable systems. It did not naturally invent a sound palette. It did not ask what a paddle hit should feel like. It did not decide whether a wall break should thump, crack, flash, pause, or leave a scar in the field.

But players do not experience a mechanic as a bullet point.

"The wall is destructible" is an idea.

"The wall reacts when I hit it, the field acknowledges the impact, the sound tells my hands that something happened, and now I want to do it again" is closer to play.

That is not just decoration. It is the feedback loop becoming legible.

My spec had preserved rules and omitted feel.

So feel disappeared at the boundary.

This is the first trap:

If your contract only names mechanics, the model will preserve mechanics. It will not preserve the unwritten reason the mechanic feels good.

The verb test

The more useful mistake was the charge shot.

On paper, charge shot is a familiar game idea. Hold power. Release power. Hit harder. It belongs in videogames, so it looked at home in a list of videogame mechanics.

But Pong has no attack button.

Pong's verb is not really "hit." Pong's verb is "be there." You move a paddle into the ball's path. Contact happens because geometry says it happens. The player does not swing.

So the charge shot had nowhere clean to live.

The implementation turned it into a passive modifier: hold charge, wait for the ball, hope your charged paddle happens to touch it. It existed as code, but not as a clean action. It was a borrowed mechanic without the verb it needed.

That was a designer error.

And it gives a better filter than "is this mechanic interesting?"

Before grafting a mechanic, ask:

What verb does this mechanic presuppose, and does the substrate already have it?

Spin works because Pong already has angled reflection. A destructible center wall works because Pong already has geometry, collision, and territory. Multiball works because Pong already asks the player to track and intercept. Bullet-time near misses work because Pong already has proximity and risk.

Charge shot, in this form, fails the verb test. It needs an active strike. Pong has positional interception.

The distinction matters because "can the model implement it?" is too weak a question.

Almost anything can be implemented.

The better question is:

Does this mechanic make the player do a sharper version of what the game is already about?

If not, you are not adding depth. You are adding a tax.

The version that worked

The winning pass did not start from a clean spec.

It started from the guilty casino.

Take the Flash build, the one with the pulse. Preserve the holistic seed: the neon field, the audio, the trails, the particles, the tiny arcade excess. Do not ask a sober design document to reconstruct that texture from first principles. Keep the texture that already works.

Then graft one coherent mechanic onto it.

Not five. One.

The chosen graft was the destructible center wall.

Why that one? Because it belongs to Pong's verbs. The ball already crosses the field. The paddles already redirect it. The center already matters as territory. A wall in the middle changes lanes, timing, and risk without asking the player to learn a foreign action.

This time, the wall did not sit on top of a dry prototype. It inherited the sensory channel of the casino build. Hits had audiovisual context. Motion already had trails. The field already knew how to react. The new mechanic had somewhere to land.

The V2 build worked.

More precisely: it improved the thing that was already fun without erasing why it was fun.

That is a different recipe from "write a better spec."

The recipe was:

1. Preserve a fun seed.
2. Generate candidate mechanics.
3. Filter them by verb coherence.
4. Graft one strong mechanic.
5. Keep the objective harness around it.
6. Let the human judge feel.

That last step is not a failure of automation.

It is the boundary.

The boundary moved again

Pong has now produced three different lessons.

The first was managerial: under-specification creates a lottery.

The second was verification: even a falsifier can lie.

The third is design: fun is partly liftable, but not by pretending it is deterministic physics.

Correctness was easy to make machine-checkable at the Pong level. Expose state. Step the simulation. Replay the same sequence. Observe bounces, scoring, containment.

Fun did not behave that way.

There were objective supports around it. The build still had to run. The deterministic layer still had to hold. A candidate mechanic still had to fit the game's verbs. Those are real checks. They matter.

But the final verdict was still human-terminal:

Does this feel better?

The danger is not that subjective judgment exists. The danger is letting it leak into places where a machine check should exist, or letting machine checks impersonate taste.

So the boundary map now has at least three layers:

• Correctness: often machine-checkable, if the artifact exposes the right hooks.
• Design coherence: partially analyzable; a designer-agent can be forced to explain verbs, loops, and fit before build.
• Feel: human-terminal for now, but protectable by preserving good seeds and avoiding incoherent grafts.

That is more useful than saying "AI can make games" or "AI cannot make games."

At Pong altitude, AI can make the game. It can even make a lively one by accident. A harness can remove the lottery and preserve the physics. A design pass can improve the result, but only if it respects the part of play that does not survive being reduced to a mechanics list.

Pong's final note is simple:

Fun is not a spec. But a spec can protect the conditions under which fun survives.

Next rung: Breakout, a game with more state than one ball and two paddles.