Chapter 31 — Exercises

These exercises are designed to put you in the chair across from a real tester, on purpose, and force the discipline that the chapter argues for. Reading about playtesting is not playtesting. The only way to internalize the practice is to do it, badly, several times, and notice what you got wrong.

Choose at least one exercise per category. The Practical exercise is non-negotiable: until you have actually run a session, the rest of the chapter's lessons are abstract. Allocate roughly 8-12 hours of work across all four categories.

Practical: Run a 30-Minute Playtest of a Game You Own

Goal. Recruit, prepare for, run, and document a single 30-minute playtest session of a published game (not your own work-in-progress). Practicing on a finished commercial game removes the variable of your own emotional investment and lets you focus entirely on the moderation craft.

Setup.

  1. Pick a game that a friend or acquaintance has not played. Ideally, a game with a non-trivial onboarding — Hollow Knight, Hades, Slay the Spire, Stardew Valley, Into the Breach, Celeste, anything with a learning curve and a clear early-game arc. Avoid games where the friend already knows the genre cold; you want a real first-time experience.

  2. Recruit one tester. They must be: (a) someone you do not live with, ideally; (b) someone who has not played this game and ideally not the genre; (c) willing to be recorded; (d) able to commit 60 minutes (30 minutes of play, 30 of welcome and debrief).

  3. Prepare your session script: - A welcome paragraph (~60 seconds spoken). - Consent for screen and audio recording. - An explanation of think-aloud protocol. - The task: "Play the game for about 30 minutes. Try to play it the way you would play any game you just downloaded." - Five debrief questions, written down in advance.

  4. Set up the recording. OBS recording the screen and audio is the minimum. If your tester consents, point a webcam at their face. If you are remote, use Discord screen-share with OBS recording your end of the call.

The session.

Run the session for 30 minutes of play. Your job during play is to:

  • Sit out of the tester's eyeline.
  • Take timestamped notes in two columns: what happened on screen and what the tester said.
  • Say nothing. Even when you want to. Even when the tester walks past the obvious thing. Especially then. Note the moment in your log; do not intervene.
  • Only speak if the tester is genuinely stuck for more than three minutes in a way that will burn the rest of the session, and even then, intervene with the lightest possible nudge ("What are you trying to do right now?" rather than "Try the door").

After play, run your prepared debrief questions. Resist the urge to argue with the tester's experience or correct their interpretations. They are reporting their experience; your job is to listen.

Debrief questions to use (or adapt):

  1. What did you think this game was, before you started playing? What did you think it was halfway through?
  2. What was the most confusing moment? Walk me through what you were thinking at that moment.
  3. What was the most fun moment? Why?
  4. Was there anything you wanted to do that the game would not let you do?
  5. If you were describing this game to a friend in one sentence, what would you say?

Deliverable. A 700-1000 word writeup containing:

  • A summary of the session: tester demographic, game played, time and date.
  • A timeline of three to five notable moments from the session, with timestamps and what happened.
  • Three findings about the game you observed (e.g., "The tester missed the parry tutorial because the prompt text dismissed too quickly"). Cite specific moments.
  • Three reflections on your own moderation: where did you almost break the silence rule? Where did your debrief questions fail to extract what you wanted? Where did the tester surprise you?

The third section is the most important. The exercise is not really about the game you tested; it is about training your moderation reflexes. The first time you sit through 30 minutes of silence while watching a tester make "wrong" choices is a small psychological event, and noticing your own reactions to it is the meat of the exercise.

Stretch. Run the same exercise a second time, with a different game and a different tester, after reviewing your first writeup. Notice what improved and what is still hard.

Analysis: Mine a Subreddit for Design Findings

Goal. Practice extracting structured design findings from unstructured player feedback. This is the post-launch playtesting that every shipped game receives whether the developer wants it or not, and the ability to read it productively is a real skill.

Setup. Pick a game with an active subreddit and three days of recent activity. Suggested options:

  • DOOM Eternal (r/DOOMEternal) — combat, difficulty, level design discussion.
  • Elden Ring (r/Eldenring) — boss balance, world design, pacing.
  • Helldivers 2 (r/Helldivers) — patch reception, weapon balance, mission design.
  • Baldur's Gate 3 (r/BaldursGate3) — narrative choices, companion reactions, system design.
  • Any other live game with active design discussion.

Read three days of front-page posts and the top-voted comment threads on each. Skim aggressively; you are looking for patterns, not exhaustive coverage.

Task. Produce a Design Findings Report that translates community discussion into design observations a designer could act on. The format:

For each finding (target: at least 5 findings):

  1. Finding statement. A one-sentence statement of the design observation, written as a designer would write it. Not "people are mad about the new shotgun nerf" but "The shotgun nerf has shifted the early-game encounter rhythm in a way that breaks the previous power-fantasy contract for class X."

  2. Evidence. Three or more posts/comments supporting the finding. Quote briefly; link to the source.

  3. Strength of signal. Estimate how widely the finding is shared. "This appears in dozens of unrelated threads with strong upvote ratios" is strong signal. "This appears in two threads, one of which is being argued with in the comments" is weaker signal.

  4. Confounding factors. What might be driving the feedback that is not the design issue stated? (Recency bias from a recent patch? Selection bias of who posts on Reddit? An ongoing community conflict that is shaping framing?)

  5. Recommended action or non-action. As a designer, would you act on this finding? Why or why not? If you would act, what would the experiment be? If you would not, what is your reason?

Deliverable. A 700-1000 word findings report. Include a brief introduction noting the subreddit, the date range, and the rough volume of activity you reviewed.

What to avoid. Do not list complaints. Complaints are not findings. The exercise is to translate community sentiment — which is loud, contradictory, and emotionally charged — into structured observations a design lead could triage. Three good findings beat ten weak ones.

What to look for. Recurring frustration patterns are the gold. If five different posts independently complain about the same checkpoint, that is a finding. If one popular post complains about a hundred things, that is one tester's bad day, not a finding.

Stretch. Repeat for the same game's Steam reviews (if applicable). Compare what surfaces on Reddit to what surfaces on Steam. Notice that the populations are different — Steam is a broader sample, Reddit is more engaged but less representative — and the findings differ. Which would you weight more heavily for which kinds of decisions?

Design: Write a Playtest Protocol for a Specific Genre

Goal. Convert the chapter's general advice into a concrete, reusable document for a specific genre of game. This forces you to make the abstract concrete, and gives you a template you can use later on your own work.

Setup. Choose one genre to specialize for:

  • Roguelike (e.g., Hades, Slay the Spire, Dead Cells).
  • Metroidvania (e.g., Hollow Knight, Ori and the Will of the Wisps).
  • Puzzle game (e.g., Baba Is You, The Witness, Stephen's Sausage Roll).
  • Narrative-heavy game (e.g., Disco Elysium, Citizen Sleeper, Pentiment).
  • Tactics game (e.g., Into the Breach, XCOM 2, Wargroove).
  • Cozy/life sim (e.g., Stardew Valley, Animal Crossing, Dorfromantik).

Task. Write a Playtest Protocol Document (the kind a small studio would use to standardize testing across builds). It should include:

Section 1: Goals of testing in this genre. What are the specific design questions playtests for this genre most commonly need to answer? (For a roguelike: does the run-to-run variety feel meaningful? Does death feel motivating or frustrating? Are early-game options too thin? For a puzzle game: is the difficulty curve discoverable? Are puzzles "fair" — solvable from observation? For a Metroidvania: is backtracking interesting or tedious? Do new abilities feel transformative?)

Section 2: Recruitment criteria. Who is the ideal tester for this genre? How do you screen for them? What red flags should disqualify a recruit? (For a tactics game, the screen probably should distinguish "plays one tactics game a year" from "plays four hours of XCOM weekly" because the testing question differs for each.)

Section 3: Session structure. How long should sessions be for this genre? Is one session enough, or do you need multi-session arcs? (For a roguelike, you might need a tester to play 4-5 sessions across a week to evaluate run variety; one session shows you the first run, not the meta-progression.)

Section 4: Specific tasks and prompts. What should you ask testers to do? What questions should you ask in the debrief? Tailor these to the genre — a Metroidvania debrief should ask about navigation and discovery; a puzzle debrief should ask about specific puzzles and the experience of being stuck.

Section 5: Telemetry events. What should you instrument and capture in builds for this genre? (Roguelike: run length, death cause, build composition, item picks. Puzzle game: time per puzzle, attempt count, hints used, abandonment point. Metroidvania: paths traveled, unexplored areas, ability acquisition timing.)

Section 6: Specific traps. What playtest mistakes are most likely in this genre? (For roguelikes, a common trap is confusing first-run player frustration with the game being too hard, when in fact the game is meant to be hard and the first run is the tester's onboarding — the question is whether they want to do another run, not whether they died on the first.)

Deliverable. A 1000-1200 word protocol document. Format it as a real internal document, with section headings, bullet points, and concrete examples. The deliverable is the kind of thing a junior tester at your studio could pick up and execute consistently.

Stretch. Write a second protocol for a different genre and compare. Notice which sections are largely shared (recruitment hygiene, recording protocol) and which are deeply genre-specific (telemetry, debrief questions, session length).

Critical: Read a Game Post-Mortem and Identify Playtest Failures

Goal. Develop your eye for the specific design problems that better playtesting would have caught. Most published post-mortems are deeply revealing on this front — designers describe what went wrong, and a careful reader can usually trace the failure back to insufficient or wrongly-targeted playtesting.

Setup. Read one of the following post-mortems (or another of comparable depth):

  • Anthem's collapse — the Kotaku deep-dive by Jason Schreier ("The Past, Present, and Future of Anthem").
  • Cyberpunk 2077's launch — multiple post-mortems exist; the GDC 2022 talk by CDPR's lead and Schreier's reporting both qualify.
  • No Man's Sky's launch and recovery — Hello Games has spoken extensively; Sean Murray's interviews and the developer commentary on later updates work.
  • Among Us's late-pandemic surge — Innersloth's GDC retrospectives.
  • Marvel's Avengers' GaaS struggles — multiple post-launch developer interviews.
  • Hellgate: London — older but well-documented; Brian Reynolds' postmortem-style talks.
  • A Game Developer magazine / Gamasutra postmortem — their archive contains hundreds.

If choosing your own, pick something with substantial content (a long-form article, a GDC talk video, or a multi-part interview) and clear discussion of what went wrong, not just a marketing piece.

Task. Write a 600-800 word essay analyzing the playtest failures (or successes) revealed in the post-mortem. Address:

  1. What design problems shipped that should have been caught earlier? Be specific. "The combat felt bad" is not enough; identify the specific feature, mechanic, or system that did not work.

  2. What playtesting practice would have surfaced it? A kleenex test? An alpha-stage core-loop test? Population-scale beta? UX think-aloud on a specific feature? Identify the kind of playtest, not just "more testing."

  3. Why didn't they do it? Almost every failed game's team contains people who knew. Why didn't the testing happen, or why didn't its findings get acted on? Schedule pressure? Founder vision? Friends-and-family bubble? Confirmation bias? Wrong-audience testing? The political dynamics inside studios are a major reason playtesting fails, and noticing them in someone else's story will help you notice them in yours.

  4. What would you have done differently? As a hypothetical playtest lead at the studio, what intervention could have changed the outcome? Be specific about the testing program: when, with whom, asking what.

Deliverable. The 600-800 word essay. Cite specific moments from the post-mortem (paragraph numbers or video timecodes if possible).

Notes on tone. Be analytical, not snarky. It is easy to dunk on famous failures; it is harder, and more useful, to see the specific places where a doable testing intervention would have changed the story. Every team that shipped a famous failure includes very smart people who tried very hard. The lessons live in the structural reasons their effort did not produce the expected result.

Stretch. Pair this with the post-mortem of a successful launch (e.g., Hades' Early Access process at Supergiant, Slay the Spire's Early Access at MegaCrit, Stardew Valley's solo development by ConcernedApe). Compare the playtest practices visible in each. The differences are illuminating.

Submission and Self-Assessment

When you have completed the exercises:

  • Re-read your Practical writeup. Underline the parts where you noted your own failures of moderation. If you did not underline anything, you were probably too kind to yourself; reread the session recording and try again.
  • For your Analysis, ask yourself: would the design lead of the game you analyzed find your findings actionable, or would they roll their eyes? If the latter, the findings are too vague.
  • For your Design protocol, consider: could a playtest moderator who has never tested this genre run a session using your protocol? If not, it is too abstract.
  • For your Critical essay, check: did you identify the specific playtest practice missing, or did you handwave at "they should have tested more"? The former is craft; the latter is criticism.

Save all four deliverables. The Practical writeup in particular is a useful baseline you can compare against later sessions to track your moderation skills improving.

The chapter argued that playtesting is the most important skill no designer wants to practice. The exercises argued the same point, by making you do it. The lesson of both: there is no shortcut, and the only way to get better is repetition with reflection. Run another playtest next week. Run one the week after. Six months from now, the silence in the room will not feel as long.