Game Jam engineering 1h 10m

W3D10Sb

Can you steer an AI into shipping one feature that actually runs in a stranger's browser β€” and prove which lines you fixed yourself?

Shipped Feature

β–Ά Enter Project

Context

It's 10:01 PM, Global Game Jam 2025, submission closes at 10:55 PM. Your team has a playable game with a working boss fight. Your designer wrote victory-screen copy and has PNG files. Your artist is done. But the code isn't built yet, and the codebase was written by your predecessor (500-line GameState.ts, boss-death hook buried at line 342, UI mounts at MainUI.svelte:67). You have 54 minutes. You will spec it tight, generate code with AI, test it, review it, and push.

Mission

Produce a working victory screen that triggers when the boss dies, integrates into MainUI without breaking GameState, and ships in one merged PR with a recorded demo and documented spec.

Finish Line

A live public URL plus the prompt-and-fix log that got it there.

  • Shipped Feature

    lesson

    One small feature that actually runs in the browser, built by steering an AI codegen tool, with the working prompt and the fix log kept beside it.

  • Builder

    Code partner. You translate spec into shipped code.

    • Posts to PR draft: (a) exact AI prompt pasted, (b) full AI response captured (screenshot or code block), (c) which lines you edited and why (e.g., 'Line 34: changed setState to dispatch because GameState is immutable here'). Verification: teacher can reproduce the AI output by pasting your prompt into Claude.
    • Runs the feature locally and posts: (a) commit hash, (b) 30-second local video showing boss dies β†’ victory screen appears β†’ copy reads correctly. Verification: teacher watches video and sees three events happen in sequence.
    • Posts code-review comment with: (a) acknowledgement of reviewer's architectural concern (e.g., 'Yes, we dispatch instead of mutate'), (b) fix commit hash if needed, or (c) explanation with a code line reference if concern is already handled. Verification: reviewer clicks the commit hash and sees the fix live.
  • Product Owner

    Specification & taste. You lock scope and judge fit.

    • Posts to PR description before any code is written: (a) one-sentence feature spec ('Victory screen appears center-of-screen when boss health ≀ 0'), (b) exactly 5 acceptance criteria (e.g., 'Screen appears within 500ms of boss death', 'Text is designer's copy (headline + 2 lines)', 'Player can dismiss it (click button or press Esc)', 'No game state is mutated', 'Score persists if player replays'). Verification: teacher reads the PR and counts 5 criteria listed.
    • Posts sign-off comment after code review: 'Approved' (all 5 criteria met by the shipped code) OR 'Rejected: criterion [X] unmet because [reason].' Includes one screenshot reference to the merged feature (e.g., 'Headline reads "Victory" in 32px Roboto, βœ“'). Verification: teacher reads the comment and sees a clear yes/no + screenshot evidence.
    • At hour 78 (12 minutes before cutoff), if velocity is slipping, posts to Slack: 'Cutting [specific criterion, e.g., score persistence]. Reason: [e.g., data-sync complexity blocked Builder]. Ship without it.' Owns the decision visibly. Verification: cut is named and posted in writing.
  • Code Reviewer

    Quality gate. You unblock or block.

    • Reads PR diff before any demo and posts one specific concern on a code line, formatted as: 'Line [N]: [observation]. This [mutates global state / has no error handling / assumes async callback]. [Fix: use dispatch() / wrap in try-catch / await before render]. Or explain why current code is safe.' Verification: comment is on a specific line number and proposes a concrete action.
    • Runs the demo video the Builder posts and replies: 'Tested on [timestamp in video]. Clicked boss β†’ health bar empty β†’ screen appeared in [~estimate]ms. Text is: [quote headline]. No console errors observed.' If demo fails: 'Tested: clicked boss, game froze for 2s, no victory screen appeared. Expected: instant screen with readable text.' Verification: teacher watches the timestamp in the video and sees the event happen or not.
    • Posts final approval comment: 'Approved for merge. [Observed behavior]. [Risk resolution, e.g., Line 34 fix confirmed / Error boundary added / Timing within spec].' Verification: comment includes one specific observation + one risk outcome.
  • Designer

    Copy and visuals. You make it feel like a win.

    • Posts to PR description before code review: victory-screen copy as two lines: Headline (3–5 words, max 12 characters): 'YOU WIN' or 'VICTORY'. Body (max 15 words, one sentence): 'You defeated the boss. The world is safe now.' Verification: teacher counts words and verifies both lines are posted in the PR.
    • Watches the final demo video and posts: 'Approved' (or) 'Redo: [element] needs [specific fix], e.g., 'Headline font needs to be white (currently gray), or 'Image asset #4 is pixelated on playback.' Verification: comment names the element, current state, and required fix; or one-word approval is posted.