Skip to content
Practices
BP #7: Playtesting Checkpoint

BP #7: Playtesting Checkpoint

Schedule at least one external playtesting session on day 2. One player, 15 minutes, before hour 40.

Why It Works

After 30 hours building the same game, you cannot see it the way a new player does. You know where everything is, why every system behaves the way it does and what the controls mean. That familiarity hides exactly the problems that will hurt ratings.

Kaitila puts it directly: games tested only by their creator regularly end up at the wrong difficulty, too hard more often than too easy. Getting someone outside the team to play it catches difficulty spikes, bad controls and anything that is hard to figure out before a stranger encounters it at submission. [2]

Hyper Holomayhem and HourGlass Collector

Both teams in LD37 brought in friends for feedback during production, not just at the end. HourGlass Collector adjusted difficulty based on what those players struggled with. Hyper Holomayhem used the feedback to confirm their core loop worked before adding more content. [1] Feedback arrived while there was still time to act on it.

How to Apply

  • Identify one person (friend, teammate from another jam) before the jam starts
  • Schedule the session for day 2, hour 36–40
  • Give them zero explanation. Watch them play cold.
  • Note what they get stuck on, what they ignore and what they misunderstand
  • Make targeted fixes only. Do not redesign.

The goal is not “is this fun?” The goal is “can someone play this without me explaining it?”

Methodology Connection

Methodology Connection

Scrum’s Sprint Review exposes completed work to outside perspective at the end of each iteration so the team can inspect and adapt. At 48-hour scale the playtesting checkpoint performs the same function, compressed to 15 minutes and timed for when fixes are still possible.

Related

BP #6: Pivot Gate at Hour 24BP #8: Definition of Done