/game-design-playtest

name: game-design-playtest
description: 将游戏体验目标变成机制、状态、试玩问题与行为证据 game design core loop playtest economy accessibility

游戏机制与试玩研究

用明确的机制与观察任务检验玩家体验假设，区分设计意图、实际行为、可复现问题和下一轮调整。

开始前

• `experience`：目标玩家、使用情景、期望体验与设计问题 缺失时：先形成假设和可观察问题，不假装知道用户喜欢
• `prototype`：规则、状态、操作、关卡/经济参数与版本 缺失时：未有原型只交设计/测试计划
• `testContext`：已有试玩记录、招募条件、设备、辅助与数据权限 缺失时：无观察不生成玩家反馈

执行

1. 阅读 [工作方法](references/professional-method.md)，先确定适用条件与证据范围。 2. 沿 [专业方法](method.json) 的 `steps` 执行具体操作，再用 [完整交付模板](references/delivery-template.md) 整理当前产物；诊断问题与空字段不能充当完成。 3. 按 [专业质量规则](method.json) 中的具体输出规则选择检查方法，保存本次输入/产物定位及未观察项。 4. 对照 [作者正反例](evals/professional-cases.json) 检查常见专业错误；作者预期不算本次评测结果。 5. 把规则结果、实际产物、未决问题交回调用方；缺口仅影响相关结论。

交付

• `designModel`：体验到机制和状态的映射。
• `testPlan`：围绕设计问题的试玩任务。
• `observations`：真实行为与证据分层。
• `iterationDecision`：机制/数值调整与后续验证。
• `facts`：当前输入、来源、期间单位及证据缺口。
• `limitations`：未执行、未观察、方法假设和外推边界。
• `handoff`：当前产物、规则结果、证据定位与待解决事项交调用方。

关键验收条件

• `designModel`：核心循环写目标、动作、反馈、资源/风险、成功失败与恢复；参数有来源和配置位置。 拒收：只写爽/沉浸等形容词，无状态和可观察规则。
• `testPlan`：每项任务对应假设、参与者/设备、观察指标、辅助规则和可反驳条件。 拒收：引导玩家正确操作后把结果当自然可用，或仅问好不好玩。
• `observations`：分开实际行为、原话、研究者解释、合成演示与未观察，附版本和来源。 拒收：编造玩家反馈或把设计者自测称代表用户研究。
• `iterationDecision`：每个调整关联证据、机制假设、影响和下一轮观察，同时检查奖励可重复性/成本/可达性。 拒收：一条主观意见就承诺留存营收，或引入无成本无限奖励却未检查。

全部检查方法、证据要求和阻断标记以 [method.json](method.json) 为准。规则未执行时记录未观察；教学案例不是已经完成的专业评测。

边界

不虚构玩家测试、留存或营收效果，不以少量主观好玩评价证明市场成功。

上线、付费与重要玩家权益变更交项目负责人确认；涉及未成年人数据或商业化规则另核适用要求。

只读本次指定材料；实际联网、命令、发布、业务变更或外部消息依当前宿主授权。方法不接管跨组件调度、持久记忆或最终验收。合同和示例检查不证明真实宿主或行业效果；无执行证据保留 needs_probe / not_evaluated。