Playtest feedback

Playtest feedback

Players are great at telling you where it hurts and bad at telling you why. This kit turns their notes into one table ranked by impact, so the next build fixes the thing four out of four testers hit, not the thing the loudest tester said.

Inputs

Ask for anything missing:

1. The raw notes: pasted text, or files in playtests/ (one file per tester is ideal).
2. The build and levels played, so notes can be pinned to a level.
3. The goal of this playtest (default: "is the first five minutes fun and clear?"). Rank against that goal.

Steps

1. Normalize into data/playtest.csv with this header:

   tester,level,type,severity,tag,note

   • One row per observation. Split a note that says two things.
   • type: bug (it is broken), confusion (did not know what to do), frustration (knew, but it felt unfair), boredom (nothing to do or too slow), delight (smiled, laughed, said "again"), idea (a suggestion).
   • severity for problems: 1 minor, 2 hurts the fun, 3 blocks progress or made them quit.
   • tag: a short shared label such as jump-too-floaty. Reuse the same tag for the same root problem across testers. This step is the real work; take care with it.
   • note: the tester's own words where possible. Use a nickname like P1, not a real name.
   • Show the user the tag list (tag, count, one example) and ask whether any should be merged or split before going on.

2. Tally:

   node scripts/tally-playtest.mjs data/playtest.csv out/playtest-summary.md --json out/playtest-summary.json

   Issues are ranked by distinct testers times worst severity. Rows with an unknown type are listed under "Rows needing a look"; fix them and rerun.

3. Read the summary and add a "Fix next" section to the top of out/playtest-summary.md: at most three items, each with the likely cause and one concrete change to try. Prefer tuning (a number in config) over new features.
4. Name what to protect: the delight list. Any fix that touches those moments needs a careful look.
5. Suggest the next test: what to watch for, and how many testers (five is usually plenty to find the big problems).

Output

## Fix next

1. **jump-too-floaty** (4/4 testers, blocks progress on 1-2). Likely cause: low gravity and long hang time. Try: raise gravity 25% and add a faster fall when the button is released.
2. **stuck-in-wall** (2/4, blocks progress on 1-3). Likely cause: collision resolves after the door opens. Try: resolve X then Y separately, and push out of solid tiles.
3. **cant-find-jump** (2/4, tutorial). Try: show "Space to jump" next to the first gap until the first jump.

Protect: the landing squash and the coin sound.

Then the generated tables follow.

Guardrails

• Keep testers anonymous in every output. Replace real names with P1, P2, and so on.
• Never invent observations. If a note is ambiguous, tag it, and mark the row in your summary as "unclear" rather than guessing the cause.
• One loud tester is one tester. The ranking counts distinct people on purpose; do not reorder by how strongly someone felt.
• Write only to data/ and out/. Raw notes in playtests/ are read, never changed.

Playtest feedback

Paste in what your playtesters said and get back a ranked list of what to fix next, plus the moments players loved so you do not break them. A small script does the counting, so the ranking is the same every time.

Who it is for: indie and jam developers, students, and small teams who just ran a playtest and have a pile of notes, chat messages, or form answers.

Example

Input, data/playtest.csv (Claude builds this from your raw notes):

tester,level,type,severity,tag,note
P1,1-2,frustration,2,jump-too-floaty,Overshot the small platform three times
P2,1-2,frustration,3,jump-too-floaty,Gave up on the gap after 6 tries
P2,1-3,bug,3,stuck-in-wall,Got stuck inside the wall left of the door
P3,1-3,delight,,,Coin sound is really satisfying

Output, out/playtest-summary.md:

Plus a per-level table, a "Protect these" list of delights, tester ideas, and a short "Fix next" section with a concrete change to try for each top issue. Try it with examples/playtest.csv.

What it can access

• Runs its own script, node scripts/tally-playtest.mjs.
• Reads raw notes from playtests/ and data/; writes data/playtest.csv and reports in out/.
• No network, no env vars.

Setup

None. Needs Node.js 18 or newer.