Files
gplan-2/.claude/docs/templates/game-design-document.md
T
2026-09-14 18:18:49 +08:00

153 lines
5.0 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
<!-- 模板 v2(2026-09-14):参考 analysis/design 两件套重构,覆盖 design-system 内置骨架。
design.md 只写结论;设计推演(候选取舍/机理/理由)写 companion:
design/gdd/analysis/[system-name].md(骨架见本文件末尾注释)。
门禁:tools/gdd_lint.py(design.md 写作时逐条对照,提交前必须 PASS;
analysis 件以推演散文为主,不入 GDD 门禁)。
门禁对应:段落 ≤240 字(R1) · 表格占比 ≥30%(R2) · 无修订注记(R3) · 版本历史(R4)
· 流程节含图(R5) · 括号跨度 ≤80(R7) · 节点 ≤80 行(R9)。 -->
# [系统名称]
> **状态**:In Design · **版本**:v1 · [日期]
> **一句话**:[这个系统做什么,一句话,≤30 字]
> **推演件**:`design/gdd/analysis/[system-name].md`(本文件只收结论,理由在那里)
## 设计目的
<!-- 一段定位(≤3 行)+ 3-5 条编号体验承诺(玩家视角一句话)。
玩家看不见的基础设施系统:体验承诺改为"它让谁、在哪一步、省掉什么"。 -->
[一段定位:这个系统为什么存在,游戏少了它会失去什么。]
1. [玩家视角体验承诺]
2. [体验承诺]
3. [体验承诺]
## 系统范围
<!-- 边界优先条款:两份清单是本 GDD 最承重的内容——实现者靠"不负责"判断票面。
与 systems-index 依赖分层保持一致;划给邻系统的条目注明归属。 -->
负责:
- [能力/数据/规则]
不负责:
- [明确不做/划给谁的内容——括注归属系统]
## 核心循环
<!-- 主流程 mermaid 或字符画(``` 围栏);分支/结局用出口分发表。禁止散文描述步骤。 -->
```mermaid
flowchart TD
A["起点"] --> B["..."]
```
| 结局 | 触发 | 结果 |
|---|---|---|
| | | |
## [领域章节](按系统自定义 2–6 节)
<!-- 系统的实体内容按领域拆节(参考写法:地块状态 / 水规则 / 出战输出)。
每节形态:状态/枚举/字段一律表格;规则一律编号人话句(谁·何时·做什么),
边界内联在句尾("不做 X""不返还 Y");每节末尾可加一行"设计意图"(≤1 行),
更长的理由去 analysis 件。 -->
### [小节名]
| 状态 | 含义 | 玩家/系统可做 |
|---|---|---|
| | | |
规则:
1. [谁]在[什么情况]下[做什么];[边界:不做 X]。
2. [规则二]。
设计意图:[一行;为什么是这条而不是别的——超过一行去 analysis。]
## 依赖与输出
<!-- 上游/下游一张表:系统 | 性质(hard/soft) | 接口要点(一行)。
数值单一事实源纪律不变:已锁数值进 design/registry,正文只引用不复述。 -->
| 方向 | 系统 | 性质 | 接口要点 |
|---|---|---|---|
| 上游 | | | |
| 下游 | | | |
## P0 最小闭环
<!-- 编号步骤,从玩家动作到结果回收,≤8 步。写不出 8 步内的闭环 = 范围没收敛,
回系统范围节砍。 -->
1. [玩家/系统动作]
2. [……]
3. [结果回流到循环起点]
## P1 / P2 后置
<!-- 优先级诚实条款:本期不做但已经想到的,全部落表并给后置原因。
后置 ≠ 删除;复活任何一行 = 修订本 GDD,不许静默加回。 -->
| 优先级 | 内容 | 后置原因 |
|---|---|---|
| P1 | [内容] | [为什么现在不做——通常是要先验证 P0 的某个前提] |
| P2 | [内容] | [理由] |
## 调参表(无独立数值的系统可省)
<!-- 全部可调参数:字段 | 域 | 默认 | owner。默认值 provisional 必须标注;
已锁数值以 design/registry 为准,本表只登记字段与域,不复述锁值。 -->
| 字段 | 域 | 默认 | owner | 说明 |
|---|---|---|---|---|
| | | | | |
## 验收标准
<!-- 默认形态:目标 | 验证问题——每条可由真人一局内回答。
项目若直接从 GDD 实现并以冒烟验收(如本项目),改用 Given-When-Then 表;
AC/规则/公式编号只出现在举证与依据列,不进人话。 -->
| 目标 | 验证问题 |
|---|---|
| [P0 闭环成立] | [玩家能否……/当……时系统是否……] |
| | |
## 版本历史
| 版本 | 日期 | 改动 |
|---|---|---|
| v1 | [日期] | 初始版本 |
<!-- ==================== companion 模板 ====================
写入 design/gdd/analysis/[system-name].md(不入 lint;每次写入后无需 PASS):
# [系统名称] 设计推演
> 状态:concluded · 本文只装"为什么"——design.md 只收本文的结论。
> 修订时新增问题节,不删旧节(历史即依据)。
## 问题:[一句设计问题]?
### 广度分析
- [候选 A:收益 + 代价]
- [候选 B:收益 + 代价]
- [候选 C:……]
### 深度分析
[1-2 段机理与约束分析,每段 ≤3 行。]
### 综合判断
[定论一段。design.md 对应章节只应出现这里的结论,不复述理由。]
(按需重复「问题」节,每系统 2–4 个为宜;琐碎系统可只写一节。)
==================================================================== -->