Scenes 5-6: The Duel & Round One Loss

Scene 5 — the duel

Now the actual match starts: a 1-on-1 football duel between the two robots in the middle of the street, meant to feel fast, messy, and chaotic rather than choreographed. Adil hands Claude a short plain-language description — two robots trading feints and dribbles, the white robot eventually winning the ball and scoring — and Claude expands it into the full scene prompt.

That prompt is dense: two characters, a ball, feints, and a physical duel all in one shot is a lot of moving mechanics for a single generation to hold onto. The rule of thumb for scenes like this: don't settle for two batches. Run a lot of generations, then cut the best few seconds out of each one and edit them together — the final sequence looks far more organic than any single take.

A story problem, caught mid-edit

Watching the duel footage back, Adil catches a structural issue: if the hero's robot scores here, the story is basically over before the midpoint. Every sports film works because the hero loses first and comes back later — that's what makes the eventual win land. So the plan changes on the spot: the footage of the white (hero) robot scoring from this batch gets set aside for the finale, and the next scene is rebuilt so the rival scores instead, putting the hero behind after round one.

Scene 6 — the rival scores, and why the goal kept jumping

Same process as before — describe the beat to Claude (the black robot beats the hero and puts the ball through the goal), get the scene prompt back, run it. But the results break in a specific way: the goal shield appears in a different spot on the street in almost every generation, sometimes teleporting mid-shot, and occasionally the goal reference image just flashes on screen as a flat keyframe instead of sitting in the scene.

The cause: the prompt never told the model exactly where the goal stands, so it guessed a new position every time. Describing the position in words again wouldn't fix it — the model needed something it couldn't misread.

Fixing it with a location scheme

The workaround is to stop describing position and start drawing it:

1. In GPT Image 2, generate a high-angle wide shot of the location — a clean top-down plate of the street.
2. Mark the two goal positions on that plate by hand with two dots, using any drawing tool.
3. Feed the dotted plate back into GPT Image 2 along with the goal-shield prop sheet, and ask it to place the goal shields where the dots are and produce a labeled location scheme.

The output is a full production-style plan: goal distance, street length and width, distance to the surrounding buildings, even compass orientation — the kind of location diagram a traditional film set would use.

That scheme then gets declared to Claude as a new element, with one instruction attached: the goals must appear exactly where the scheme places them in every generation — the goal-shield prop itself is used as a reference, not a keyframe to copy literally. Back in the generation tool, the scheme is added to the scene's elements before the prompt runs.

The difference is immediate — the goals now lock to the same spot in every shot, matching the dots exactly, instead of drifting around the street or flashing as a static image. The takeaway: when a prompt keeps failing on something spatial, stop writing more words and show the model a picture instead — a map beats a paragraph.

With scene 6 locked, round one ends with the rival ahead — not a win for anyone yet, but the low point the rest of the story builds from.