Game Design

Game Design Document 策划设计

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

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

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

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

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

涉及资源供需、奖励分布、成长曲线或解锁变更时，使用 [成长与经济](references/progression-economy.md)，按问题展开模型、算例和保存边界；不默认项目需要等级、货币或跨局成长。

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

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

当前专业参考为 [战斗](references/combat-design.md)、[射击](references/shooting-design.md)、[探索与冒险](references/exploration-adventure-design.md)。它们是可组合的参考，不是项目分类或功能清单；只读取本轮相关部分。射击可用于没有伤害的发射机制，探索可以没有战斗，跨活动关系要单独分析，不能分别套模板后拼接。

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

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

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

规则与系统

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

修订与宿主

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

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: openaigames
• Source: openaigames/OpenAIGamesDesigner
• License: MIT

Install and usage instructions live in the source repository linked above.