Stoppage Time

I'm a midfielder. I took free kicks through my varsity years, so when I was asked to build an arcade game, that was the obvious subject, not a sport I had to research. Stoppage Time puts you over a dead ball ten times in a row: pick your angle, pick how much air you put under it, strike it, then bend it in flight if the wall or keeper forces you to. It's not really about scoring. It's about standing over the ball with your heart rate up and still executing the same mechanical decision you've made a hundred times in practice.

Two design decisions I'd actually defend. First, the Low / Medium / High lift choice was mine from the start, not Claude's. I didn't want a single arc the game picks for you. I wanted the same choice I actually make before a kick, where a low driven ball and a lofted one are different techniques with different risk, and where the “right” choice changes with distance. From 30 yards, a low ball just doesn't carry. It dies in the grass before the box, which is exactly the kind of consequence a real low free kick from that far out has. Second, I pushed for the keeper to actually be beatable. The first build had a keeper that read my curl input in real time and adjusted every single frame, which meant it could never be beaten no matter how I bent the ball. I played all ten rounds and didn't score once. That's not hard, that's broken. I said so, and the fix (the keeper commits to a dive once, early, with some margin of error, and can't change its mind after that) is the actual design idea the game runs on now: disguise the shot before the keeper reads it, then bend it after.

I gave Claude very little up front: my major, my year, and that I play soccer. The free-kick concept itself, the perspective rendering, the wall geometry, and the nerves/heartbeat pressure effect were all Claude's ideas, not mine, and they're good ones. I wouldn't have thought on my own to tie the wall's position to covering the near post. What I actually did was catch the thing that was broken by playing it, and push three concrete changes afterward: the lift mechanic I wanted kept front and center, a pentagon-patterned ball instead of a plain white circle, and ten rounds instead of eight. That's a smaller share of authorship than I'd like to claim credit for, and I'd rather say that directly than pretend the idea was mine.

Is the game mine? The concept, the feel, and almost every system in it came from Claude working off two sentences about my major and that I play soccer. What's mine is narrower: I know free kicks well enough to recognize when the keeper mechanic was actually broken rather than just hard, and I made three specific calls about what the final game should look and feel like. That's real, but it's a smaller claim than “I made this.”

Prompts:

“I am an undergraduate finance student and I love to play soccer. During my varsity days I was a midfielder. My strengths: set-pieces, passes and shooting. After giving you this information can you produce a soccer game that has around 800-1,500 lines of code.”

“I played the 8 rounds, yet it is impossible to score against. The keeper saves every shot, we need to reduce the difficulty.”

“I am enjoying the game, but as a user I realize the rounds are moving pretty quick, let’s total it to 10 rounds of set-pieces”

AI Disclosure:

Claude code built the entire first version of the game from one short prompt about my major and that I play soccer; I did not design any system myself. I played all ten rounds and reported that the keeper was unbeatable. Claude identified the actual bug (it was re-reading my shot every frame instead of committing to one read) and fixed it, which I verified by playing again afterward. I then requested three further changes: keeping the lift mechanic central, a pentagon-patterned ball, and ten rounds instead of eight. These were implemented without further correction needed. I did not write, and have not reviewed in detail, the underlying JavaScript.