← Back to Godot · project planning pack

Skill · Version 1.0.0

Playtest questions and telemetry

Turns a design question into a focused playtest with interpretable observations. Defines what to record and compare while keeping player explanations, measured actions and designer assumptions distinct.

game-playtest-telemetry

Agents using this skill

See how it helps

When is it useful?

Use when deciding what a playtest should establish or interpreting incomplete gameplay data.

What does it help you do?

  • Separates observed actions, player explanations and designer inference.
  • Defines events, denominators and build versions for a small relevant metric set.
  • Recognizes biased samples and proposes a next experiment without claiming unsupported causality.

Try asking this

Players often stop at the second puzzle room. Record room entry, attempts, hints and exits with the tested build version, then ask players what they expected. Compare completion and time-to-first-action before and after one hint change, and explain sample limits instead of claiming that a small test proves causation.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

Playtest Questions and Gameplay Evidence

Start with a specific design uncertainty and the decision the evidence will inform. Define participant context, build/configuration and an observable scenario before adding metrics.

  • Separate observed action, player explanation, designer inference and unknown cause. A completion or abandonment count does not by itself explain motivation.
  • Choose a few metrics tied to the hypothesis: time to first meaningful action, failed attempts by cause, resource flow, choice frequency, recovery or encounter outcome. Define denominators and observation windows.
  • Keep event semantics and units stable, with build/config version and a bounded session identity where appropriate. Distinguish repeated attempts from distinct participants.
  • Use the existing analytics setup and collect only what the task needs. Adding external collection, identifying players or contacting/recruiting participants needs the appropriate explicit scope.
  • Treat biased samples, missing events, small cohorts and changed build conditions as limitations. Do not claim causality or broad retention improvement from an uncontrolled comparison.
  • Turn findings into a small next experiment with expected observations, preserving useful counterexamples rather than selecting only favorable sessions.

Deliver scenario, observation notes, metric definitions, findings and uncertainty. A scripted agent run can reveal mechanics defects but is not a substitute for human experience evidence.

Reference: the adapted upstream level-design workflow. No external analytics service or playtest outreach is activated by this skill.

Included files 2

  • LICENSE.txt
  • SKILL.md