Game Design Document 策划设计

本 Skill 维护系统规则与跨系统关系。定量模型与平衡设计由 game-numerical-design、战斗/射击由 game-combat-design、关卡由 game-level-design、界面流程由 game-ui-ux 维护详细方法；本入口保留导航和专业接口。只需一个专业时直接进入，不先完成全部策划文件。阶段与设计深度按当前任务目标决定：完整策划可交付制作所需规格，但文档完成不代表机制或品质已经实证。

规则修改先落在 GDD 或负责该规则的详细规格，再检查表现资产、技术接口和验证的依赖。专业总入口链接详细规格；参数引用实际生效配置，不维护第二份数值。 跨方向工作按 变更联动 关联同一变更入口并更新管理摘要；仅安装本 Skill 时沿用项目现有变更记录，缺少管理 Skill 不阻塞本专业工作。

新作 GDD 入口由管理流程先建立；内容可以待讨论，进入实施时需记录当前规则和假设。已实现内容发生变化时更新正文及管理索引，避免仍保留初始占位。

用户要求做出原型也属于实施任务，应采用 实施阶段的规则交付，不能停留在初期系统概述。读者应能确定操作在各状态下的结果、主要例外与重置行为，并找到生效参数和验证入口；只列功能名称、按键或代码路径不足以交接玩法。

玩家操作、按键/手柄映射等逐项信息使用操作表，分开动作、设备与输入、触发方式、可用条件、行为反馈及状态依据，不仅写成一段“WASD 移动、空格闪避”的说明。格式见 玩家操作表。规则理由仍用短段落；多设备或上下文拆行，未知映射留待定，不从例子推定按键。已有权威输入规格原位维护并由 GDD 链接，不维护相互冲突的两套绑定。

新项目从模糊体验进入实现时，先识别会改变玩家行动与反馈的关键未知，不把“应对”默认解释为某一种动作。明确选择或用户授权采用默认方案后，将当前规则及暂定参数保存为 GDD/功能规格再交接；不要仅在代码生成后将参数说明补写成设计依据。已有工程的小改动只更新相关规格。

涉及资源供需、奖励分布、成长曲线或解锁变更时，使用 成长与经济，维护资源用途、解锁、交易和保存边界，定量模型与曲线按需交接数值策划；不默认项目需要等级、货币或跨局成长。

涉及批量数值、计算曲线、用户自行编辑表格或把调参带回工程时，直接使用 数值策划 及其 数值表与调参。按需生成可编辑雏形，区分候选、已确认和实际配置；读取用户回传的真实文件并按稳定 ID 比较，交由技术侧校验和写回，不能把表格已更新当作工程已生效。

从用户的创意、目标和现状识别当前任务设计问题，使用 设计推理与参考选择。先理解玩家行动、选择、后果与系统联系，再按需选择方法，不要求用户选择游戏类型，不从标签或参考作品推导必备系统。没有匹配专题仍可根据项目目标提出规则、记录假设并验证。

当前专业参考为 战斗、射击、探索与冒险。它们是可组合的参考，不是项目分类或功能清单；只读取当前任务相关部分。射击可用于没有伤害的发射机制，探索可以没有战斗，跨活动关系要单独分析，不能分别套模板后拼接。

涉及区域和流程编排使用 关卡设计；涉及控制、镜头和环境对象使用 移动与交互；涉及信息、焦点、操作流程和教学使用 UI/UX。按实际问题组合，与相关规则共享状态来源，不要求每轮加载全部专题。

新作初期使用 references/outputs.md。新增或修改玩法、规则、系统或详细内容时读取 功能规格与设计变更，按当前任务功能展开而非重写全部 GDD。初期模板中的简化约束只适用于立项任务，不限制已有项目所需的详细设计。

维护 Game Design Document.md 或项目已有的设计文档与专项规格。读取与当前任务有关的体验目标、用户选择和玩法资料；已有工程还要核对相关配置、实现与试玩证据。缺少会改变系统设计的关键需求时才聚焦反问；不自行决定项目理念，不为了填齐系统而加入用户未要求的机制。

规划可由需求或素材进入：职责明确时提出必要行为再找资源；玩法未定、已有资源可复用或预算/周期受素材供给限制时，可主动先搜索并检查资源能力，再形成职责、玩家选择和规则。通用探索见 素材检索与获取，角色/敌人组合见 角色职责与素材适配。单独安装时沿用同一判断记录到现有规格，无需补齐整份 GDD 才能探索。区分用户已定目标、素材启发的候选和待验证假设；玩家装备不自动成为敌人要求，素材也不能静默改掉已定选择。

规则与系统

• 核心循环写出行动、决策、成本、反馈与状态变化；长期循环写出短期成果怎样改变下一次选择。没有跨局成长时不强行增加。
• 系统设计需解释组成及它们对玩家选择的影响，复杂时用系统树与关系图互补，简单关系可直接说明；小改动不强制绘图。不能只列系统名称。内容和成长若承载核心体验，不因“最小化”而从产品模型中删掉。
• 立项阶段仅按需要概述战斗、移动、敌人功能角色、关卡、成长、装备、经济、任务、社交/多人等系统；不套用示例中的全部系统。关键规则描述条件、选择、成本、反馈、成功/失败、持久状态和例外。具体数值按问题所需补充，未知不编造；关卡解释路线、信息、风险与目标之间的关系。
• 逆向分析把已证实规则、观察、推断和待查细则分开，注明版本与配置。不要因为同属一个类型，就补上限时、永久死亡、随机生成或联网等未核实规则。复述设计意图不能证明机制效果。
• 只有原型任务才缩小范围，且要保留回答实验问题需要的完整因果链。产品完整设计与当前任务实验范围分开保存。

修订与记录维护

默认维护 Game Design Document.md 或现有功能规格，关联规则、设计支柱和待验证判断。保存后同步已有项目管理入口中的文档状态和变更摘要；其他专业正文的潜在影响标为待复核，不擅自重写。用户指定记录系统的字段时只修改允许范围，文档计划不等于已提交的机制制作任务。不代替用户批准，不生成或启动看板。