Back to Details

gdd-writing

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

GDD Writing

GDD写作

Purpose

目的

Create or update a Game Design Document that is actionable for design, engineering, QA, production, and content teams.
创建或更新一份可供设计、工程、QA、制作及内容团队落地执行的游戏设计文档。

Use When

适用场景

  • starting a new game or major feature
  • the current design intent is fragmented across chats and tickets
  • systems, loops, or content rules need a durable source of truth
  • 启动新游戏或重大功能开发时
  • 当前设计意图分散在聊天记录和工单中时
  • 系统、循环机制或内容规则需要一个可靠的事实来源时

Inputs

输入信息

  • product pillars and target audience
  • core loop assumptions
  • feature list and scope constraints
  • known technical or production constraints
  • 产品核心支柱与目标受众
  • 核心循环机制假设
  • 功能列表与范围约束
  • 已知技术或制作约束

Process

流程

  1. define the player promise, pillars, and target audience
  2. describe core and supporting loops with clear rules
  3. document feature behavior, progression, UI, content, and edge cases
  4. separate goals, assumptions, decisions, and open questions
  5. hand off sections that need technical, QA, or production follow-up
  1. 定义玩家承诺、核心支柱与目标受众
  2. 清晰描述核心及辅助循环机制的规则
  3. 记录功能行为、进度、UI、内容及边缘情况
  4. 区分目标、假设、决策及待解决问题
  5. 将需要技术、QA或制作团队跟进的部分移交出去

Outputs

输出成果

  • current GDD
  • feature sections with acceptance criteria
  • open questions list
  • cross-discipline follow-up items
  • 当前版本GDD
  • 带有验收标准的功能模块
  • 待解决问题清单
  • 跨部门跟进事项

Quality Bar

质量标准

  • every system section states player-facing rules concretely enough that a developer could implement them without asking the designer
  • each feature section carries acceptance criteria QA can test against
  • decisions, assumptions, and open questions are kept in separate, labeled lists
  • the document reflects the game as currently intended — superseded sections are removed or marked, never left to contradict
  • 每个系统模块都需明确阐述面向玩家的规则，确保开发者无需询问设计师即可实现
  • 每个功能模块都包含QA可用于测试的验收标准
  • 决策、假设及待解决问题分别存放在标记清晰的独立列表中
  • 文档需反映当前既定的游戏设计——过时内容需移除或标记，绝不能保留矛盾内容

Common Failure Modes

常见失误

  • describing intent ("combat should feel punchy") without rules a developer can implement
  • features documented without acceptance criteria, leaving QA to guess
  • the GDD silently diverging from what was actually built after iteration
  • open questions buried inside prose instead of tracked in the open questions list
  • 仅描述设计意图（如“战斗应充满打击感”），却未给出开发者可实现的具体规则
  • 功能文档未包含验收标准，导致QA只能自行猜测
  • 迭代后GDD未同步更新，与实际开发内容悄然脱节
  • 待解决问题隐藏在正文段落中，未在待解决问题清单中追踪

Related Agents

相关Agent

  • gdd-designer
  • planner
  • systems-designer
  • producer
  • gdd-designer
  • planner
  • systems-designer
  • producer

Related Commands

相关命令

  • gdd
  • plan
  • update-docs
  • gdd
  • plan
  • update-docs

Notes

注意事项

  • Keep this skill aligned with the relevant rules layer and current project documentation.
  • If engine-specific constraints materially change the workflow, hand off to the matching engine skill or engine-specific reviewer.
  • 确保本技能与相关规则层及当前项目文档保持一致。
  • 若引擎特定约束对工作流程产生实质性影响，需移交至匹配的引擎技能或引擎特定审核人员处理。