game-playtest

AlterLab GameForge -- Structured Playtest Analysis

Playtesting is not asking players if they had fun. It is the disciplined observation of player behavior to identify where the design succeeds and where it fails. The player's mouth lies -- their hands do not. Nintendo has known this for decades: Miyamoto famously watches players silently, trusting their confusion over their compliments. Larian ran thousands of community playtests during BG3's Early Access, and every major system change traced back to behavioral data, not forum polls. This workflow provides a rigorous behavioral observation framework that transforms raw playtest sessions into actionable design insights.

Purpose & Triggers

Invoke this workflow when:

• A build is ready for external eyes and you need structured feedback, not just reactions
• Specific design questions need answering: "Do players understand the crafting system?" not "Is the game good?"
• Onboarding flow needs validation -- can new players learn the core mechanic without a tutorial?
• Difficulty curve assessment -- are players in the flow channel or oscillating between boredom and frustration?
• A new feature has been integrated and its impact on the overall experience is unknown
• Pre-release polish pass needs data on which rough edges matter most to players
• Competitive analysis requires side-by-side comparison with a reference game

Do NOT use this workflow when:

• You need to test a raw mechanic in isolation (use game-prototype instead)
• The build is so broken that testers will spend most of their time hitting bugs (fix critical bugs first, then playtest)
• You want marketing quotes or positive testimonials (that is PR, not playtesting)

Critical Rules

1. Define questions before inviting testers. Every playtest answers specific questions. "Is it fun?" is not a question -- it is a prayer. "Can players complete the first dungeon without dying more than twice?" is a question. Celeste's playtests asked "can players learn the dash mechanic within the first three screens?" -- specific, observable, actionable.
2. The facilitator does not play. You observe. You take notes. You do not help, explain, suggest, or react. Your poker face is a scientific instrument.
3. Minimum 5 testers per session. Fewer than 5 and you are collecting anecdotes, not data. Individual player quirks dominate small samples. At 5+ testers, patterns emerge.
4. Never test with the development team. They know too much. Their muscle memory, mental models, and context make them incapable of experiencing the game as a new player. Nintendo's internal playtesting teams are deliberately kept away from development discussions so they approach each session cold. Your developers are blind to every onboarding problem they have already internalized.
5. Behavioral data outranks verbal data. If a player says "the controls feel fine" but you observed them pressing the wrong button 11 times in a 10-minute session, the behavioral data wins. Always. Larian tracked BG3 playtester behavior at the input level -- they knew which dialogue options players hovered over before choosing, and that hesitation data informed their rewrite of Act 1.
6. Separate observation from interpretation. During the session, record what happened. After the session, interpret what it means. Mixing the two in real-time creates confirmation bias.
7. Reference docs/game-design-theory.md for Flow Theory and MDA Framework when analyzing player engagement and emotional responses.