By the end of this session, you can…
- LO 11.1Merge playtest findings and audit findings into one ranked backlog with impact × effort scored.
- LO 11.2Commit to a revision frontier — the top N items that fit within budget — and defend the cut line.
- LO 11.3Execute at least three revisions in the studio period; log the diff.
- LO 11.4Present your revised loop to a peer group in a 5-minute show-and-ask.
One table. Every finding. Ranked.
| Column | What belongs |
|---|---|
| ID | Short handle — PT-03, AU-02. Easy to reference in commits. |
| Source | Playtest / audit / instructor / own observation. |
| Finding | One sentence. No paragraph; those go in the source doc. |
| Impact | 1–5. How much does fixing this move a D2 objective forward? |
| Effort | 1–5. How many studio hours realistically? |
| Flag | Red if stopper (ethics, safety, content error). Non-negotiable top priority. |
| Decision | Do / defer / decline. Deferred and declined items have a one-sentence reason. |
A good backlog has items below the line. Items below the line have a reason they are there — low impact, high effort, out of scope, or a deliberate choice about what this version is not. A backlog with no declines is a to-do list, not a design.
Score, sort, draw the line
| Time | What happens | Cue |
|---|---|---|
| 00:00–10:00 | Solo — transfer all findings into the backlog. One row per finding. | "No editing yet. Capture everything." |
| 10:00–20:00 | Solo — score impact and effort. Flag stoppers. | "If you rate >5 items at Impact 5, you have not really scored them." |
| 20:00–25:00 | Pair — swap backlogs; partner queries the top three rankings. | "Why is PT-03 impact 4, not 3?" |
| 25:00–30:00 | Draw the cut line. Above it: this session's work. Below: the decline/defer note. | "The line is a commitment, not a filter." |
Execute. Log the diff.
Work above the line, top down. After each revision, make a commit (or a dated entry in your change log) with the backlog ID and a one-sentence diff. The log is graded — a fast revision with no trace is worth less than a slow revision that is documented.
Today you will think of a great new feature. Write it below the line. You are not building it. This is the last revision week; what is not on the list is not in the game.
5 minutes, 2 slides, 1 question
Demo the revised loop to your triad. Two slides max — before and after, or the revised state machine. Bring one question you want feedback on. Not "thoughts?" — a specific question. Your peers' job is to answer that question only.
Good questions / bad questions
- Bad
- "What do you think of my game?"
- Better
- "Does the revised pager-interrupt state visibly teach escalation, or does it feel like a chore?"
- Bad
- "Any feedback?"
- Better
- "Between the old and new feedback for incorrect picks, which lands the discrimination point faster?"
Before final presentations
The build-discipline handout for revision
Revision studio is when teams overbuild. Today's handout is the counterweight: structured implementation with Codex, task packets scoped tight enough to debug, and decisions about what to cut.
Codex-To-Three.js Build Playbook
The build-loop discipline for teams turning revision findings into bounded, testable code changes. Written to prevent the classic failure: asking Codex for a full game instead of a disciplined next slice.
Why this week Write your revision cycle as Codex task packets from this playbook. If the packet won't fit the template, the revision is too big.