Compare commits
8 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 lhk229
|
89a901e329 | ||
|
lhk229
|
46024b5043 | ||
|
lhk229
|
8484a30d49 | ||
|
lhk229
|
c6a0844b50 | ||
|
lhk229
|
c7ac4f3bab | ||
|
lhk229
|
155f0d316a | ||
|
lhk229
|
6ed1fd26ed | ||
|
lhk229
|
4912aa4df0 |
@@ -30,6 +30,7 @@ The hosted MCP offers the following tools. Choose the task tool when its action
|
||||
| `PATCH /api/external/v1/editor/assets/{assetId}` | `organize_asset_library` (`update_asset`) | `update_editor_asset` |
|
||||
| `DELETE /api/external/v1/editor/assets/{assetId}` | `delete_resources` (`delete_asset`) | `delete_editor_asset` |
|
||||
| `POST /api/external/v1/editor/images/generations` | `generate_image`, `modify_image` (`variation`, fixed `kind="quick-edit"`) | `generate_external_editor_image` |
|
||||
| `POST /api/external/v1/editor/scenes/generations` | structured game-scene generation (no hosted MCP tool yet) | `generate_external_editor_scene` |
|
||||
| `POST /api/external/v1/editor/images/edits` | `modify_image` (`edit`) | `edit_external_editor_image` |
|
||||
| `POST /api/external/v1/editor/images/background-removals` | `modify_image` (`remove_background`) | `remove_external_editor_image_background` |
|
||||
| `POST /api/external/v1/editor/icon-spritesheets/generations` | `generate_icon_spritesheet` | `generate_external_editor_icon_spritesheet` |
|
||||
@@ -89,6 +90,7 @@ Every generation row requires a stable `Idempotency-Key` header and returns HTTP
|
||||
| Capability | POST path | Required body fields | Common optional body fields |
|
||||
| ------------------- | ------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Image generation | `/api/external/v1/editor/images/generations` | `prompt` | `kind`, `style`, `model`, `aspectRatio`, `imageSize`, `size`, `referenceImageSrcs`, `projectId`, `assetFolderId`, `assetLabel`, `canvasCompletion`, `generationInputs` |
|
||||
| Game scene | `/api/external/v1/editor/scenes/generations` | `sceneContent`, `stylePreset` | `customStyle` (required when `stylePreset="custom"`), `model`, `aspectRatio`, `imageSize`, `referenceImageSrcs`, `projectId`, `assetFolderId`, `assetLabel`, `canvasCompletion`, `generationInputs` |
|
||||
| Image edit/redraw | `/api/external/v1/editor/images/edits` | `prompt`, `sourceReferenceId` | `referenceImageSrcs`, `model`, `size`, `projectId`, `assetFolderId`, `assetLabel`, `targetLayerId`, `canvasCompletion` |
|
||||
| Background removal | `/api/external/v1/editor/images/background-removals` | `sourceImageSrc` | `projectId`, `sourceResourceId`, `targetLayerId`, static-image `assetKind`, `assetFolderId`, `assetLabel`, `canvasCompletion`, `generationInputs` |
|
||||
| Icon spritesheet | `/api/external/v1/editor/icon-spritesheets/generations` | `referenceId`, `iconDescriptions`, `sliceMode` | `gridX`, `gridY`, `sliceCount`, `style`, `referenceImageSrcs`, `screenColor`, `model`, `aspectRatio`, `imageSize`, `projectId`, `assetFolderId`, `assetLabel`, `canvasCompletion` |
|
||||
@@ -98,7 +100,7 @@ Every generation row requires a stable `Idempotency-Key` header and returns HTTP
|
||||
| Sound effect | `/api/external/v1/editor/audios/sound-effects/generations` | `prompt` | `model`, `duration`, `loop`, `projectId`, `assetFolderId`, `assetLabel`, `canvasCompletion`, `generationInputs` |
|
||||
| Background music | `/api/external/v1/editor/audios/background-music/generations` | `gptDescriptionPrompt`, `makeInstrumental` | `projectId`, `assetFolderId`, `assetLabel`, `canvasCompletion`, `generationInputs` |
|
||||
|
||||
Poll all nine through:
|
||||
Poll all ten through:
|
||||
|
||||
```text
|
||||
GET /api/external/v1/generations/{operationId}
|
||||
@@ -140,7 +142,7 @@ The icon-spritesheet primary `referenceId` is intentionally stricter than ordina
|
||||
Use OpenAPI as the final authority; these common values are a routing aid:
|
||||
|
||||
- Image `kind`: `spec`, `character`, `quick-edit`, `ui-design`, `publication-material`; ordinary image generation may omit it.
|
||||
- External v1 currently has no structured game-scene generation operation. Do not send `kind: "scene"` or `assetKind: "scene"` through generic image generation; the server rejects both before queueing.
|
||||
- Game scenes must use the dedicated structured route `POST /api/external/v1/editor/scenes/generations` (`sceneContent` + `stylePreset`; `customStyle` required for `custom`). Do not send `kind: "scene"` or `assetKind: "scene"` through generic image generation; the server rejects both before queueing. The scene route assembles the full provider prompt server-side and never accepts a caller-assembled `prompt`.
|
||||
- Image `model`: `gpt-image-2`, `gemini-3.1-flash-image-preview`, `nanobanana2`, `nano-banana`.
|
||||
- Image `aspectRatio`: `1:1`, `2:3`, `3:2`, `9:16`, `16:9`.
|
||||
- Image `imageSize`: `0.5K`, `1K`, `2K`.
|
||||
|
||||
@@ -148,7 +148,7 @@ For the lower-level asset/resource creation endpoints, `generationInputs` is rep
|
||||
|
||||
## Art Spec and Image Request
|
||||
|
||||
Generic External v1 image generation does not expose the main-site structured game-scene contract. `kind: "scene"` and `assetKind: "scene"` are both invalid and return HTTP `400` before any generation job is queued. Do not replace the structured scene fields and server-owned prompt assembly with a generic image prompt.
|
||||
Game scenes have a dedicated structured route: `POST /api/external/v1/editor/scenes/generations` with `sceneContent` and `stylePreset` (`customStyle` required when `stylePreset` is `custom`). The server assembles the full provider prompt; a caller-assembled `prompt` is not accepted. `kind: "scene"` and `assetKind: "scene"` remain invalid on generic image generation and return HTTP `400` before any generation job is queued.
|
||||
|
||||
When maintaining a reusable art spec, carry it in `generationInputs.artSpec` and reflect important constraints in the prompt. This is an example with both canvas and library destinations, not a requirement for every generation:
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
共享过程文件（如需维护，请使用这些相对路径）：
|
||||
- project/analysis.md
|
||||
- project/决策台账.md
|
||||
- project/dialog.md
|
||||
- project/analysis.md：重要取舍的依据与当前结论。
|
||||
- project/决策台账.md：待处理事项与下一步，必要时引用相关文档。
|
||||
- project/dialog.md：仅在用户需要时记录对话摘要或交接信息。
|
||||
正式产物使用当前阶段指定的相对路径。
|
||||
五个策划阶段的审批：当你判断当前策划阶段必需产物已完成时，必须提交阶段审批。用户批准后进入下一阶段。
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
概念阶段定稿时，创建或更新 `project/速览卡.md`。下面是速览卡的参考结构；根据游戏类型、项目规模和用户要求选择适用字段，同类内容可以合并，复杂项目可以增加必要字段。表格和列表中的示例行按实际对象逐行扩展：
|
||||
概念阶段定稿时，创建或更新 `project/速览卡.md`，简要介绍当前游戏。后续仅在核心体验、范围、平台等概览内容变化时更新，不复制完整决策清单。下面是速览卡的参考结构；根据游戏类型、项目规模和用户要求选择适用字段，同类内容可以合并，复杂项目可以增加必要字段。表格和列表中的示例行按实际对象逐行扩展：
|
||||
|
||||
# 速览卡：《游戏名》
|
||||
|
||||
|
||||
@@ -1 +1 @@
|
||||
当前阶段：顶层设计。明确玩家持续游玩的循环、资源流、节奏和系统范围。
|
||||
当前阶段：顶层设计。明确游玩过程、关键规则与反馈、版本范围和验证计划，为系统划分提供依据。
|
||||
|
||||
+6
-64
@@ -1,66 +1,8 @@
|
||||
# 决策台账：《星露谷物语》金样项目
|
||||
# 决策台账：《星露谷物语》示例项目
|
||||
|
||||
版本：v3 | 规则：台账放活队列——design 只放结论、分析只放论证、决定与开放问题住这里。编号连续不复用；被推翻的行标 overturned 挂新行，不删行。
|
||||
状态六态：`confirmed`（用户亲口/亲选）/ `auto_decided`（技术类代决，必带理由＋推翻条件，用户一键可翻）/ `default_pending`（默认建议兜底，用户未点头）/ `prototype_pending`（待原型验证）/ `pending_user`（等用户拍板）/ `overturned`（被推翻，挂旧行编号）。
|
||||
仅列仍需跟进的事项和下一步。详细依据与采用的规则见相关分析和设计文档；事项完成后移出待办。
|
||||
|
||||
> 编号口径：D-01~D-13 与 templates/stardew-analysis.md 台账节选一致（D-04~D-06、D-08~D-10、D-12 原为"就地小权衡，直接登记未开条目"，此处按登记口径展开）；D-14 起为技术文档期新增，与 stardew-tdd-tech.md 开放问题回执互引。
|
||||
|
||||
## 当前待办（活队列）
|
||||
|
||||
### 等用户拍板（pending_user）
|
||||
|
||||
| 编号 | 决定 | 层 | 谁 | 依据 | 推翻条件 | 状态 |
|
||||
|---|---|---|---|---|---|---|
|
||||
| D-14 | 体力与战斗共享单池 | TDD | user | 风险资源统一制造取舍（概念张力一）；**暂按共享实现，改单拆只需改 S02 成本入口** | 战斗参与率实测过低（玩家回避矿井） | pending_user（暂按共享实现） |
|
||||
| D-15 | 背包格子制 vs 重量制 | TDD | user | 格子制直觉、重量制焦虑感与 T5"休闲不打卡"冲突；暂按格子制实现、存档预留 capacity_type 字段 | 格子管理成为主要负面反馈 | pending_user（B 级阻断存档结构，暂按格子制） |
|
||||
|
||||
### 待原型验证（prototype_pending）
|
||||
|
||||
| 编号 | 决定 | 层 | 谁 | 依据 | 推翻条件 | 状态 |
|
||||
|---|---|---|---|---|---|---|
|
||||
| D-13b | 战斗判定窗口手感（前摇帧数/无敌帧 450ms 基准） | 系统 | user | 数值可定、手感不可纸面验证 | 原型显示节奏拖慢/玩家困惑 | prototype_pending（规则本体见 D-13 confirmed） |
|
||||
|
||||
### 默认建议兜底（default_pending）
|
||||
|
||||
| 编号 | 决定 | 层 | 谁 | 依据 | 推翻条件 | 状态 |
|
||||
|---|---|---|---|---|---|---|
|
||||
| D-19 | 天气权重表具体数值（晴/雨/风暴按季节） | TDD | agent | 概念层只定"雨免浇水"定性；数值推内容期填 | 前 5 日出现连续 3 日雨/全无雨 | default_pending（默认值已进数据表，带 designer_note） |
|
||||
|
||||
## 已采用决定
|
||||
|
||||
### 用户确认（confirmed）
|
||||
|
||||
| 编号 | 决定 | 层 | 谁 | 依据 | 推翻条件 | 状态 |
|
||||
|---|---|---|---|---|---|---|
|
||||
| D-01 | 定调：牧场物语系参照、治愈慢节奏 | 概念 | user | 用户原始需求 | — | confirmed |
|
||||
| D-02 | 单人体验，无多人 | 概念 | user | 概念层非目标 | — | confirmed |
|
||||
| D-03 | 战斗保持伴生风险，不做装备驱动主轴 | 概念 | user | 概念期问题一 | 矿井流失率过半且归因战斗 | confirmed |
|
||||
| D-07 | 日目标自设，季节与社区提供低频牵引 | 顶层 | user | 顶层期问题一 | 新手周流失归因无方向 | confirmed |
|
||||
| D-11 | 采集/钓鱼/战斗统一"活动结果"接口 | 架构 | user | 架构期问题一 | 第三活动类型出现结构性差异 | confirmed |
|
||||
| D-13 | 战斗采用节奏/指令判定 | 系统 | user | S06 问题一 | 原型显示节奏拖慢/玩家困惑 | confirmed（手感部分拆 D-13b prototype_pending） |
|
||||
|
||||
### 技术代决（auto_decided——带理由与推翻条件，用户一键可翻）
|
||||
|
||||
| 编号 | 决定 | 层 | 谁 | 依据（理由） | 推翻条件 | 状态 |
|
||||
|---|---|---|---|---|---|---|
|
||||
| D-04 | 时间片制：700ms=10 游戏分钟 | 概念 | agent | 原作实证节拍；一天≈14 分钟真实时间贴合 T5"休闲" | 内测一天体感过短/过长 | auto_decided |
|
||||
| D-05 | 分区域切换（区域独立场景，非连续地图） | 概念 | agent | 概念层"不是什么：无边界开放世界"；区域小网络全部步行可达 | 场景切换成为移动负担反馈 | auto_decided |
|
||||
| D-06 | 28 日/季、四季/年 | 顶层 | agent | 季节窗口制造"本季计划"节奏（支柱二） | 换季频率在测试中被无视 | auto_decided |
|
||||
| D-09 | 商店营业时段走条件表 | 架构 | agent | 与配方/区域解锁共用 check(condition_id) 单一入口 | 条件表规模膨胀难维护 | auto_decided |
|
||||
| D-10 | 出货箱日终统一结算 | 架构 | agent | 收入集中进日终面板，强化"一天一结算"叙事；商店现卖保留即时通道 | 玩家普遍绕开出货箱 | auto_decided |
|
||||
| D-12 | 工具升级期间该工具不可用 | 系统 | agent | 升级=时间成本换效率（顶层张力二）；备用旧工具暂不做（开放问题） | 升级期挫败感集中爆发 | auto_decided |
|
||||
| D-16 | 矿井逐层生成本期不做（P2） | TDD | agent | GDD 已标"不做无限地牢"；首期按布局池 8~12 模板拼装 | 内测要求深度爬塔玩法 | auto_decided |
|
||||
| D-17 | 换装首期 5 层（基础体/裤/衣/发型/饰件），非 19 层 | TDD | agent | 外观自定义非首期卖点；层结构预留到 19 层 | 外观系统成核心诉求 | auto_decided |
|
||||
| D-18 | 作物品质三档：普通/银/金 | TDD | agent | 经济分层需要（即时变现 vs 等待升值的取舍） | 银金档无人区分、一律普通出售 | auto_decided |
|
||||
|
||||
### 已推翻（overturned——旧行保留，挂新行）
|
||||
|
||||
| 编号 | 决定 | 层 | 谁 | 依据 | 推翻条件 | 状态 |
|
||||
|---|---|---|---|---|---|---|
|
||||
| D-08 | 作物品质两档：普通/银 | TDD | agent | 早期小权衡：两档最简 | — | **overturned → D-18**（经济分层不足，改三档；铱档留 P1） |
|
||||
|
||||
## 队列纪律（使用说明）
|
||||
|
||||
- 新决定入队：拿下一号（当前最大 D-19，下一号 D-20）；就现代决可登记不开条目，但状态必须写 auto_decided 并带理由＋推翻条件。
|
||||
- 用户翻案：旧行标 overturned 挂新行，受影响文档节重写（本台账只记录，不代改）。
|
||||
- 概念层变更定稿后：速览卡"决定状态与原型验证项"字段随本文件最新版同步。
|
||||
- 体力与战斗是否共享资源：涉及探索压力和恢复规则，结合用户对战斗体验的要求确认，再更新相关系统设计。
|
||||
- 背包使用格子还是重量限制：在确定存档和界面结构前确认，选择依据记录在分析文档。
|
||||
- 战斗判定窗口的手感：通过矿井原型试玩观察是否易懂、是否拖慢探索，依据见分析文档“战斗判定窗口是否需要调整”。
|
||||
- 天气权重是否合适：用前几天的游玩样本检查连续雨天或长期无雨的影响，再调整配置。
|
||||
|
||||
+13
-17
@@ -1,39 +1,39 @@
|
||||
# 速览卡：《星露谷物语》金样项目
|
||||
|
||||
> 字段来源见每节尾注（概念层/定调记录/决策台账）。概念层变更定稿后本卡必须同步更新。
|
||||
> 本卡概括当前游戏；仅在核心体验、范围、平台等概览内容变化时更新。具体规则和取舍依据见对应设计与分析文档。
|
||||
|
||||
## 1. 游戏名称
|
||||
《星露谷物语》（金样项目沿用案例名；新项目由概念层第 1 节定名）←概念层§1
|
||||
《星露谷物语》（金样项目沿用案例名）←概念设计标题
|
||||
|
||||
## 2. 一句话描述
|
||||
继承一座荒废农场的乡村生活 RPG：安排每天的时间与体力，种田、探索、交朋友，把日子过成自己想要的样子。（←概念层§1 一句话概念，45~90 字）
|
||||
继承一座荒废农场的乡村生活 RPG：安排每天的时间与体力，种田、探索、交朋友，把日子过成自己想要的样子。（←概念层「游戏概念」）
|
||||
|
||||
## 3. 游戏分类
|
||||
乡村生活模拟 RPG（经营+探索+社交；参照系牧场物语）←概念层§1
|
||||
乡村生活模拟 RPG（经营+探索+社交；参照系牧场物语）←概念层「游戏概念」
|
||||
|
||||
## 4. 美术风格（四件）←定调记录＋概念层§4
|
||||
## 4. 美术风格（四件）←概念层「身份、基调与世界观」与美术圣经
|
||||
- 视觉类型：手绘感像素风、俯视 45° 视角。
|
||||
- 风格关键词：温暖、田园、四季分明、生活感。
|
||||
- 色彩与氛围：暖土绿基底+季节信号色整体切换；治愈不压抑；无锐利科技感、无阴暗元素。
|
||||
- MVP 美术边界：首期 3 区域 tileset、8 位 NPC（行走+立绘）、约 120 物品图标、玩家换装 5 层；不做 19 层全量换装与全区域。
|
||||
|
||||
## 5. 游戏支柱（3 条）←设计锚点提炼
|
||||
## 5. 游戏支柱（3 条）←概念层「游戏概念」「体验与玩法」
|
||||
| 支柱 | 玩家感受 | 实现机制 |
|
||||
|---|---|---|
|
||||
| 自己的节奏 | "今天想干嘛就干嘛，明天一切更顺手。" | 自由日程+时间体力预算；无失败结局 |
|
||||
| 今天的选择让明天更从容 | "升级工具、攒钱扩建是有意义的。" | 长期投资线：工具升级/技能/设施 |
|
||||
| 社区让独居变成归属 | "镇上的人在等我。" | NPC 关系/任务/社区修复目标 |
|
||||
|
||||
## 6. 核心循环（5 步）←锚点循环位展开
|
||||
## 6. 核心循环（5 步）←概念层「体验与玩法」
|
||||
安排一天的时间与体力 → 农/采/钓/矿/战/社交任选组合 → 获得资源·金钱·经验·关系 → 投资工具·设施·种子·物品 → 解锁更高效或更丰富的活动。
|
||||
|
||||
## 7. 目标用户 ←概念层§5
|
||||
## 7. 目标用户 ←概念层「目标玩家与情境」
|
||||
牧场物语系慢节奏成长玩家+动森式"无压力日常"需求；单人、可反复、每次一至数个游戏日；不要求预先掌握复杂数值。
|
||||
|
||||
## 8. 平台事实（禁改）
|
||||
Web 浏览器运行 · 双视口（桌面/移动）· 键鼠/触屏双输入 · 本地启动后可在浏览器中试玩。
|
||||
|
||||
## 9. MVP 系统（5 个）←概念层"最小闭环粗清单"
|
||||
## 9. MVP 系统（本例首期范围）
|
||||
| 系统 | 最小功能 | 为什么必须有 | 验证方法 |
|
||||
|---|---|---|---|
|
||||
| 时间与日程 | 时钟/日终结算/季节天气 | 全局节拍器 | 一个游戏日全流程可完成并结算 |
|
||||
@@ -42,18 +42,14 @@ Web 浏览器运行 · 双视口（桌面/移动）· 键鼠/触屏双输入 ·
|
||||
| 物品与制作 | item_id/背包/配方解锁 | 资源身份与转化 | 拾取/堆叠/制作全链无回翻 GDD |
|
||||
| 经济与商店 | 基准价+价差+出货箱 | 投资回报换算 | 第 4 日现金流回正（前五日验算） |
|
||||
|
||||
## 10. 制作边界 ←概念层"不是什么"表
|
||||
## 10. 制作边界 ←概念层「边界与约束」
|
||||
不做：硬核生存（无饥饿/债务/死亡惩罚）；效率至上的工厂经营；以战斗为核心的动作游戏；剧情驱动的任务链主线；多人竞争；无边界开放世界（区域小网络全步行可达）。
|
||||
|
||||
## 11. 创作者提示（先做与验证）←概念层"先做与验证"节
|
||||
## 11. 创作者提示（本例原型验证安排）
|
||||
- 先做：第 1 日循环（买种→播种→浇灌→收获→出售→日终结算）＋一个可进入的矿井遭遇。
|
||||
- 暂不做：装备刷取、随机构筑、复杂剧情、节日全量、联机。
|
||||
- 这样验证：测试者玩完第 1 日后是否主动说"再玩一天"；能否说出"明天要先做什么"。
|
||||
- 达标再扩展：玩家能自述明日计划后，才加社交深度与矿井分层。
|
||||
|
||||
## 12. 决定状态与原型验证项（依据决策台账）
|
||||
- 已确认（confirmed）：定调 D-01 / 单人 D-02 / 战斗伴生 D-03 / 日目标自设 D-07 / 活动统一接口 D-11 / 战斗节奏判定 D-13。
|
||||
- 技术代决（auto_decided，可一键翻案）：D-04 时间片 / D-05 分区域切换 / D-06 28 日季 / D-09 营业条件 / D-10 出货箱日终 / D-12 工具占用 / D-16 矿井生成 P2 / D-17 换装 5 层 / D-18 品质三档（推翻 D-08 两档）。
|
||||
- 等拍板（pending_user）：D-14 体力战斗是否共享单池（暂按共享实现）；D-15 背包格子/重量（暂按格子制，B 级阻断存档结构）。
|
||||
- 待原型（prototype_pending）：D-13b 战斗判定窗口手感（前摇帧数/450ms 无敌帧基准）。
|
||||
- 默认兜底（default_pending）：D-19 天气权重数值（默认已入表，带 designer_note）。
|
||||
## 12. 待原型验证项
|
||||
- 矿井中的轻度战斗能否提供节奏变化，同时保持探索流畅；通过原型试玩观察判定是否易懂、战斗是否拖慢探索。
|
||||
|
||||
+4
-4
@@ -8,7 +8,7 @@
|
||||
> 玩家在有限的时间与体力下，通过农场、探索与社交三组活动系统产出资源与关系，经物品与经济系统转化为投资，由时间系统推进日终，把一天的成果变成下一天的选择。
|
||||
|
||||
变更记录：
|
||||
- 2026-09-05：战斗与敌人系统定为伴生风险定位，深度刻意受限，不进入最小闭环核心链（依据：概念分析 D-03）。
|
||||
- 2026-09-05：战斗与敌人系统定为伴生风险定位，深度刻意受限，不进入最小闭环核心链（依据：分析文档“矿井战斗要不要做成装备驱动的成长主轴”）。
|
||||
|
||||
## 系统地图
|
||||
|
||||
@@ -66,7 +66,7 @@ P0 段：
|
||||
负责一天制的节奏规则：什么时候推进日期、哪些系统收到跨天 tick、日终结算何时发生。它不负责奖励结算，也不负责作物成长规则——只负责"什么时候"和"谁被通知"。
|
||||
|
||||
### S06 战斗与敌人系统
|
||||
负责战斗内状态、敌人行为与战利品请求。它不直接修改商店价格或 NPC 好感，不负责角色长期成长；战利品只提交请求，由 S07 物品系统入账。定位是矿井探索的风险与节奏变化，不是成长主轴（D-03）。
|
||||
负责战斗内状态、敌人行为与战利品请求。它不直接修改商店价格或 NPC 好感，不负责角色长期成长；战利品只提交请求，由 S07 物品系统入账。定位是矿井探索的风险与节奏变化，不是成长主轴，依据见分析文档中的矿井战斗取舍。
|
||||
|
||||
### S07 物品、背包与制作系统
|
||||
负责物品身份、容器、堆叠与配方队列。它是全项目的公共语言层——任何系统的产出都以 `item_id` 入账；它不负责物品的经济价值平衡，价格只由 S09 维护。
|
||||
@@ -116,9 +116,9 @@ flowchart LR
|
||||
- 系统之间通过稳定 ID 关联（物品 ID、NPC ID、区域 ID、任务 ID、配方 ID）。
|
||||
- 任何系统都不复制另一系统的主数据；任务只引用物品 ID，不重新定义物品价格。
|
||||
|
||||
## 核心循环覆盖检查
|
||||
## 玩法覆盖检查
|
||||
|
||||
| 顶层循环环节 | 认领系统 |
|
||||
| 顶层玩法环节或关键规则 | 负责或协作系统 |
|
||||
|---|---|
|
||||
| 查看天气、日程与目标 | S01、S11、S12、UI |
|
||||
| 选择活动并移动 | S04、S02 |
|
||||
|
||||
+29
-49
@@ -1,63 +1,43 @@
|
||||
# 概念设计：《星露谷物语》
|
||||
|
||||
## 一句话概念
|
||||
《星露谷物语》是一款以经营农场为基础、融合探索、采集、制作、轻度战斗、角色成长与社区叙事的乡村生活模拟 RPG；玩家通过安排每日时间与体力，把荒废农场逐步建设成理想家园，并与周围居民建立关系。
|
||||
## 游戏概念
|
||||
|
||||
## 定调与设计锚点
|
||||
《星露谷物语》是一款以经营农场为基础、融合探索、采集、制作、轻度战斗、角色成长与社区叙事的乡村生活模拟 RPG。玩家安排每日时间与体力，把荒废农场逐步建设成理想家园，并与周围居民建立关系。吸引力在于按自己的节奏塑造生活：今天的选择让明天更从容，社区关系让独居逐渐变成归属。
|
||||
|
||||
### 定调记录
|
||||
- 参照选择：以牧场物语系为主（无压力日常方面学动物森友会）；不参考任何高难动作与生存类游戏。
|
||||
- 调性滑杆：压力感 低 / 战斗比重 低 / 管理深度 中 / 叙事比重 中低 / 节奏 慢。
|
||||
- 调性锚：
|
||||
T1 轻松治愈、自己的节奏（目标体验）；T2 不劝退、无唯一最优解（体验门槛）；T3 战斗轻度、非高难动作（非目标）；T4 以"游戏日"为单位、可反复的单人体验（情境）；T5 时间体力有限但休闲不打卡（跑偏风险）；T6 小团队可维护的规模（关键约束）；T7 日常叙事而非宏大主线，隐藏信息不迫使玩家查攻略（非目标/跑偏风险）。
|
||||
## 体验与玩法
|
||||
|
||||
### 设计锚点
|
||||
- 核心幻想：离开令人疲惫的城市生活，继承一片荒废土地，在自己的节奏中经营、探索、成长，并成为社区的一员。
|
||||
玩家念头："再玩一天就好——今天做完想做的事，明天的一切都会更顺手。"
|
||||
- 目标体验：治愈、自由规划、持续成长、发现秘密，以及"今天的选择会让未来更轻松"的掌控感。
|
||||
- 玩家动机：改善农场与生活条件；发现新区域和资源；完成社区目标；提升技能；与 NPC 建立关系；按照自己的偏好塑造生活方式。
|
||||
- 核心循环：安排一天的时间与体力 → 进行农业、采集、钓鱼、采矿、战斗或社交 → 获得资源、金钱、经验与关系进展 → 投资工具、设施、种子和物品 → 解锁更高效或更丰富的活动。
|
||||
- 跑偏风险：系统过多导致目标分散；时间与体力限制把休闲体验变成每日打卡；隐藏信息迫使玩家依赖外部攻略；经济成长过快使后期失去决策。
|
||||
- 非目标：不做多人竞争、高难度动作战斗、唯一最优效率经营、主线剧情取代日常（详见《不是什么》）。
|
||||
玩家通过改善农场、发现资源与区域、提升技能、完成社区目标和发展人际关系，获得自由规划、持续成长与发现秘密的乐趣。既可以追求效率，也可以把时间用于装饰、社交或探索。
|
||||
|
||||
## 玩家身份与基调
|
||||
- 玩家身份：一名辞职逃离城市、继承祖父荒废农场的归乡人——不是拯救世界的英雄，是重新学会生活的人。季节与节日构成一年的节拍，日落结算构成每天的呼吸。
|
||||
- 情绪基调：温暖治愈，慢而踏实。可以有忙碌与轻度压力（时间、体力），不做生存焦虑（饥饿、债务倒计时）与黑暗题材；孤独感只作为被社区逐渐治愈的起点，不成为基调本身。
|
||||
主要游玩过程是：安排一天的时间与体力 → 进行农业、采集、钓鱼、采矿、战斗或社交 → 获得资源、金钱、经验与关系进展 → 投资工具、设施、种子和物品 → 解锁更高效或更丰富的活动，在下一天重新安排计划。
|
||||
|
||||
## 风格与世界观
|
||||
复古像素风的温暖乡村世界。玩家来到一个正在现代化与传统生活之间摇摆的小镇，农场、商店、社区设施、自然区域和矿井共同构成可步行抵达的生活网络。世界观服务于生活模拟而非复杂设定解释：季节、天气、节日、居民日程和区域变化，让同一张地图随着时间产生生活感。叙事主要通过 NPC 日常对话、关系事件、任务和社区目标逐步展开。
|
||||
其中的重要取舍包括：
|
||||
|
||||
- 时间与体力有限，玩家需要安排今天的优先级，做一件事意味着少做另一些事。
|
||||
- 出售资源能立即获得资金，保留资源制作设备和升级工具则能提高未来效率。
|
||||
- 农场提供可预测的收益；探索可能带来新资源和发现，也会消耗时间、承担风险。
|
||||
- 赚钱占用社交时间；发展关系会减缓眼前收入增长，但能带来配方、剧情和情感回报。
|
||||
- 季节、节日和社区目标提供方向；追赶这些目标会占用自由安排日常的空间，错过部分机会则需要等待或调整计划。
|
||||
|
||||
## 身份、基调与世界观
|
||||
|
||||
玩家是一名辞职离开城市、继承祖父荒废农场的归乡人，在经营与探索中重新建立生活，并成为社区的一员。日落结算构成每天的节拍，季节与节日带来更长周期的变化。
|
||||
|
||||
情绪基调温暖治愈，节奏慢而踏实。时间与体力可以带来忙碌和轻度压力，但不以饥饿、债务倒计时或黑暗题材制造生存焦虑；孤独感是逐渐融入社区的起点。
|
||||
|
||||
视觉采用复古像素风的温暖乡村。农场、商店、社区设施、自然区域和矿井组成可步行抵达的生活网络。季节、天气、节日、居民日程和区域变化让同一张地图产生生活感；叙事通过日常对话、关系事件、任务和社区目标展开。
|
||||
|
||||
参照牧场物语系的农场生活组织方式，以及动物森友会的自定义、装饰和按自己节奏整理日常的体验；农业经营中的时间、体力、季节取舍与社区修复仍是本例的重要内容。参照用于说明体验，不复制具体角色、文本、美术、地图或数值。
|
||||
|
||||
## 目标玩家与情境
|
||||
- 目标玩家：与牧场物语系受众高度重合——喜欢种田与小人际的慢节奏成长玩家；同时吸收动物森友会式"无压力日常整理"的需求（自定义、装饰、按自己的节奏玩）。但它不能变成纯装饰沙盒，因为农场经营的时间、体力与季节取舍，以及社区修复目标必须始终存在。
|
||||
- 适合情境：单人、可反复游玩、每次一个游戏日或几个游戏日；可以高效规划，也可以把时间用于装饰、社交或探索。
|
||||
- 体验门槛：需要理解基础资源转换和时间安排，不应要求预先掌握复杂数值或寻找唯一正确答案。
|
||||
|
||||
## 不是什么
|
||||
| 不是 | 因为 |
|
||||
|---|---|
|
||||
| 硬核生存农场模拟 | 没有饥饿、债务、死亡惩罚；压力止于温和的时间与体力 |
|
||||
| 效率至上的工厂经营 | 不要求唯一最优解，装饰与闲逛是合法玩法而非浪费 |
|
||||
| 以战斗为核心的动作游戏 | 战斗只是采矿与探索的伴生风险，深度刻意受限 |
|
||||
| 剧情驱动的叙事游戏 | 社区叙事是日常的背景与情感回报，不是任务链主线 |
|
||||
| 多人社交平台 | 单人体验为前提，人际关系由 NPC 关系承载 |
|
||||
| 无边界开放世界 | 地图是功能明确的小区域网络，全部可步行抵达 |
|
||||
面向喜欢种田、人际关系与慢节奏成长的玩家，也容纳偏好装饰、收集和自由安排日常的玩家。
|
||||
|
||||
## 核心张力
|
||||
- 时间与体力有限，但想做的事情很多：玩家必须决定今天的优先级。
|
||||
- 立即变现与长期投资：出售资源能快速获得资金，制作设备和升级工具则能提高未来效率。
|
||||
- 稳定经营与未知探索：农场提供可预测收益，矿井、钓鱼和新区域提供风险与发现。
|
||||
- 个人效率与社区关系：把时间用于赚钱会挤压社交，但关系又会带来配方、剧情和新的情感目标。
|
||||
- 自由生活与阶段目标：玩家可以自由安排日常，同时受到季节、节日、任务和社区修复目标的轻度牵引。
|
||||
本例围绕可反复游玩的单人体验，每次可玩一个或几个游戏日。玩家需要理解基础资源转换和时间安排，不应依赖复杂数值计算或寻找唯一正确答案才能推进。
|
||||
|
||||
## 边界与约束
|
||||
- 概念层只定义核心幻想、目标用户、体验基调与排除方向；具体战斗公式、作物成长天数、礼物偏好、掉落率、系统清单和 MVP 内容，留给顶层及以后决定。
|
||||
- 设计规模以单人或小团队可理解、可维护为前提；地图采用多个功能明确的区域，而非无边界开放世界。
|
||||
- 所有系统都必须回流到"安排一天并获得长期改善"的核心循环；独立小游戏或装饰功能不能成为主要范围扩张来源。
|
||||
- 案例声明：本文以《星露谷物语》为案例展示设计的组织方式，不复制其具体角色、文本、美术、地图或数值。
|
||||
|
||||
## 概念定稿
|
||||
《星露谷物语》的核心不是"种田赚钱"，而是：
|
||||
> 在自己的节奏里经营一片土地与一段生活——今天的选择让明天更从容，而社区让独居变成归属。
|
||||
|
||||
交给下一层的约束：时间与体力必须构成温和而非焦虑的取舍；战斗、采矿、社交等支线必须回流农场生活循环；成长权重要允许玩家自定义（效率型与休闲型玩家都成立）。
|
||||
（调性已在第 2 节定死；顶层及以下一切开放问题先回定调记录的 T1~T7 级联。）
|
||||
- 战斗服务于采矿与探索，不扩展为高难度动作游戏；社区叙事提供日常背景与情感回报，不用宏大主线取代农场生活。
|
||||
- 时间和体力形成温和的取舍，避免把休闲变成每日打卡。装饰、闲逛和社交都有价值，不以唯一最优效率为目标。
|
||||
- 本例按单人或小团队规模控制内容，地图采用功能明确的小区域网络，不扩展为无边界开放世界或多人社交平台。
|
||||
- 各系统服务于日常生活及其长期改善。独立小游戏或装饰内容的扩张不能挤占核心体验；同时避免经济成长过快使后期失去选择，或隐藏信息迫使玩家依赖攻略。
|
||||
- 后续设计应允许效率型和休闲型玩家按自己的偏好成长；具体系统范围、版本内容、战斗公式、作物成长天数和掉落率等再逐步展开。
|
||||
|
||||
+12
-9
@@ -1,16 +1,17 @@
|
||||
# 美术圣经：《星露谷物语》（TDD 金样 · 美术圣经）
|
||||
|
||||
> 状态：reviewed | 定调锚：概念层@v1 第 2 节（定调记录：牧场物语系参照、压力低/节奏慢/治愈） | style_id：`stardew_warm_rural_pixel`
|
||||
> 状态：reviewed | 设计依据：概念层@v1「身份、基调与世界观」「边界与约束」（温暖乡村、慢节奏、治愈、轻度压力） | style_id：`stardew_warm_rural_pixel`
|
||||
> 本例仍有换装范围、锚点图和字体等待解决的问题；相关规格为草案，不能将局部资产验收当作整体规格完备。
|
||||
> 实证规格来源：星露谷 1.6.15 解包知识库 v3（资产计数时点 2026-09-11，快照 stardew-1.6.15-7f1e5b8e）。写新项目时按本项目定调重译，数字仅作规模参照。
|
||||
|
||||
## 视觉风格总览
|
||||
|
||||
从定调记录翻译的视觉气质：**"被四季照亮的温暖小农场"**——手绘感像素、俯视 45° 视角，春夏绿意、秋日暖橙、冬季留白，颜色随季节整体切换而不是换贴图；物件轮廓圆润、无锐利科技感。玩家一看画面就该感到：这里节奏很慢，干活是安心的。参考图位 4 张（量产流程第 3 步产出锚点图）。
|
||||
承接概念层温暖乡村与季节变化的视觉气质：**"被四季照亮的温暖小农场"**——手绘感像素、俯视 45° 视角，春夏绿意、秋日暖橙、冬季留白，颜色随季节整体切换而不是换贴图；物件轮廓圆润、无锐利科技感。玩家一看画面就该感到：这里节奏很慢，干活是安心的。参考图位 4 张（量产流程第 3 步产出锚点图）。
|
||||
|
||||
## 视觉锚
|
||||
|
||||
- 关键词：温暖、手绘像素、田园、四季分明、生活感。
|
||||
- 禁用关键词：阴暗压抑、血腥恐怖、高饱和霓虹、写实渲染、锐利科技风（承概念层 T3"战斗轻度"、T7"日常叙事"）。
|
||||
- 禁用关键词：阴暗压抑、血腥恐怖、高饱和霓虹、写实渲染、锐利科技风（依据概念层的温暖治愈基调、乡村像素风和不制造生存焦虑的边界）。
|
||||
- 色板：主色 暖土绿系（草地/耕地基底）60% ／ 辅色 暖木棕+瓦顶红 30% ／ 点缀 季节信号色（春樱粉/夏浓绿/秋橙/冬蓝白）10%。昼夜·天气·季节表现：季节=色调与植被整体切换；天气=雨天全屏冷色叠加（原作 OrangeRed×0.45 实证）；昼夜=时刻线性插值环境光。
|
||||
- 形状语言：圆润矩形轮廓，物件以 16px 网格对齐；无 1px 高光乱线。
|
||||
- 比例与轮廓：物件 16px 一档；NPC 16×32（渲染放大 4 倍）；玩家可完全自定义外观。
|
||||
@@ -71,12 +72,14 @@
|
||||
|
||||
## 量产流程与验证
|
||||
|
||||
1. 概念候选 4 张（农场一角/角色/物品图标/UI 面板各 1 方向稿）→ 2. 人选方向（用户确认）→ 3. 锚点图 4 张 → 4. 锁圣经 → 5. 写契约（本文件已锁）→ 6. 小批 8 张（icon_item 子集：防风草种子/防风草/木材/石头/铜矿/锄头/水壶/出货箱）→ 7. 技术检查（尺寸/透明/命名/atlas 解析）→ 8. 接入程序（v0.1 里程碑）→ 9. 运行时截图验收（桌面/移动双视口下 16×16 图标与作物相位可辨、四季色调正确）→ 10. 扩产（8→120→全量）。
|
||||
1. 概念候选 4 张（农场一角/角色/物品图标/UI 面板各 1 方向稿）→ 2. 人选方向（用户确认）→ 3. 锚点图 4 张 → 4. 锁圣经 → 5. 写契约（本例的相关缺口仍待补齐）→ 6. 小批 8 张（icon_item 子集：防风草种子/防风草/木材/石头/铜矿/锄头/水壶/出货箱）→ 7. 技术检查（尺寸/透明/命名/atlas 解析）→ 8. 接入程序（v0.1 里程碑）→ 9. 运行时截图验收（桌面/移动双视口下 16×16 图标与作物相位可辨、四季色调正确）→ 10. 扩产（8→120→全量）。
|
||||
|
||||
## 开放问题回执
|
||||
## 待解决问题
|
||||
|
||||
| # | 问题 | 去向 |
|
||||
| 问题 | 影响 | 下一步与需更新的正文 |
|
||||
|---|---|---|
|
||||
| 1 | 换装系统首期是否做全 19 层（或缩到 5 层） | → 台账代决（建议首期 5 层：基础体/裤/衣/发型/饰件；台账 D-17） |
|
||||
| 2 | 锚点图方向需用户确认 | → 施工期提案卡 |
|
||||
| 3 | 位图字体 vs 矢量像素风字体 | → 小批阶段随 UI 套件定 |
|
||||
| 换装首期是否采用 5 层 | 决定角色图集数量与程序分层接口 | 确认范围后，在角色规格及素材契约写清采用的层次、顺序与命名；当前建议为基础体、裤、衣、发型、饰件 |
|
||||
| 锚点图方向待用户确认 | 影响后续素材的视觉验收依据 | 用户确认后将锚点及具体风格要求写入视觉规格，更新受影响的素材契约 |
|
||||
| 位图字体还是矢量像素风字体 | 影响文字渲染与 UI 资产格式，正文的位图方案尚为暂定 | 小批 UI 验证后定案，将字体资源、格式与使用方式补入 UI 规格并同步程序分册 |
|
||||
|
||||
问题解决后更新对应正文并移出待办，施工方无需从外部台账查找最终规格。
|
||||
|
||||
+11
-4
@@ -1,6 +1,6 @@
|
||||
# 数据与配表：《星露谷物语》（TDD 金样 · 数据与配表）
|
||||
|
||||
> 状态：accepted（结构定稿＋首期全量填充验算通过） | 基于：各系统文档交接节汇总 ＋ 归 TDD 素材两份提取件（S06 数值结构／架构字段字典） | 验收：check@C-2026-09-11-v1 结论 无 blocker
|
||||
> 状态：待补齐（背包容量与公共索引定义仍有缺口） | 基于：各系统文档交接节汇总 ＋ 归 TDD 素材两份提取件（S06 数值结构／架构字段字典） | 已有数据验收：check@C-2026-09-11-v1；不代表当前范围规格已完备
|
||||
> 实证计数来源：星露谷 1.6.15 解包知识库 v3（13 张数据表，提取脚本断言通过；快照 stardew-1.6.15-7f1e5b8e）。写新项目时按本项目系统交接节重建，计数仅作规模参照。
|
||||
|
||||
## 数据表总清单
|
||||
@@ -66,9 +66,9 @@
|
||||
|
||||
## 数值填充与验算
|
||||
|
||||
- 填充代决台账：
|
||||
- 当前采用的数值与验证关注点：
|
||||
|
||||
| 表 | 字段 | 默认值 | 依据 | 推翻条件 |
|
||||
| 表 | 字段 | 当前值 | 依据 | 验证关注点（按需） |
|
||||
|---|---|---|---|---|
|
||||
| 等级经验表 | skill_cumulative_xp | 100/380/770/1300/2150/3300/4800/6900/10000/15000 | 代码常量（Farmer.cs 实证） | 原型期曲线过陡/过缓 |
|
||||
| 作物表 | 防风草 price/days/xp | 35 金/4 日/8 xp | 原作作物表实证（crop 472：phases 1-1-1-1，xp_per_harvest 8） | 前 5 日验算不闭合 |
|
||||
@@ -95,4 +95,11 @@
|
||||
- 两查复核：业务规则（季节窗口相容、目标有验证系统、奖励一次、配方输入可达——防风草种子→收获→出售链全通）；重复归属（价格只由经济表维护、品质只由收获规则维护）。
|
||||
- 三级处置：blocker 禁止扩内容；warning 记负责人与计划；note 不阻断。
|
||||
- 工具化实证口径（参照知识库做法）：提取脚本逐表断言（行数/字段/枚举）；对账器做表间交叉对账（代表资产级 50 键全对账）；反例套件 5/5 拒绝。
|
||||
- 最近验收结论：check@C-2026-09-11-v1——五查全过、两查复核通过、blocker 清零（结构、规则或字段语义一变，受影响链路全部重验）。
|
||||
- 最近验收结论：check@C-2026-09-11-v1——已有数据的五查与两查复核通过；背包容量与公共索引定义仍需补齐，不能据此认定当前范围的数据规格完整。结构、规则或字段语义一变，受影响链路全部重验。
|
||||
|
||||
## 待解决问题
|
||||
|
||||
- 背包容量：与技术分册确认格子或重量规则后，补齐容器字段、容量约束及存档数据定义。
|
||||
- 公共索引：补齐 condition/text/station/behavior 的索引定义与引用说明，再检查加载和引用完整性。
|
||||
|
||||
完成后将采用的规则写入本文对应数据规格并更新验收结论，移出待办。
|
||||
|
||||
+25
-25
@@ -1,35 +1,35 @@
|
||||
# TDD 总册：《星露谷物语》
|
||||
|
||||
> 状态：active（v0.1 里程碑期） | 基于 GDD：架构层@v3 + 各系统交接节
|
||||
> 状态：待补齐（v0.1 仍有关键规格缺口） | 基于 GDD：架构层@v3 + 各系统交接节
|
||||
|
||||
## 自足性检查（2026-09-06 生产态复评）
|
||||
## 自足性检查（未完备示例）
|
||||
|
||||
| # | 施工方的问题 | 答案在哪 | 状态 |
|
||||
|---|---|---|---|
|
||||
| 1 | 七个 P0 系统怎么行为？ | 01 收编章（P0 七系统规则全文已收编@v1；S06 P1 要点已收） | **过** |
|
||||
| 2 | 表里有多少行内容、文本全填了吗？ | 03 全量填充（作物8/敌人3/NPC12/文本40/物品46/配方14 全填，第八查全绿） | **过** |
|
||||
| 3 | 每个界面长什么样、怎么走？ | 01 UI 交互规格（HUD/背包/商店/对话/结算五界面全） | **过** |
|
||||
| 4 | 每份素材什么规格、谁验收过？ | 02 资产状态表 42 行全登记（完成度 12/42，缺口=量产排期非规格缺口） | **过（规格）**／量产进行中 |
|
||||
| 1 | 七个 P0 系统怎么行为？ | 01 收编章及待解决问题 | **缺口**：背包容量与体力规则仍需确定 |
|
||||
| 2 | 表里有多少行内容、文本全填了吗？ | 03 数值填充、验收及待解决问题 | **缺口**：已有数据检查不能代替容量与公共索引定义 |
|
||||
| 3 | 每个界面长什么样、怎么走？ | 01 UI 交互规格 | **缺口**：背包方案确定后需更新对应交互 |
|
||||
| 4 | 每份素材什么规格、谁验收过？ | 02 素材规格、资产状态表及待解决问题 | **缺口**：换装范围、锚点图和字体仍有待确认内容 |
|
||||
| 5 | 代码怎么组织、跑在哪？ | 01 代码组织+能力边界（三态全落位） | **过** |
|
||||
| 6 | 怎么算做完？ | 01 里程碑三判据+三件验收 | **过** |
|
||||
|
||||
**结论：六问全过——TDD 规格已自足，施工方 可只凭本 TDD 开工。**
|
||||
剩余非规格缺口（不阻塞开工，按里程碑推进）：①P1 四系统（S05/S10/S11/S12）施工前补文档并收编；②资产表 30 行量产（按十步流程排期）；③B 级两项（背包容量、生命体力共享）在 v0.1 存档实现前收口。
|
||||
**结论：当前范围的 TDD 尚未完备。** 只有相关规则、数据与素材规格补齐到 TDD 正文后，才能认定施工方可只凭 TDD 完成该范围的实现；登记待办或已有检查通过均不能替代这一步。
|
||||
后续版本新增系统时仍需补齐相应规则并收编。已明确规格的资产可按计划制作，其生产进度与上述规格缺口分别记录。
|
||||
|
||||
## 三件状态
|
||||
|
||||
| 件 | 状态 | 版本 | 读者 | 一句话结论 |
|
||||
|---|---|---|---|---|
|
||||
| 01 技术实现 | reviewed | v0.2 | 程序 | P0 铁底七件全部落位（native 4/emulated 3），无 gated；v0.1 判据=一个游戏日全流程 |
|
||||
| 02 美术圣经 | locked（锚点已锁） | v1 | 美术 | 视觉锚七件套从 T1~T7 翻译完毕；资产表 ~40 行全登记，农夫已接入、芜菁已验收 |
|
||||
| 03 数据与配表 | accepted | ck-001 | 数值+程序 | 七查过、无 blocker、2 warning（公共索引表未建、背包容量未定案）；前五日验算通过 |
|
||||
| 01 技术实现 | 待补齐 | v0.2 | 程序 | 补齐背包与体力规则；v0.1 判据仍为一个游戏日全流程 |
|
||||
| 02 美术圣经 | 待补齐 | v1 | 美术 | 确认换装范围、锚点图与字体；已有资产的验收记录保留 |
|
||||
| 03 数据与配表 | 待补齐 | ck-001 | 数值+程序 | 已有数据检查通过，容量与公共索引定义仍需补齐后重验 |
|
||||
|
||||
## 跨件契约速查
|
||||
|
||||
| 缝 | 契约 | 权威在 |
|
||||
|---|---|---|
|
||||
| 素材绑定 | 作物绑 `crop_{id}`、工具绑 `item_`、敌人绑 `enemy_{id}`、NPC 绑 `npc_{id}`（ID 全部查 03 字段字典指向的表） | 03 字段字典 |
|
||||
| 视觉翻译链 | `cozy-pixel-countryside` 溯源概念层 T1/T4/T7；四季色板=日单位与季节推动的视觉形态 | 概念层@v3 第 2 节 |
|
||||
| 视觉设计依据 | `stardew_warm_rural_pixel` 承接概念层的温暖治愈、乡村生活与季节变化；四季色板和完整视觉规格见美术圣经 | 02 视觉风格与视觉锚 |
|
||||
| 加载顺序 | 主数据（物品/敌人）→ 关系（掉落/配方）→ 条件（condition 表）→ 文本（text 表最后） | 03 契约七条① |
|
||||
| 帧表格式 | `farmer_{anim}_{dir}_{frame}` JSON 帧表：圣经契约列的格式=程序侧帧动画节直接解析的格式 | 01 §能力边界 |
|
||||
| 交互热区 | 触控热区 ≥44px；圣经 UI 节与 01 输入表同源（热区按钮规格一字不差） | 01 输入表 |
|
||||
@@ -37,23 +37,23 @@
|
||||
| 昼夜色调 | `tint_{phase}` 四档程序色值表，豁免绑定、拥有者=美术圣经资产表 | 02 资产状态表 |
|
||||
| 拥有者总则 | 数值事实归 03（价格只在经济表）；生产状态归 02（素材验收记录）；技术事实归 01（缩放档位） | 架构层@v3 |
|
||||
|
||||
## 开放问题回执汇总
|
||||
## 重要缺口汇总
|
||||
|
||||
| # | 来源件 | 问题 | 去向 | 状态 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | **01** | 背包格子还是重量容量（阻断：影响存档与 UI） | 概念层决策卡 | **待用户（B 级置顶）** |
|
||||
| 2 | 02 | NPC 对话立绘 +12 张（影响 UI 结构与工时） | 决策卡 | 待用户（B 级） |
|
||||
| 3 | 01 | 矿井逐层生成是否本期 | 台账代决（建议 P2） | 待登记 |
|
||||
| 4 | 02 | 节日专属装饰 P1/P2 | 台账代决（建议 P2） | 待登记 |
|
||||
| 5 | 02 | 矿井色板 1 套 vs 3 套 | 台账代决（建议 1 套+亮度递减） | 待登记 |
|
||||
| 6 | 03 | condition/text/station/behavior 公共索引表 | 03 warning（记负责人） | 进行中 |
|
||||
| 相关分册 | 影响当前施工的缺口 | 详细位置 |
|
||||
|---|---|---|
|
||||
| 01、03 | 背包容量与体力规则影响行为、存档及界面 | 01“待解决问题”；确定后同步两份分册正文 |
|
||||
| 01 | 矿井生成是否纳入本期影响地图实现 | 01“待解决问题”及“场景与镜头” |
|
||||
| 02 | 换装范围、锚点图与字体影响素材和渲染规格 | 02“待解决问题” |
|
||||
| 03 | 公共索引定义影响数据加载与引用 | 03“待解决问题” |
|
||||
|
||||
详细分析与下一步在对应分册维护；问题解决后更新分册正文，再移出本汇总，无需向全局台账重复登记。
|
||||
|
||||
## 验收总状态
|
||||
|
||||
| 件 | 最近验收 | blocker | 结论 |
|
||||
|---|---|---|---|
|
||||
| 01 | 构建通过+静态检查全绿；双视口验证待 v0.1 联调 | 0 | 结构合格 |
|
||||
| 02 | ck-a01~a03：农夫接入✓、芜菁两维过（1 warning）、春瓦技术过视觉待锚点 | 0 | 小批已过闸，允许扩产 |
|
||||
| 03 | ck-001 七查全跑 | 0（2 warning） | 允许内容扩充 |
|
||||
| 01 | 已有构建和静态检查通过；双视口验证待联调 | 背包与体力等规格缺口 | 补齐正文后复核当前范围的完整性 |
|
||||
| 02 | ck-a01~a03 保留已有资产的接入与验收记录 | 换装、锚点图与字体规格未定 | 相关规格确认后再制作和验收受影响素材 |
|
||||
| 03 | ck-001 已有数据检查通过 | 容量与公共索引定义缺口 | 补齐后重验受影响的数据与接口 |
|
||||
|
||||
当前无任何 blocker：填数（03）、扩产（02）、v0.1 联调（01）三线并行合法。B 级第 1 条（背包容量）在 v0.1 存档实现前必须收口，否则冻结存档模块。
|
||||
以上缺口解决且施工所需信息完整后，才能将当前范围标为“只凭 TDD 可实施”。
|
||||
|
||||
+10
-7
@@ -1,6 +1,7 @@
|
||||
# 技术实现：《星露谷物语》（TDD 金样 · 技术实现）
|
||||
|
||||
> 状态：reviewed | 基于 GDD：架构层@v3 + P0 系统文档@v1（收编） | 数据侧契约：data/contracts@v2
|
||||
> 本例仍有背包容量和体力规则等关键缺口，尚不能作为当前范围的完整施工依据；相关暂定内容需解决后更新正文。
|
||||
> **目标运行时：HTML**（由 GDD 平台事实锁定；本项目按浏览器平台事实执行）
|
||||
> 平台事实：双视口（桌面/移动）· 键鼠/触屏双输入 · 本地 HTTP 预览
|
||||
> 实证数字来源：星露谷 1.6.15 反编译知识库 v3（快照 stardew-1.6.15-7f1e5b8e，2026-09-11）；写新项目时替换为本项目数值。
|
||||
@@ -124,9 +125,9 @@
|
||||
|
||||
| 项 | 规定 | 依据 |
|
||||
|---|---|---|
|
||||
| 瓦片地图结构 | 16px 网格；农场 80×65、小镇 50×40、矿井按层生成 | 台账 D-05（区域分场景，非连续地图） |
|
||||
| 瓦片地图结构 | 16px 网格；农场 80×65、小镇 50×40、矿井按层生成（是否纳入本期尚待确认） | 各区域独立场景，通过连接点切换，不构建连续地图 |
|
||||
| 镜头 | 跟随玩家+边界钳制；无缩放（固定整数倍） | GDD 顶层（无镜头玩法） |
|
||||
| 场景切换 | 农场↔小镇↔矿井走连接点淡入淡出 ≤1s | 概念 D-05 定案"分区域切换" |
|
||||
| 场景切换 | 农场↔小镇↔矿井走连接点淡入淡出 ≤1s | 分区域加载，限制单次加载范围 |
|
||||
| 关卡数据 | `data/maps/*.json`（自定义 JSON：层/网格/对象点） | 契约 v2 |
|
||||
|
||||
## 输入与操作
|
||||
@@ -163,10 +164,12 @@
|
||||
| v0.2 | 矿井+战斗（S06）+成长（S08） | 矿井进出一次、遭遇一场、掉落入账、经验到 1 级（累计 100xp） |
|
||||
| v0.3 | NPC+任务+商店（S09/S10/S11） | 修路任务全链可交付并解锁洒水器配方 |
|
||||
|
||||
## 开放问题回执
|
||||
## 待解决问题
|
||||
|
||||
| # | 问题 | 去向 |
|
||||
| 问题 | 影响 | 下一步与需更新的正文 |
|
||||
|---|---|---|
|
||||
| 1 | 背包格子还是重量容量（影响存档与 UI 结构） | → 概念层决策卡（B 级阻断，台账 D-15） |
|
||||
| 2 | 矿井逐层生成是否本期做 | → 台账代决（建议 P2，GDD 已标"不做无限地牢"；台账 D-16） |
|
||||
| 3 | 体力是否与战斗共享单池 | → 台账 D-14（B 级待拍，暂按共享实现） |
|
||||
| 背包采用格子还是重量容量 | 决定物品容器、存档和 UI 结构 | 与用户确认后补齐 S07 行为规格、UI 交互规格及数据分册中的容量字段；目前的格子制是暂定方案 |
|
||||
| 矿井逐层生成是否纳入本期 | 影响地图结构与关卡数据，当前方案倾向延期 | 确认本期范围与地图实现方式，再更新场景与镜头、关卡数据及版本里程碑 |
|
||||
| 体力是否与战斗共享单池 | 影响 S02、战斗成本及恢复规则 | 与用户确认后补齐相关系统行为规格和数据定义；目前共享单池是暂定方案 |
|
||||
|
||||
问题解决后将实际采用的规则写入对应正文，检查关联分册并移出待办；这些记录不能代替施工规格。
|
||||
|
||||
+88
-158
@@ -1,182 +1,112 @@
|
||||
# 顶层设计：《星露谷物语》
|
||||
|
||||
## 顶层定位与规模锚点
|
||||
顶层不是做长线农场生产线，也不是做以探索战斗为主的活动清单，而是让玩家每天都在想：
|
||||
> "今天做什么？——下雨天不用浇水，正好下矿井；回来的路上把罗宾的生日礼物送了。"
|
||||
## 玩法目标
|
||||
|
||||
| 项 | 定义 |
|
||||
|---|---|
|
||||
| 循环单位 | 一个游戏日（约 10~20 分钟） |
|
||||
| 段落构成 | 日初规划 → 白天执行（农务/探索/社交）→ 日落结算 |
|
||||
| 操作复杂度 | 低——单人键鼠交互，无动作门槛 |
|
||||
| 经营复杂度 | 中——时间、体力、资金三约束下的日程规划；不做生产线布局优化 |
|
||||
| 长期主轴 | 第一：农场与生活方式成型；第二：社区修复与技能成长；角色数值只做辅助 |
|
||||
以一个游戏日组织慢节奏的农场生活。玩家根据天气、农场状态、居民日程和自己的目标安排活动，再将当天的成果投入后续生活。时间与体力提供温和的规划压力，农场、探索与社交共同支持不同的生活方式。
|
||||
|
||||
## 设计目标
|
||||
让玩家在一个没有唯一正确答案的乡村生活循环中，同时获得三种回报：
|
||||
- 轻松生活：可以按自己的兴趣安排一天，通过农场、装饰、收集和社交获得稳定的正反馈。
|
||||
- 规划掌控：时间、体力、季节和资金构成可理解的取舍，提前准备会让未来更高效。
|
||||
- 探索成长：探索区域、战斗和资源发现提供变化与风险，并将成果转化为农场与角色的长期改善。
|
||||
主要回报包括自由安排日常的放松感、通过规划改善生活的掌控感，以及探索新资源、区域和人际关系的发现感。农场提供稳定产出，探索带来原料和新内容，社交带来配方、剧情与情感回报；这些关系帮助玩家形成自己的计划。
|
||||
|
||||
三者互相供给：农场提供稳定资源与恢复空间，探索提供稀有资源和发现，社交与社区目标提供方向和情感回报。
|
||||
农场与生活方式成型是长期主轴，社区修复与技能成长提供阶段目标。战斗是探索中的伴生风险，不扩展为高难度动作或装备构筑主轴；制作服务于日常投资，不扩展为生产线布局优化。
|
||||
|
||||
## 核心推动力
|
||||
玩家每天拥有有限的时间与体力，但可以在一天结束后保留成果，并把收益投入到工具、设施、种子、装备和关系中。短期的"今天做什么"决策，持续转化为长期的"我的生活变得怎样"。
|
||||
## 游玩过程与节奏
|
||||
|
||||
主要推动力按层次排列：
|
||||
1. **即时推动**：完成一次采集、收获、战斗或对话，立即得到物品、金钱、经验、信息或关系进展。
|
||||
2. **日程推动**：在日落或体力耗尽前完成今天最重要的目标。
|
||||
3. **季节推动**：抓住作物、鱼类、节日和任务的时间窗口，准备下一阶段。
|
||||
4. **长期推动**：改善农场、解锁区域和设施、完成社区目标、掌握技能，并建立属于自己的生活方式。
|
||||
一个常规游戏日目标约为 10～20 分钟，具体节奏需通过试玩调整。单人键鼠操作以日常行动为主，不以操作精度制造门槛。
|
||||
|
||||
## 大循环
|
||||
**规划一天 → 执行活动 → 获得资源与关系进展 → 出售、加工或投资 → 解锁更高效率与新内容 → 进入下一天。**
|
||||
|
||||
在更长周期中：**完成一个季节目标 → 调整生产与探索计划 → 迎接新季节 → 修复社区或解锁区域 → 扩大玩家可选择的生活方式。**
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[规划一天] --> B[执行农务/探索/社交]
|
||||
B --> C[获得资源·金钱·经验·关系]
|
||||
C --> D[出售/加工/投资]
|
||||
D --> E[解锁效率与新内容]
|
||||
E --> F[进入下一天]
|
||||
F --> A
|
||||
```
|
||||
|
||||
## 小循环
|
||||
|
||||
### 农务循环
|
||||
清理土地、播种或饲养 → 每日维护 → 等待成长 → 收获 → 出售或加工 → 将收益投入下一轮生产。
|
||||
|
||||
### 探索循环
|
||||
选择目的地与携带物资 → 在有限体力和时间内采集、钓鱼或战斗 → 判断继续深入还是返程 → 带回资源 → 用于升级、制作或出售。
|
||||
|
||||
### 社交循环
|
||||
寻找 NPC → 观察其日程与需求 → 对话、赠礼或完成委托 → 提升关系 → 解锁新对话、事件、配方或功能。
|
||||
|
||||
### 成长循环
|
||||
重复使用某类能力 → 获得经验并提升技能 → 获得效率、工具或职业选择 → 以更低成本完成同类活动，并接触更高阶内容。
|
||||
|
||||
## 资源流与输入输出
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
F[农场生产] -->|作物·畜产品| S[出售与加工]
|
||||
E[采集·钓鱼·采矿·战斗] -->|原料·鱼类·矿物·战利品| S
|
||||
S -->|金钱| I[工具·设施·种子·装备]
|
||||
I -->|效率提升| F
|
||||
E -->|经验| K[技能成长]
|
||||
K -->|效率·配方| F
|
||||
G[社交] -->|关系进展| R[新对话·事件·配方]
|
||||
R --> G
|
||||
```
|
||||
|
||||
- 主要输入：时间与体力；金钱、种子、原材料和消耗品；工具、装备和技能；NPC 关系、任务状态和社区进度；天气、季节、地图位置和活动开放状态。
|
||||
- 主要输出：农产品、采集物、鱼类、矿物、战利品和加工品；金钱、技能经验、工具/设施升级；地图区域、配方、任务、事件和 NPC 关系解锁；农场外观、生产能力和社区状态变化。
|
||||
- 反馈四层：
|
||||
- 立即反馈：动画、音效、图标、数字、资源变更和状态变化。
|
||||
- 短期反馈：背包、金钱、任务和技能面板更新。
|
||||
- 中期反馈：设施完成、工具升级、关系事件和新区域开放。
|
||||
- 长期反馈：农场自动化、社区恢复、生活方式成型和终局目标完成。
|
||||
|
||||
## 最小体验单位
|
||||
一个约 10~20 分钟的"游戏日"：查看状态 → 选一个主目标与一两个顺路次目标 → 执行 → 在时间或体力约束下结束 → 结算并获得当日反馈，决定明天是否继续当前计划或转换方向。
|
||||
|
||||
单个行动必须至少提供一种清晰反馈：资源增加、进度推进、能力提升、关系变化、地图信息或视觉状态变化。
|
||||
|
||||
## 核心活动流程
|
||||
|
||||
| 阶段 | 玩家行为 | 设计目的 |
|
||||
| 环节 | 玩家行为 | 对体验的作用 |
|
||||
|---|---|---|
|
||||
| 日初 | 查看天气、季节、农场状态、商店或任务提示 | 给当天决策提供完整状态 |
|
||||
| 目标选择 | 从生产、赚钱、探索、成长、社交和社区目标中确定优先级 | 制造当日取舍（张力兑现处） |
|
||||
| 准备与出发 | 整理背包，携带工具、消耗品和必要装备 | 投入成本前置，增强方向感 |
|
||||
| 执行活动 | 完成一组有空间关系或时间关系的行动 | 核心玩法发生地 |
|
||||
| 中途调整 | 根据体力、时间、掉落和突发事件，决定继续、转向或返程 | 张力的实时兑现 |
|
||||
| 结算与投资 | 出售或加工资源，购买材料，安排设施和下一轮生产 | 回流与长期化 |
|
||||
| 日终反馈 | 记录技能、关系、任务、生产和解锁变化，进入下一天 | 闭合并钩住明天 |
|
||||
| 日初与计划 | 查看天气、季节、农场状态、商店或任务信息，决定今天的优先级 | 让玩家根据当前条件选择目标 |
|
||||
| 准备与出发 | 整理背包，携带工具、消耗品和必要装备 | 为选定活动投入资源 |
|
||||
| 活动与调整 | 完成农务、采集、钓鱼、采矿、战斗或社交，根据时间、体力和发现调整计划 | 让选择产生可感知的结果 |
|
||||
| 结算与投资 | 出售或加工资源，购买材料，安排设施和下一轮生产 | 将当天成果转为后续机会 |
|
||||
| 日终 | 展示技能、关系、任务、生产与解锁变化，保存并进入下一天 | 保留进展，并为次日计划提供信息 |
|
||||
|
||||
## 取舍表
|
||||
不同活动的过程与时间跨度有所区别：
|
||||
|
||||
| 决策 | 立即收益 | 延迟收益 | 主要代价 |
|
||||
|---|---|---|---|
|
||||
| 出售原料还是加工（张力2） | 快速获得资金 | 更高价值或新用途 | 占用设备与等待时间 |
|
||||
| 留在农场还是外出探索（张力3） | 稳定推进生产 | 稀有资源与发现 | 错过维护或消耗补给 |
|
||||
| 深入探索还是及时返程（张力3） | 更多资源与经验 | 更高风险和返程压力 | 可能损失当日效率或物资 |
|
||||
| 购买工具升级还是扩大生产（张力2） | 提高行动效率 | 增加产量与收入 | 当前资金减少 |
|
||||
| 赚钱还是社交（张力4） | 直接经济进展 | 关系、剧情和配方回报 | 消耗可用于生产的时间 |
|
||||
| 追求效率还是装饰与兴趣（张力5） | 更快成长 | 个性化与放松体验 | 放弃部分短期收益 |
|
||||
- 农务：清理土地、播种或饲养，经过维护与成长后收获，再出售、加工或投入下一轮生产。
|
||||
- 探索：选择目的地和携带物资，在时间与体力限制下活动，权衡继续深入或返程，再把成果用于升级、制作或出售。
|
||||
- 社交：寻找居民，观察日程与需求，通过对话、赠礼或委托发展关系，解锁对话、事件、配方或功能。
|
||||
- 成长：使用能力积累经验，获得技能、效率、工具或职业选择，从而接触新的活动内容。
|
||||
|
||||
（张力1"时间与体力有限"由目标选择阶段整体承载。）设计原则：这些选择应产生不同的合理生活方式，而不是把玩家逼向唯一最优路线。
|
||||
天气、营业时间和居民日程让日常计划发生变化。季初准备、季中经营和季末收获形成更长节奏；季节更替改变作物、资源、节日和目标。长期则从手工劳动推进到工具升级、自动化设施、新区域和更复杂的人际目标。
|
||||
|
||||
## 节奏结构
|
||||
- **日内节奏**：信息确认 → 连续行动 → 资源或发现反馈 → 体力/时间压力 → 日终结算。
|
||||
- **周内节奏**：工作日进行生产与探索，商店营业、NPC 日程和周期事件制造计划变化。
|
||||
- **季节节奏**：季初准备，季中稳定经营，季末收获与总结；季节变化带来资源、作物、天气和目标变化。
|
||||
- **长期节奏**：从手工劳动起步，逐步获得工具升级、自动化设施、新区域和更复杂的关系目标。
|
||||
农场与小镇提供熟悉、安定的活动，探索与事件提供变化。节奏应容纳效率型和休闲型玩家，不把每天的任务完成率作为唯一价值。
|
||||
|
||||
整体情绪应在"安定的重复"和"偶尔的发现"之间摆动：农场与城镇提供恢复，探索与事件提供变化。
|
||||
## 资源与进展
|
||||
|
||||
## 失败与回收
|
||||
失败主要表现为"少拿与顺延"，不毁掉既有积累。
|
||||
- 时间与体力限制当天可以完成的行动；天气、季节、位置和活动开放状态影响行动机会。
|
||||
- 金钱、种子、原料与消耗品投入生产、制作或探索，转化为农产品、加工品、发现和后续投资能力。背包与设备容量影响携带、加工和安排。
|
||||
- 工具、装备、设施与技能改变行动效率和可选活动。经验积累用于成长，不要求玩家把经验作为货币消耗。
|
||||
- NPC 关系、任务状态和社区进度记录持续进展，带来对话、事件、配方与区域解锁。
|
||||
- 农场外观、生产能力和社区状态展示长期生活变化。
|
||||
|
||||
| 情况 | 结果 |
|
||||
|---|---|
|
||||
| 当日计划未完成 | 成果顺延到明天，无惩罚；次日优先级重排 |
|
||||
| 深夜未归昏倒 | 当日行动终止，次日体力受限，轻度损失 |
|
||||
| 矿井中倒下 | 损失部分金钱或物品，保留大部分积累 |
|
||||
| 季节更替未收获 | 该季作物枯萎——日历压力的主要形式 |
|
||||
| 错过节日或窗口期 | 顺延至下个周期，制造轻度遗憾而非惩罚 |
|
||||
行动结果通过相应的动画、音效、资源或状态变化表现；背包与面板显示当前结果，设施完成、关系事件和区域开放表现更长周期的进展。重要变化应能被玩家理解，不依赖外部攻略才能形成下一步计划。
|
||||
|
||||
## 系统范围
|
||||
## 选择与后果
|
||||
|
||||
| 系统 | 顶层目的 | 边界（本层不做什么） |
|
||||
时间与体力有限，选择一项活动会挤占其他活动的空间。本例希望不同选择支持不同的生活方式，不把玩家逼向唯一效率路线。
|
||||
|
||||
| 选择 | 方案 A 的收益与代价 | 方案 B 的收益与代价 |
|
||||
|---|---|---|
|
||||
| 农场经营 | 承载规划与回报的核心场 | 不做布局优化向的生产线 |
|
||||
| 时间与体力 | 全局硬约束、日程的标尺 | 不做饥饿等生存需求式衰减 |
|
||||
| 探索与采集（矿井/钓鱼/采集） | 提供风险与发现 | 不做程序生成的无限地牢 |
|
||||
| 轻度战斗 | 矿井探索的风险与节奏变化 | 不做装备驱动的成长主轴 |
|
||||
| 物品与制作 | 资源的转化与长期投资 | 不做复杂配方树管理 |
|
||||
| 技能成长 | 使用即成长的回报层 | 不做技能树构筑 |
|
||||
| NPC 关系与任务 | 社区叙事与情感回报 | 不做分支剧情引擎 |
|
||||
| 经济与商店 | 连接产出与投资 | 不做玩家间交易市场 |
|
||||
| 季节天气与节日 | 时间压力与变化来源 | 不做动态天气模拟 |
|
||||
| 日终结算 | 闭合一天并钩住下一天 | — |
|
||||
| 出售原料或加工 | 出售可立即获得资金，但放弃加工增值或其他用途 | 加工可能提高价值，但占用设备并需要等待 |
|
||||
| 留在农场或外出探索 | 农场收益较稳定，但会放弃部分探索机会 | 探索带来稀有资源和发现，但消耗补给并占用维护时间 |
|
||||
| 深入探索或及时返程 | 深入可能增加资源与经验，也提高倒下或来不及返程的风险 | 返程保住已得成果并可安排其他活动，但放弃继续发现的机会 |
|
||||
| 升级工具或扩大生产 | 升级提升行动效率，但占用可用于扩产的资金 | 扩产提高产出潜力，但增加维护负担并推迟工具改善 |
|
||||
| 赚钱或社交 | 赚钱加快当前投资，但减少发展关系的时间 | 社交带来关系与后续回报，但放弃部分眼前收入 |
|
||||
| 追求效率或装饰与兴趣 | 效率安排加快成长，但减少自由探索和个性化活动 | 兴趣活动带来放松和表达，但可能减缓短期经济成长 |
|
||||
|
||||
## 范围与非目标
|
||||
最小完整版本包含：
|
||||
- 一个可经营农场
|
||||
- 一个小镇与若干功能区域
|
||||
- 基础农务、采集、钓鱼、制作、轻度战斗和探索
|
||||
- 有日程的 NPC、关系值、任务和社区目标
|
||||
- 工具/技能成长、商店经济与基础加工链
|
||||
- 季节、天气、节日和日终结算
|
||||
失败允许局部损失和机会错过，同时保留大部分长期进展。不同场景的后果需要分别判断，不能把温和压力理解为完全没有损失。
|
||||
|
||||
不做清单：
|
||||
- 不做无缝大型开放世界
|
||||
- 不做复杂实时多人或玩家交易市场
|
||||
- 不做以操作精度为核心的高难度战斗
|
||||
- 不为每个系统都添加独立小游戏
|
||||
- 不在本阶段确定具体数值、完整内容数量或实现方案
|
||||
|
||||
## 验证标准
|
||||
|
||||
| 验证点 | 成功标准 |
|
||||
| 情况 | 后果与恢复 |
|
||||
|---|---|
|
||||
| 一天循环成立 | 玩家能复述"今天做了什么、为什么、明天想做什么" |
|
||||
| 取舍真实存在 | 玩家在目标选择阶段出现可观察的犹豫或计划调整 |
|
||||
| 时间压力温和 | 玩家感到"今天做不完"而不是"今天被逼着做" |
|
||||
| 回流成立 | 玩家能把当日收益明确投入到下一轮计划 |
|
||||
| 长期钩子成立 | 玩家能说出自己"在为什么长期目标积累" |
|
||||
| 普通日常计划未完成 | 可继续的目标移到后续日期，重新安排优先级；限时目标按自身窗口处理 |
|
||||
| 深夜未归昏倒 | 当日行动终止，次日体力受限并有轻度损失，之后重新安排活动 |
|
||||
| 矿井中倒下 | 损失部分金钱或物品，保留大部分积累，补充准备后再探索 |
|
||||
| 季节更替未收获 | 不适应新季节的作物枯萎，需要改种；土地和已有设施仍可继续使用 |
|
||||
| 错过节日或窗口期 | 失去本次机会，等待后续周期或调整目标 |
|
||||
|
||||
## 开放问题
|
||||
- 休闲玩家与规划玩家的时间/体力压力如何共存？
|
||||
- 战斗在整体游戏中的最低必要深度是什么，如何避免压过生活模拟？
|
||||
- 社区目标应采用线性章节、可选收集，还是两者结合？
|
||||
- 终局是明确的阶段性结算，还是允许玩家在结算后继续自由生活？
|
||||
- 哪些信息必须通过 UI 直接展示，哪些信息可以保留为探索发现？
|
||||
损失幅度和恢复成本需结合试玩判断，不应把一次失误放大为长期无法恢复的挫败。
|
||||
|
||||
## 顶层定稿
|
||||
顶层当前定稿为：以一个游戏日为循环单位，时间与体力构成温和硬约束，农场、探索、社交三线互相供给的慢节奏生活循环；矿井战斗保持伴生风险定位，失败只造成少拿与顺延。
|
||||
后续架构必须围绕"一天"拆系统（时间/农场/探索/社交/经济/成长/结算）；不得把战斗、制作或任何支线做成独立主轴，不得引入生存焦虑型惩罚。
|
||||
## 系统范围与版本边界
|
||||
|
||||
以下是支撑完整版本的能力范围，架构层可按职责拆分或合并。
|
||||
|
||||
| 能力方向 | 目的与主要联系 | 边界 |
|
||||
|---|---|---|
|
||||
| 农场经营 | 承载规划与回报，与物品、制作和经济连接 | 不做生产线布局优化 |
|
||||
| 时间与体力 | 限制行动并影响日程选择 | 不做饥饿等生存需求式衰减 |
|
||||
| 探索与采集 | 提供资源、风险与发现，成果回到制作和投资 | 不做无限程序生成地牢 |
|
||||
| 轻度战斗 | 为矿井探索提供风险与节奏变化 | 不做装备驱动的成长主轴 |
|
||||
| 物品与制作 | 支持携带、资源转化与长期投资 | 不做复杂配方树管理 |
|
||||
| 技能成长 | 回应重复实践，改变效率与可选内容 | 不做技能树构筑 |
|
||||
| NPC 关系与任务 | 承载社区叙事与情感回报 | 不做分支剧情引擎 |
|
||||
| 经济与商店 | 连接产出、交易与投资 | 不做玩家间交易市场 |
|
||||
| 季节天气与节日 | 改变行动条件与阶段目标 | 不做动态天气模拟 |
|
||||
| 日终结算 | 汇总各活动进展，衔接次日与保存 | 不重复定义各活动的奖励规则 |
|
||||
|
||||
本例完整版本包含可经营农场、小镇与功能区域，基础农务、采集、钓鱼、制作、轻度战斗和探索，以及居民日程、关系、任务、社区目标、工具与技能成长、商店加工、季节天气和节日。具体内容数量与详细规格后续展开。
|
||||
|
||||
范围排除无缝大型开放世界、复杂实时多人、玩家交易市场、高难度战斗，以及为每个系统附加独立小游戏。
|
||||
|
||||
## 原型验证与开放问题
|
||||
|
||||
以下是验证计划，尚不代表已经通过试玩。原型按问题分步覆盖，不要求一次实现完整版本。
|
||||
|
||||
| 需要判断的问题 | 原型范围与游玩跨度 | 判断依据 |
|
||||
|---|---|---|
|
||||
| 日常计划能否形成有意义的选择 | 一个游戏日，包含农务、基础外出采集、时间体力与结算 | 观察目标选择与中途调整，结合玩家对选择理由的说明，判断限制是否真正影响行动 |
|
||||
| 当天成果能否支持后续计划 | 连续数个游戏日，包含作物成长与收获、出售、种子或工具投资、基础成长 | 观察收益是否进入下一轮活动，并询问玩家接下来想改善什么；仅能复述流程不足以证明愿意继续 |
|
||||
| 时间压力是否符合休闲体验 | 让偏休闲与偏规划的玩家尝试上述日常流程 | 结合未完成计划的频率、返程行为和体验反馈，判断是可接受的取舍还是被任务催促 |
|
||||
| 轻度战斗是否改善探索节奏 | 基础日常流程后加入一个矿井遭遇 | 观察理解、停顿和损失后的恢复，结合玩家反馈判断战斗是否压过探索与生活体验 |
|
||||
| 社区与成长能否形成长期目标 | 后续加入代表性的关系事件与社区目标，保留必要的多日推进 | 观察玩家是否愿意投入、如何解释目标价值；单日原型不据此宣称长期体验成立 |
|
||||
|
||||
首个原型聚焦农务、基础地图与采集、时间体力、物品、经济、基础成长和日终结算。钓鱼深度、节日全量、完整社区内容和更多区域不作为首个原型的必需内容。
|
||||
|
||||
后续仍需展开的问题包括：
|
||||
|
||||
- 时间、体力和损失的具体幅度：核心方向已明确为温和规划压力，通过原型比较具体参数。
|
||||
- 战斗的最低必要深度：根据代表性遭遇的试玩结果确定，再补齐系统规格。
|
||||
- 社区目标采用章节、可选收集还是结合：在社区内容进入实现范围前明确，以便架构判断相应能力。
|
||||
- 终局结算与后续自由生活：不阻塞早期日常原型，在确定完整版本的终局内容前解决。
|
||||
- UI 直接展示与探索发现的边界：先保证原型的关键行动与结果可理解，再结合试玩展开详细信息设计。
|
||||
|
||||
这些问题若改变当前范围或关键玩法，应回到受影响的正文调整，不能只留在问题清单中。
|
||||
|
||||
+13
-11
@@ -16,9 +16,9 @@ description: 写"美术圣经"（美术侧）分册时使用。与总纲（技
|
||||
|
||||
- **风格统一是资产效率的前提**：没有圣经，每张图都在重新发明风格；
|
||||
有了圣经，一百张素材共享同一套锚点。
|
||||
- **视觉锚从定调翻译，不从审美发明**：参照选择、调性滑杆、T 原则是
|
||||
源头（概念层第 2 节定调记录），你的工作是翻译成关键词、色板、形状语言
|
||||
——不是自己另起一套审美。
|
||||
- **视觉设计承接概念**：依据概念层的核心体验、情绪基调、风格及相关约束，
|
||||
形成关键词、色板和形状语言。需要追溯时引用具体内容或章节，
|
||||
完整视觉规格写入本圣经。
|
||||
- **每个可见对象必须绑定资产或显式豁免**：GDD 里出现的每个 gameplay 可见
|
||||
对象，要么在资产总清单有一行，要么显式标"程序化生成/UI 文本/本期不需要"
|
||||
——没有第三种状态。漏绑定的对象会在开发中期以"缺素材"形式爆炸。
|
||||
@@ -29,7 +29,7 @@ description: 写"美术圣经"（美术侧）分册时使用。与总纲（技
|
||||
|
||||
## 二、动笔前
|
||||
|
||||
1. 输入齐了吗：概念层定调记录与身份基调（翻译源头）、系统文档全部可见
|
||||
1. 输入齐了吗：概念层与视觉有关的体验、基调和约束（设计依据）、系统文档全部可见
|
||||
对象（资产总清单的范围）、物品表（item_id 绑定依据，数据侧已定）、
|
||||
可复用画风规范。
|
||||
2. 本件在数据侧表结构定稿后开写（素材清单引用 item_id）。
|
||||
@@ -38,9 +38,9 @@ description: 写"美术圣经"（美术侧）分册时使用。与总纲（技
|
||||
## 三、怎么写（模板即流程，按节）
|
||||
|
||||
### 1. 视觉风格总览
|
||||
一段话 + 参考图位。从定调记录翻译：参照的视觉气质、滑杆值对应的视觉
|
||||
密度、T 原则对应的视觉禁忌。**style_id 在此定名**——本项目全部素材
|
||||
提示词共用此锚。
|
||||
一段话 + 参考图位。结合概念层的体验、基调与约束，说明视觉气质、信息密度
|
||||
和需要避免的表现；有视觉参照时说明具体借鉴点。**style_id 在此定名**——
|
||||
本项目全部素材提示词共用此锚。
|
||||
|
||||
### 2. 视觉锚（七件套）
|
||||
关键词（3~5 个）/ 禁用关键词 / 色板（主色辅色点缀+配比）/ 形状语言 /
|
||||
@@ -75,9 +75,11 @@ description: 写"美术圣经"（美术侧）分册时使用。与总纲（技
|
||||
→运行时截图验收→**通过后才批量扩产**。验收判据写行为：桌面与移动视口
|
||||
下阵营/状态/反馈是否一眼可辨。
|
||||
|
||||
### 6. 开放问题回执
|
||||
视觉与玩法冲突、素材成本超预算（面数/张数/工时）、锚点两难——全部走
|
||||
回执：问用户的升级决策卡，代决的记台账。
|
||||
### 6. 未决问题与待办
|
||||
视觉与玩法冲突、素材成本超预算（面数/张数/工时）、锚点两难等未决问题，
|
||||
记明影响和下一步；涉及产品取舍时请用户确认并同步 GDD。解决后把完整规格
|
||||
补入本圣经与资产清单，关闭待办。影响当前素材施工的关键问题未解决时，
|
||||
不宣称该范围已完备。
|
||||
|
||||
## 四、写完自查（参考，不是闸门）
|
||||
|
||||
@@ -88,6 +90,6 @@ description: 写"美术圣经"（美术侧）分册时使用。与总纲（技
|
||||
|
||||
## 五、红线（承总纲四条，本件特化）
|
||||
|
||||
1. 视觉锚必须能溯源到定调记录，不许无锚发明审美。
|
||||
1. 视觉规格应与概念层的体验、基调和约束一致，并在本圣经中写全。
|
||||
2. 素材契约每行必绑 item_id 或写豁免类型。
|
||||
3. 画风卡引用必带版本；工艺沿用既有复用能力的工艺卡，不即兴写流程。
|
||||
|
||||
+5
-3
@@ -74,7 +74,8 @@ draft 调试可见/两 disabled 不加载、deprecated 留 ID 占位防复用）
|
||||
种子，防读档刷结果。
|
||||
|
||||
### 6. 数值填充与验算
|
||||
结构定稿后才填数。每项代决记台账（默认值+依据+推翻条件）。**前五日
|
||||
结构定稿后才填数。实际数值、单位、适用范围和默认值写在本册配表与字段
|
||||
契约中；重要取舍按需记分析。**前五日
|
||||
闭环验算必做**：按架构统一数值基准排五日表（主目标/关键行动/成本/获得/
|
||||
结果），加收益链校验（`区域→敌人→材料→配方→产出`逐环引 ID）——验算
|
||||
结论写回：第 1 日不要求做完、奖励多元不单一、第 5 日出现取舍但仍留两条
|
||||
@@ -85,7 +86,8 @@ draft 调试可见/两 disabled 不加载、deprecated 留 ID 占位防复用）
|
||||
（对话/提示/图鉴文案）逐行填满。这是"纯看 TDD 做完游戏"的数据前提：
|
||||
程序加载表即得完整内容，不再回 GDD 找"这里应该有 8 种作物"。验收在七查
|
||||
之外加第八查——**内容完成度**：每表计划行数 vs 实填行数，缺口列清单回填；
|
||||
填数每项代决记台账。文本表由文本系统文档的文案收编（带版本锁）。
|
||||
未决的填充缺口记明影响和下一步，解决后补齐配表并关闭待办。文本表由文本
|
||||
系统文档的文案收编（带版本锁）。
|
||||
|
||||
### 7. 验收（七查+三级）
|
||||
主键/引用/枚举/单位/范围五查必须过；业务规则/重复归属两查需设计师复核。
|
||||
@@ -104,5 +106,5 @@ note 不阻断。验收记录表留 check_id 与 data_version。**结构、规
|
||||
## 五、红线（承总纲四条，本件特化）
|
||||
|
||||
1. 表里不写散文；规则进契约文档。
|
||||
2. 数值填充的每个代决都进台账，无痕改数=违规。
|
||||
2. 数值变更同步更新本册配表、字段契约和受影响的验算；重要取舍按需记分析，不以外部台账替代施工数据。
|
||||
3. 有 blocker 不许扩内容——没有例外。
|
||||
|
||||
+5
-4
@@ -15,7 +15,7 @@ description: 写"技术实现"（程序侧）分册时使用。与总纲（技
|
||||
|
||||
- **自包含**：TDD 开头"来自 GDD 的功能"节必带——读者不回翻 GDD 就能开工。
|
||||
- **平台事实置顶且禁改**：自包含 Web、双视口、键鼠+触控、本地 HTTP 预览。
|
||||
一切技术选择先过这道闸；GDD 里出现平台做不到的需求，回执上报，不硬做。
|
||||
一切技术选择先过这道闸；GDD 里出现平台做不到的需求，记明问题、影响与下一步，涉及产品取舍时请用户确认，不硬做。
|
||||
- **能力边界说三态**：native（原生支持）/ emulated（需模拟封装）/ gated
|
||||
（本期不做，写明替代方案）——程序侧不许答应 GDD 做不到的事。
|
||||
- **性能预算是基准不是完美**：每项指标写上限、写测量方式，当取舍依据用，
|
||||
@@ -69,8 +69,9 @@ HTML 的 Canvas/WebAudio/localStorage）、**自封装**（基础 API 上自己
|
||||
实现类需求先查可复用能力；记录来源、适用版本与实例化参数；没有现成能力时写明来源与理由。
|
||||
|
||||
### 7. 场景与镜头 / 输入与操作 / 音频
|
||||
三节各一张表：场景（tilemap 结构/镜头行为，代决记台账）；输入（动作×
|
||||
键盘×触控对照）；音频（用途×格式规格×触发点×依据）。
|
||||
三节各一张表：场景（tilemap 结构/镜头行为，规格和参数写全）；输入（动作×
|
||||
键盘×触控对照）；音频（用途×格式规格×触发点×依据）。各项实现默认值
|
||||
也写在对应正文，重要取舍按需记分析，不让施工方依赖外部台账。
|
||||
|
||||
### 8. 构建与验证
|
||||
构建流程 + 验证分级：自动（什么命令、什么输出为过）、半自动（双视口
|
||||
@@ -88,6 +89,6 @@ HTML 的 Canvas/WebAudio/localStorage）、**自封装**（基础 API 上自己
|
||||
|
||||
## 五、红线（承总纲四条，本件特化）
|
||||
|
||||
1. 平台事实禁改；与 GDD 冲突走回执，不就地硬做。
|
||||
1. 平台事实禁改；与 GDD 冲突时说明影响和下一步，涉及产品取舍时请用户确认并同步 GDD。
|
||||
2. 可复用能力引用必带版本与参数。
|
||||
3. 里程碑判据不许写"基本""大致""感觉"。
|
||||
|
||||
+24
-37
@@ -3,7 +3,7 @@
|
||||
---
|
||||
name: game-gdd-architecture
|
||||
description: 写游戏策划案（GDD）系统架构时使用。在顶层设计定稿之后，
|
||||
把顶层的系统范围表正式切成 Sxx 系统：编号、职责、依赖、数据流、优先级，
|
||||
把顶层的能力范围正式切成 Sxx 系统：编号、职责、依赖、数据流、优先级，
|
||||
并向系统文档交付目录映射与 MVP 闭环。配套：templates/architecture.md、
|
||||
templates/analysis.md（全局一份）、exemplars/stardew-architecture.md、templates/stardew-analysis.md（全局一份）。
|
||||
---
|
||||
@@ -25,15 +25,15 @@ description: 写游戏策划案（GDD）系统架构时使用。在顶层设计
|
||||
- **依赖无环**是硬要求；信息呈现层只读状态、只经行动入口写入。
|
||||
- 架构是全项目返工最多的一份（实测 11 版 vs 概念层 2 版）——所以每次改刀
|
||||
都要写变更记录，让"为什么这么切"可追溯。
|
||||
- 你不越层：上不重定义玩法循环（那是顶层的），下不写单系统内部规则
|
||||
- 你不越层：上不重定义玩法过程（那是顶层的），下不写单系统内部规则
|
||||
（那是系统文档的），字段定义与数值配置归技术文档层（数值策划）。
|
||||
|
||||
## 二、动笔前
|
||||
1. 顶层设计已定稿可用——把它的**系统范围表**（粗清单）和**顶层定稿约束**
|
||||
摊开当输入；切分是对粗清单的正式化（拆、并、裁都在这层做）。
|
||||
1. 顶层设计已定稿可用——以其中的玩法过程、能力范围、版本边界和验证计划为输入；
|
||||
按职责拆分、合并系统，不要求与顶层清单逐项对应。需要改变已定范围时先讨论相关决定。
|
||||
2. 读取 exemplars/stardew-architecture.md 了解内容组织方式，
|
||||
然后往 templates/architecture.md 里填。
|
||||
3. 记住顶层的核心循环图——切完必须跑覆盖检查。
|
||||
3. 根据顶层已有的文字、表格或图检查玩法覆盖，不要求额外补画固定循环图。
|
||||
|
||||
## 三、架构设计的组织维度：写什么、为什么、怎么咬合
|
||||
|
||||
@@ -41,15 +41,15 @@ description: 写游戏策划案（GDD）系统架构时使用。在顶层设计
|
||||
**这个架构为什么这样切（1~3）→ 系统是什么、怎么连接（4~6）→
|
||||
怎么落地、怎么验证（7~11）→ 还有什么没想清（12）。**
|
||||
|
||||
第 1 节承顶层的定稿约束开篇，MVP 闭环在中间当守门员，开放问题收尾。
|
||||
第 1 节承顶层已确定的范围与约束开篇，MVP 闭环在中间当守门员，开放问题收尾。
|
||||
|
||||
| # | 节 | 是什么 | 为什么写 | 和谁咬合 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | 架构定位与目标 | 阶段边界（定哪些系统、不展开内部）+ 划分原则 + 一句话架构 + **变更记录** | 防止架构漂离顶层；改刀可追溯 | 承顶层定稿；变更记录引登记编号 |
|
||||
| 1 | 架构定位与目标 | 阶段边界（定哪些系统、不展开内部）+ 划分原则 + 一句话架构 + **变更记录** | 防止架构漂离顶层；改刀可追溯 | 承顶层已确定的范围与约束；必要时引用相关分析 |
|
||||
| 2 | 系统地图 | Sxx 编号清单（=系统文档范围真源）+ 支撑层 + P0 段五列表（目的/输入/输出/P0原因） | 编号让系统可引用；P0 原因逼答"删了塌什么" | **对下真源**：Sxx ↔ 04 系统文档一一对应 |
|
||||
| 3 | 系统职责 | 职责表（负责/不负责→移交谁）+ 逐系统说明段 | 边界写死，防两个系统管同一件事 | 系统文档的"边界与非目标"必须与此对齐 |
|
||||
| 4 | 依赖与数据流 | 依赖图（无环）+ 数据流图 + 主要状态 + 主数据归属规则 | 谁读谁、数据从哪到哪——接口的真源 | 顶层的资源流图在此展开成系统级 |
|
||||
| 5 | 核心循环覆盖检查 | 顶层每个循环环节 → 认领系统 | 顶层→架构的验收线，防切系统切碎循环 | 对上接口：逐环节对照顶层循环图 |
|
||||
| 4 | 依赖与数据流 | 依赖图（无环）+ 数据流图 + 主要状态 + 主数据归属规则 | 谁读谁、数据从哪到哪——接口的真源 | 顶层的资源与进展关系在此展开成系统级 |
|
||||
| 5 | 玩法覆盖检查 | 顶层玩法环节与关键规则 → 负责或协作系统 | 防止系统切分遗漏玩法能力 | 对照顶层已有的玩法描述，检查职责覆盖与分工 |
|
||||
| 6 | 目录映射 | 职责 → 物理文档目录的归并表 | 职责数≠文档数；归并规则显式化 | **对下接口**：系统文档照此开工 |
|
||||
| 7 | MVP 最小闭环 | 编号验证链 + 守门句（"闭环不成立不许加东西"） | 立项后第一条要跑通的链 | 对应顶层验证标准；失败回顶层而非加系统 |
|
||||
| 8 | 统一数值基准 | 单位清单 + 四类定性基准（时间/货币/成长/体力风险的风格约束） | 各系统单独配数值会互相失衡；先定全局尺度 | **数值换算与验算归技术文档层**，此处只到定性 |
|
||||
@@ -61,11 +61,11 @@ description: 写游戏策划案（GDD）系统架构时使用。在顶层设计
|
||||
咬合一图：
|
||||
|
||||
```
|
||||
顶层定稿 + 系统范围表（粗清单）
|
||||
顶层玩法过程、能力范围与版本边界
|
||||
↓ 正式切分（拆/并/裁）
|
||||
1 定位与目标 ──► 2 系统地图（Sxx 真源）──► 3 职责表
|
||||
↓ ↓ ↓
|
||||
5 循环覆盖检查 ◄── 4 依赖与数据流（接口真源）
|
||||
5 玩法覆盖检查 ◄── 4 依赖与数据流（接口真源）
|
||||
↓
|
||||
6 目录映射 ──► 7 MVP 最小闭环（守门员）
|
||||
↓
|
||||
@@ -74,17 +74,17 @@ description: 写游戏策划案（GDD）系统架构时使用。在顶层设计
|
||||
12 开放问题 →（进分析文档 / 系统文档开题）
|
||||
```
|
||||
|
||||
三个接口：**对上**承顶层系统范围表并跑循环覆盖检查；**对内**地图↔职责↔依赖
|
||||
三个接口：**对上**承顶层能力范围并跑玩法覆盖检查；**对内**地图↔职责↔依赖
|
||||
三方一致、主数据归属唯一；**对下**目录映射 + MVP 闭环喂系统文档。
|
||||
|
||||
## 四、怎么写（模板参考结构，建议按此组织）
|
||||
（本节是带写法要领的教学版；实际填写的纯净模板在 templates/architecture.md）
|
||||
|
||||
### 1. 架构定位与目标
|
||||
本阶段确定"哪些系统支撑一轮玩法"，不展开单系统内部规则。
|
||||
本阶段确定哪些系统支撑已确定的玩法与版本范围，不展开单系统内部规则。
|
||||
划分原则：__。一句话架构：
|
||||
> （玩家通过哪些系统、以什么因果，把一轮玩法的输入变成下一轮的选择）
|
||||
变更记录：日期 + 改了什么 + 为什么（引登记编号）。
|
||||
> （玩家通过哪些系统完成主要行动，结果如何推动过程继续或结束）
|
||||
变更记录：日期 + 改了什么 + 为什么，必要时引用相关分析。
|
||||
→ 没有变更记录的架构文档，第二轮迭代就会变成黑箱。
|
||||
|
||||
### 2. 系统地图
|
||||
@@ -104,9 +104,9 @@ P0 段五列表：
|
||||
主数据归属规则：规则与数据表分工 / 稳定 ID 关联 / 任何系统不复制他系统主数据。
|
||||
→ 依赖图出现环 = 回去重切。
|
||||
|
||||
### 5. 核心循环覆盖检查
|
||||
| 顶层循环环节 | 认领系统 |
|
||||
→ 逐环节对照顶层循环图；有环节无人认领或多人认领都是切分错误。
|
||||
### 5. 玩法覆盖检查
|
||||
| 顶层玩法环节或关键规则 | 负责或协作系统 |
|
||||
→ 对照顶层已有的玩法描述，检查当前范围内的能力是否遗漏；多个系统共同支持一个环节时，明确分工，避免同一职责由多个系统重复维护。
|
||||
|
||||
### 6. 目录映射
|
||||
| 目录 | 本阶段定位 |
|
||||
@@ -114,6 +114,7 @@ P0 段五列表：
|
||||
系统文档以此开工：地图上没有的系统不许有文档。
|
||||
|
||||
### 7. MVP 最小闭环
|
||||
依据顶层的版本范围与验证计划，确定最先实现的完整可玩流程；可以是线性推进或循环，不固定为单个体验片段。
|
||||
1. __ 2. __ …（编号验证链，一条玩家可走的完整因果）
|
||||
守门句：如果这条闭环不成立，不应继续增加 __。
|
||||
→ 闭环失败回顶层改设计，不是加系统打补丁。
|
||||
@@ -132,34 +133,20 @@ P1/P2 可用能力表（能力/说明）控制颗粒度。
|
||||
|
||||
### 11. 风险与校验
|
||||
| 风险 | 校验方式 |
|
||||
→ 从概念层跑偏风险和顶层失败档位反推；校验方式要可观察。
|
||||
→ 结合概念层跑偏风险、顶层关键规则与验证问题识别结构风险，说明相应校验方式。
|
||||
|
||||
### 12. 开放的结构问题
|
||||
→ 结构级（接口归属/统一格式/合并拆分）才留这里；数值细节不留。
|
||||
|
||||
## 五、分析文档（全局一份，按层分节）
|
||||
## 五、分析参考
|
||||
|
||||
**全局共用 `project/analysis.md`**：论证按发生层归节，决定登记表全项目共用，
|
||||
跨层引用查这里。模板与例子：资源 `templates/analysis.md`、
|
||||
`templates/stardew-analysis.md`。已决论证与登记写入分析文档，
|
||||
灵感池、代决、待原型等活队列写入决策台账。
|
||||
|
||||
- 条目格式：`## 问题：<一句话>` ＋ 状态（agent_proposal / user_confirmed /
|
||||
superseded，登记 D-__）＋ 广度分析（牵动面＋候选 ≥2）＋ 深度分析
|
||||
（逐候选利弊依据，必须引 T 原则/锚点/张力编号，写不出依据的偏好不进分析）
|
||||
＋ 综合判断（建议取 __ 因为 __；推翻条件：__）。
|
||||
- 分诊三条件全满足才进：① 影响项目方向或边界；② ≥2 合理候选；③ 一时定不了。
|
||||
不满足的：就地小权衡直接进登记表一行，不写条目。
|
||||
- 本层标准问题：结构级争议——接口统一、系统归并、主数据归属划分。
|
||||
- 数量纪律：按需；架构期问题多为接口与归属二义。
|
||||
- user_confirmed 后三件事：结论一句话迁入 design.md 对应节（留修订痕迹）；
|
||||
登记表加行（编号全项目连续，跨层引用写 D-__）；本条目改状态记 D 号保留不删。
|
||||
推翻时新增行挂旧行编号，旧行不删。
|
||||
可关注系统拆分、接口和数据归属中的重要争议。
|
||||
按需参考 `templates/analysis.md` 和 `templates/stardew-analysis.md`。
|
||||
|
||||
|
||||
## 六、自查参考
|
||||
- 每个 Sxx 都能一句话答"删了它什么塌"吗？
|
||||
- 顶层的循环环节全覆盖、无重复认领吗？
|
||||
- 顶层当前范围的玩法环节和关键规则是否覆盖完整，协作分工是否清楚？
|
||||
- 依赖图无环？主数据无一物两管？
|
||||
- 系统文档拿到目录映射能直接开工吗？
|
||||
- 有没有字段定义或数值配置偷偷写进来？（该在技术文档层）
|
||||
|
||||
@@ -1,163 +1,44 @@
|
||||
## A1 概念层分册（game-gdd-concept）
|
||||
|
||||
---
|
||||
name: game-gdd-concept
|
||||
description: 写游戏策划案（GDD）概念层时使用。把一句话游戏想法写成一份
|
||||
"一次写对、之后不动"的立项概念文档——它是后续所有设计争议的仲裁依据。
|
||||
任何游戏类型通用。配套：templates/concept-design.md、templates/analysis.md（全局一份）、
|
||||
exemplars/stardew-concept.md、templates/stardew-analysis.md（全局一份）。
|
||||
---
|
||||
|
||||
# 概念层写法（策划 · 概念层分册）
|
||||
|
||||
> 本文件是概念层唯一承载写作流程的教学件。
|
||||
> 模板与例子文件保持纯净：不含任何步骤、检验提示与标记。
|
||||
产物：`project/00_concept/design.md`。
|
||||
参考资源：`templates/concept-design.md`、`exemplars/stardew-concept.md`；全局分析文档的模板与样例：`templates/analysis.md`、`templates/stardew-analysis.md`。
|
||||
|
||||
## 〇、结构适配原则
|
||||
## 判断立场
|
||||
|
||||
根据游戏类型、项目规模、用户要求和上层已定范围选取本分册的适用内容，同类项可合并；复杂项目可以拆分补充，简单项目可以压缩为最小可用规格。
|
||||
- 聚焦游戏的核心体验和主要吸引力，为后续设计提供依据。
|
||||
- 用具体的玩家行为、情境和感受说明设计，避免空泛描述。
|
||||
- 不把自己的建议写成用户已经作出的决定。
|
||||
|
||||
## 一、这一层的判断立场
|
||||
你是资深游戏策划，看过上千份概念案，清楚绝大多数死在"什么都说、什么都不尖"。
|
||||
在这个层里你相信：
|
||||
- 概念的成败在取舍，不在丰富：一句话里卖点只许有一个。
|
||||
- 你写的是裁判文档：后续每一层的设计争议，都要能回到这里找到仲裁。
|
||||
- 具体压倒抽象："压力很大"是废字，"每开一扇门都在烧自己的命"才是概念。
|
||||
- 用户没说过的话不当他说过：宁可标"待确认"，不替人拍板。
|
||||
- 发现自己在堆形容词 = 概念没想清楚：停笔回去问，别用空话盖过去。
|
||||
- 概念层是"一次写对、之后不动"的层（实作中它的返工率远低于架构与
|
||||
系统层），所以判断力要前置堆足，不要指望后面回来改。
|
||||
## 动笔前
|
||||
|
||||
## 二、动笔前
|
||||
1. 拿到用户真实回答过的定调信息（参照对象、题材偏好、压力档位）。
|
||||
没有 → 先问一个定调问题，禁止自问自答充当用户。
|
||||
2. 读取 exemplars/stardew-concept.md 了解内容组织方式，
|
||||
然后往 templates/concept-design.md 里填。
|
||||
3. 零参照时在文档头注明"零参照"。
|
||||
结合已有对话、用户资料和项目文档开展设计。信息不足时，判断是否影响当前概念的成立或关键方向，再决定需要补问什么；可以依据已有信息推进的部分先完成。
|
||||
|
||||
## 三、概念设计的组织维度：写什么、为什么、怎么咬合
|
||||
模板和样例按需参考。参照有助于沟通时，说明具体借鉴什么；不能把参照作品的其他设计自动视为用户选择。
|
||||
|
||||
概念文档回答四个问题：
|
||||
**这是什么（1~5）→ 它不是什么（6）→ 它靠什么让人一直玩（7）→
|
||||
它管到哪、交出什么（8~9）。**
|
||||
## 内容组织
|
||||
|
||||
第 1 节是全案的压缩态，第 9 节是全案的判断态重述，首尾呼应；
|
||||
中间各节从"设计锚点"这个枢纽长出来，争议又都回头接受它的仲裁。
|
||||
概念设计明确核心体验、主要吸引力和重要边界，作为后续玩法与系统设计的依据。根据游戏类型、项目规模和用户要求组织内容，可以合并、拆分或省略不适用的部分。
|
||||
|
||||
| # | 节 | 是什么 | 为什么写 | 和谁咬合 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | 一句话概念 | 全案压缩成一句：品类+融合+唯一卖点 | 概念的第一命运是被转述；这句立不住，后面写得再好都救不回来 | 9 是它的重述；2 是它的展开 |
|
||||
| 2 | 定调与设计锚点 | 定调记录（参照/滑杆/T 原则，调性真源）+ 六个仲裁位：幻想/体验/动机/循环/跑偏/非目标 | 概念层把调定死：后续所有开放问题先回定调记录级联（约八成可就地定），级联不掉的才上决策卡；概念文档的核心职能是当裁判 | **全文档枢纽**：3~6 由它长出；7 由它的循环与动机抽出；定调记录被顶层及以下所有层引用 |
|
||||
| 3 | 玩家身份与基调 | 玩家在虚构里是谁 + 情绪温度与红线 | 幻想需要一张脸和一种温度，否则是空话；基调边界句防调性漂移 | 身份 = 幻想的具象化；基调 = 目标体验的情绪面 |
|
||||
| 4 | 风格与世界观 | 支撑玩法的世界规则 + 叙事载体 | 世界观是给玩法供氧的背景板，不是设定集 | 服务 3 的身份与基调；世界规则支撑 2 的核心循环成立 |
|
||||
| 5 | 目标玩家与情境 | 为谁、什么场景、门槛多高 | 同一设计对不同人是不同游戏；受众映射防止"谁都适合=谁都不适合" | 反面校验 2 的目标体验；情境（一局多久）给 7 的循环定参数 |
|
||||
| 6 | 不是什么 | 负面定位表：不是 X，因为 Y | 正面定义写多必然发散；负面定位用"误会方向+封死原因"收边界，比光秃的非目标锋利一档 | 2 的非目标与跑偏风险的表化展开；与 5 的防串味声明呼应 |
|
||||
| 7 | 核心张力 | 玩家持续面对的两难，两端各有代价 | 长期游玩的根本动力；没有张力，再丰富的内容玩几次就腻 | **向下接口**：每条张力必须在顶层变成取舍表里的具体决策 |
|
||||
| 8 | 边界与约束 | 本层只定什么、什么留给后面 + 规模回流 | 防止概念层越层写数值和系统（越层是下游返工之源）；给写作画线 | 保护 2 的纯度；告诉顶层"你们的地盘从哪开始" |
|
||||
| 9 | 概念定稿 | "核心不是 __ 而是 __"重述 + 按需记录给顶层的约束 | 收口并检查概念是否写散；把承诺转成对下的契约 | 回环呼应 1；把边界和交接约束传给下一层 |
|
||||
- **游戏概念**：简洁说明游戏是什么、玩家做什么、吸引力在哪里。多个特点可以共同支撑核心体验。
|
||||
- **体验与玩法**：说明玩家在什么情境下感到什么、为什么愿意继续，以及主要行动如何形成游玩过程。存在重要取舍时，说明选择及代价。
|
||||
- **身份、基调与世界观**：有助于理解游戏时，说明玩家身份、情绪基调、风格和必要的世界规则。叙事载体按项目需要展开。
|
||||
- **目标玩家与情境**：说明面向哪些玩家、适合怎样的游玩情境，以及体验门槛。
|
||||
- **边界与约束**：说明容易混淆的方向、排除理由和实际的跑偏风险；依据团队与项目条件确定规模。后续设计需要遵守的约束在相关内容中写清，无需结尾重复定稿。
|
||||
|
||||
咬合一图：
|
||||
设计原则用自然语言说明对本项目的实际影响。它们帮助判断方向，不能替代具体问题的分析。
|
||||
|
||||
```
|
||||
1 一句话概念（压缩态）
|
||||
↓ 展开
|
||||
2 设计锚点（枢纽 · 仲裁位）◄── 所有节的争议回来找它
|
||||
├→ 3 身份基调 ──→ 4 风格世界观（给玩法供氧）
|
||||
├→ 5 目标玩家（反面校验）──→ 6 不是什么（负面收边）
|
||||
└→ 7 核心张力（动力结构）──→ 【交给顶层】取舍表
|
||||
8 边界与约束（画线：本层到此为止）
|
||||
↓ 回环
|
||||
9 概念定稿（判断态重述 + 交接契约）
|
||||
```
|
||||
## 展开深度
|
||||
|
||||
记住三个接口：**对内**锚点仲裁一切；**对下**张力变取舍表、定稿变硬约束；
|
||||
**对上**边界画线防止越层。九节不是清单，是一台咬合的机器。
|
||||
围绕概念成立所需的信息展开。能够说明核心体验或重要约束的具体信息可以保留，包括必要的数值、操作方式和界面形式；详细系统规则、数值平衡和界面规格留待后续展开。
|
||||
|
||||
## 四、怎么写（模板参考结构，建议按此组织）
|
||||
（本节是带写法要领的教学版；实际填写的纯净模板在 templates/concept-design.md）
|
||||
有意义但信息不足的内容，保留已知内容与待补问题；不为填满模板编造身份、世界观、张力或其他设定。
|
||||
|
||||
### 1. 一句话概念
|
||||
《__》是一款 __（品类与融合）：玩家通过 __，把 __ 逐步 __。
|
||||
→ 45~90 字，卖点唯一。检验：删掉那个卖点句子依然成立，说明没写对。
|
||||
## 分析参考
|
||||
|
||||
### 2. 定调与设计锚点（先定调，再立仲裁位）
|
||||
**定调记录**（全项目调性真源，此节定死）：
|
||||
- 参照选择：以 __ 为主、__ 学 __（参照即定调，选完调性随之而来）。
|
||||
- 调性滑杆：压力感/战斗比重/管理深度/叙事比重/节奏，各一档。
|
||||
- 调性锚 T 原则：按项目需要提炼并逐条具名（如"T2 不劝退——凡惩罚类问题默认取最轻档"）。
|
||||
检验：每条 T 都能当一句 IF-THEN 用——"凡__类问题默认__"；写不出口径的 T 是空话。
|
||||
→ 下游每个开放问题先来这里级联批量起草，级联不了的才升级提问。
|
||||
**设计锚点（六项，争议时的仲裁原则，全部具名）**
|
||||
- 核心幻想：一句描述 + 一句玩家念头（引号写出玩家脑中的自言自语）。
|
||||
检验：念头句写不出来 = 幻想没立住，回去重想，不要用描述糊弄。
|
||||
- 目标体验：何时感到什么。
|
||||
- 玩家动机：短期 __；长期 __。
|
||||
- 核心循环：__ → __ → __ → __ → 回到 __（箭头式）。
|
||||
- 跑偏风险：本项目可能的真实偏航，不放万金油。
|
||||
- 非目标：一行带过，详表见第 6 节。
|
||||
可关注核心体验的取舍，以及哪些范围扩张会稀释它。按需参考 `templates/analysis.md` 和 `templates/stardew-analysis.md`。
|
||||
|
||||
### 3. 玩家身份与基调
|
||||
- 玩家身份：玩家在虚构里是谁 + 本项目的核心节奏，一口气说清。
|
||||
- 情绪基调：正面定调 + 边界句——"可以 __，不可以 __"。
|
||||
## 交付检查
|
||||
|
||||
### 4. 风格与世界观
|
||||
世界观为 __（玩法）服务；叙事通过 __（载体）展开。禁编年史、种族志。
|
||||
|
||||
### 5. 目标玩家与情境（受众映射三件套）
|
||||
- 与谁的受众重合；吸收了谁的什么需求；**为什么不会变成它**（防串味声明，
|
||||
参照越多越必须有这句）。
|
||||
- 情境与门槛：单人/多人；一局多久；需要理解 __，不应要求 __。
|
||||
|
||||
### 6. 不是什么（负面定位表）
|
||||
| 不是 | 因为 |
|
||||
→ 每行原因要封死一条具体误会方向（例：不是武器店经营｜武器主要拿去
|
||||
战斗，不是卖给顾客）。从锚点的非目标与跑偏风险长出来，通常 4~6 行。
|
||||
|
||||
### 7. 核心张力
|
||||
- __ 有限，但 __。
|
||||
- __ vs __（两端的代价各是什么）。
|
||||
→ 如果项目存在核心张力，保留的每条张力都应说明双方代价；没有形成有效张力时，不为了满足结构新增张力。这些是顶层取舍表的种子，后面按需对应。
|
||||
|
||||
### 8. 边界与约束
|
||||
- 概念边界放首位：本层只定幻想、用户、基调与排除方向；具体数值、
|
||||
系统清单、MVP 内容留给顶层及以后。
|
||||
- 规模与回流：单人可维护；所有系统回流核心循环。
|
||||
- 参照声明：学组织方式，不复制角色/文本/美术/数值。
|
||||
|
||||
### 9. 概念定稿（收口重锤）
|
||||
这个游戏的核心不是 __，而是：
|
||||
> （一句话重述核心承诺）
|
||||
交给下一层的约束：按项目需要记录，顶层据此展开。
|
||||
|
||||
若某节对本项目没意义，直接省略。
|
||||
|
||||
## 五、分析文档（全局一份，按层分节）
|
||||
|
||||
**全局共用 `project/analysis.md`**：论证按发生层归节，决定登记表全项目共用，
|
||||
跨层引用查这里。模板与例子：资源 `templates/analysis.md`、
|
||||
`templates/stardew-analysis.md`。已决论证与登记写入分析文档，
|
||||
灵感池、代决、待原型等活队列写入决策台账。
|
||||
|
||||
- 条目格式：`## 问题：<一句话>` ＋ 状态（agent_proposal / user_confirmed /
|
||||
superseded，登记 D-__）＋ 广度分析（牵动面＋候选 ≥2）＋ 深度分析
|
||||
（逐候选利弊依据，必须引 T 原则/锚点/张力编号，写不出依据的偏好不进分析）
|
||||
＋ 综合判断（建议取 __ 因为 __；推翻条件：__）。
|
||||
- 分诊三条件全满足才进：① 影响项目方向或边界；② ≥2 合理候选；③ 一时定不了。
|
||||
不满足的：就地小权衡直接进登记表一行，不写条目。
|
||||
- 本层标准两问：① 什么是本项目不可替代的核心承诺；② 什么内容扩张会稀释它。
|
||||
- 数量纪律：概念期问题通常 ≤3；开始堆第 4 问时先怀疑概念层没想清楚，重读定调记录而不是继续开新争议。
|
||||
- user_confirmed 后三件事：结论一句话迁入 design.md 对应节（留修订痕迹）；
|
||||
登记表加行（编号全项目连续，跨层引用写 D-__）；本条目改状态记 D 号保留不删。
|
||||
推翻时新增行挂旧行编号，旧行不删。
|
||||
|
||||
|
||||
## 六、自查参考
|
||||
- 卖点唯一吗？念头句立得住吗？
|
||||
- 随便挑一个后续设计问题，锚点六项之一能当裁判吗？
|
||||
- "不是什么"表封死了最可能的误会方向吗？
|
||||
- 张力每条都两端有代价吗？
|
||||
|
||||
## 七、红线（只有三条）
|
||||
1. 不冒充用户决定：用户没说的方向标"待确认"，正文不写死。
|
||||
2. 不越层：出现具体数值、按键、界面即删。
|
||||
3. 不凑数：章节对项目有意义但信息不足时，记录已确定内容与待补问题；章节对项目无意义时，直接省略。
|
||||
- 是否能理解玩家做什么、获得什么体验，以及主要吸引力。
|
||||
- 内容是否符合已有意图和约束，关键方向是否存在矛盾或缺口。
|
||||
- 是否为了填模板而编造内容、重复表述，或把尚未确定的方向写成定论。
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
---
|
||||
name: game-gdd-system-doc
|
||||
description: 写单个系统的设计文档（Sxx）时的总纲——通用纪律、十二类常见内容、
|
||||
红线与分析文档格式。每类系统的专属写法与模板在 modules/system-types/ 下对应目录的 SKILL.md
|
||||
红线与分析参考。每类系统的专属写法与模板在 modules/system-types/ 下对应目录的 SKILL.md
|
||||
与对应模块的模板.md 里，按需取用。
|
||||
---
|
||||
|
||||
@@ -19,7 +19,7 @@ description: 写单个系统的设计文档（Sxx）时的总纲——通用纪
|
||||
## 一、这一层的判断立场
|
||||
你是写单个系统的策划。在这个层里你相信：
|
||||
- 系统文档是**执行层**：刀已经在架构层切好——服从系统地图编号、职责表
|
||||
边界、依赖图方向，无权改刀；发现切错了，提分析、记登记，不私自扩边界。
|
||||
边界、依赖图方向，无权改刀；发现切错了，说明问题并提出调整建议，不私自扩边界。
|
||||
- 一个系统文档的成败在**边界节**："不负责什么、移交给谁"那几行是
|
||||
防返工价值最高的几行。
|
||||
- 接口纪律：引用具名系统与具名数据，禁泛称；别家主数据只引 ID 不复制。
|
||||
@@ -63,7 +63,7 @@ description: 写单个系统的设计文档（Sxx）时的总纲——通用纪
|
||||
2 支撑体验：对应顶层目标第__条、调性原则第__条。
|
||||
3 进入与退出：按本系统实际存在的入口、退出和恢复路径记录。
|
||||
4 玩家行动：记录本系统实际存在的具名动词组；编排类写"安排"动词，活动类写"操作"动词。
|
||||
5 取舍表：决策/立即收益/延迟收益/主要代价；挂顶层张力编号。
|
||||
5 取舍表：决策/立即收益/延迟收益/主要代价；需要追溯时引用顶层相关取舍的内容或章节。
|
||||
6 状态与规则：对象-状态-转换-异常，全部枚举表达，不许整段散文。
|
||||
7 数值与数据交接：列数据类别名 + 设计侧定性约束；字段定义归 TDD。
|
||||
8 反馈：记录本系统关键结果的可理解反馈；存在失败时说明原因和恢复路径。
|
||||
@@ -72,24 +72,10 @@ description: 写单个系统的设计文档（Sxx）时的总纲——通用纪
|
||||
11 边界与非目标：参考该类型系统写法的“三不”说明边界；建议说明字段与数值的交接边界。
|
||||
12 开放问题：结构级才留；手感数值类标"待原型验证"。
|
||||
|
||||
## 五、分析文档（全局一份，按层分节）
|
||||
## 五、分析参考
|
||||
|
||||
**全局共用 `project/analysis.md`**：论证按发生层归节，决定登记表全项目共用，
|
||||
跨层引用查这里。模板与例子：资源 `templates/analysis.md`、
|
||||
`templates/stardew-analysis.md`。已决论证与登记写入分析文档，
|
||||
灵感池、代决、待原型等活队列写入决策台账。
|
||||
|
||||
- 条目格式：`## 问题：<一句话>` ＋ 状态（agent_proposal / user_confirmed /
|
||||
superseded，登记 D-__）＋ 广度分析（牵动面＋候选 ≥2）＋ 深度分析
|
||||
（逐候选利弊依据，必须引 T 原则/锚点/张力编号，写不出依据的偏好不进分析）
|
||||
＋ 综合判断（建议取 __ 因为 __；推翻条件：__）。
|
||||
- 分诊三条件全满足才进：① 影响项目方向或边界；② ≥2 合理候选；③ 一时定不了。
|
||||
不满足的：就地小权衡直接进登记表一行，不写条目。
|
||||
- 本层标准问题：① 本系统与相邻系统的边界在哪；② 本系统内部哪个规则影响顶层取舍。条目标系统号（如 S06）。
|
||||
- 数量纪律：按需；每系统通常 0~1 条，超了先回读架构职责表。
|
||||
- user_confirmed 后三件事：结论一句话迁入 design.md 对应节（留修订痕迹）；
|
||||
登记表加行（编号全项目连续，跨层引用写 D-__）；本条目改状态记 D 号保留不删。
|
||||
推翻时新增行挂旧行编号，旧行不删。
|
||||
可关注本系统与相邻系统的边界，以及影响玩家选择的关键规则。
|
||||
按需参考 `templates/analysis.md` 和 `templates/stardew-analysis.md`。
|
||||
|
||||
|
||||
## 六、自查参考
|
||||
@@ -101,6 +87,6 @@ description: 写单个系统的设计文档（Sxx）时的总纲——通用纪
|
||||
|
||||
## 七、红线（只有三条）
|
||||
1. 不冒充用户决定：用户没说的方向标"待确认"，正文不写死。
|
||||
2. 不越层：不翻架构的案（要改走分析文档+登记表），不写字段数值（归 TDD），
|
||||
2. 不越层：架构需要调整时先说明影响，不写字段数值（归 TDD），
|
||||
不替别的系统定规则。
|
||||
3. 不凑数：写不出"删了塌什么"的系统直接删除；章节对项目有意义但信息不足时，记录已确定内容与待补问题。
|
||||
|
||||
@@ -49,13 +49,15 @@ GDD 是设计真源（给人看、给迭代看）；TDD 是构建真源（给施
|
||||
|---|---|---|
|
||||
| 系统范围表 + P0 清单 + 主数据归属规则 | 架构层 | 三件共用（拆表与拆模块依据） |
|
||||
| 各系统「数值与数据交接」节 + 定性约束 | 系统文档 | 数据侧（直接订单） |
|
||||
| 定调记录（参照/滑杆/T 原则）+ 身份基调 | 概念层 | 美术圣经（视觉翻译源头） |
|
||||
| 核心体验、情绪基调、风格及相关约束 | 概念层相关内容或章节 | 美术圣经（视觉设计依据） |
|
||||
| 可复用能力 | 能力库 | 程序侧+美术圣经（带版本与实例化参数） |
|
||||
|
||||
TDD 不回头改 GDD：发现 GDD 没写清楚的点，走「开放问题回执」——该问用户
|
||||
的升级决策卡，该代决的记台账（带理由和推翻条件），结论回写对应层，TDD 只
|
||||
登记去向。顾问期（开发阶段）同一出口：程序美术卡点、成品与文档偏差，都从
|
||||
回执进、修订出（v{N+1}）。
|
||||
TDD 不擅自改 GDD：发现 GDD 没写清楚的产品取舍，向用户确认并同步 GDD；
|
||||
技术实现中的规格、参数和默认值直接写完整在对应 TDD 正文。重要取舍可按需
|
||||
记录分析，但外部决策台账不是施工信息来源。尚未解决的问题记入对应分册的
|
||||
待办，写明问题、影响和下一步；解决后补齐正文并关闭待办。顾问期（开发阶段）
|
||||
遇到程序美术卡点或成品与文档偏差，也按此更新对应文档版本（v{N+1}）。
|
||||
影响当前实现的关键问题未解决时，不宣称该范围的 TDD 已完备。
|
||||
|
||||
## 三、三大件与开工顺序
|
||||
|
||||
@@ -73,7 +75,7 @@ GDD 喂的（系统文档交接节就是订单）；程序侧的加载与验证
|
||||
## 四、怎么写（总纲级；细节在各分册）
|
||||
|
||||
1. 数据侧：总清单拆表 → ID 与字段字典 → 公共条件表 → 建表顺序（物品表
|
||||
起步）→ 表结构契约（程序签名）→ 数值填充（代决+台账）→ 验收七查。
|
||||
起步）→ 表结构契约（程序签名）→ 数值填充（完整值与默认值）→ 验收七查。
|
||||
2. 程序侧：系统实现总览（每系统一段话写死怎么做）→ 技术选型与可复用能力引用
|
||||
→ 场景与镜头 → 输入与操作 → 音频 → 验证方式与性能预算。
|
||||
3. 美术圣经：视觉锚（从概念层定调翻译）→ 素材规格契约逐素材一行 →
|
||||
@@ -90,9 +92,9 @@ GDD 喂的（系统文档交接节就是订单）；程序侧的加载与验证
|
||||
## 六、红线（只有四条）
|
||||
|
||||
1. **收编必带版本锁**：从 GDD 收编的任何内容标注"基于系统文档@v{N}"；
|
||||
无锁收编=违规（双源漂移之源）。TDD 不产生设计观点，只汇集与落实施工。
|
||||
无锁收编=违规（双源漂移之源）。TDD 不擅自新增产品设计，只汇集与落实施工。
|
||||
2. 引用必带版本：可复用能力引用必须记录版本与实例化参数，选型时与执行时用的一致性靠此保证。
|
||||
3. 不越权拍板：产品级取舍回 GDD 层走决策流程；TDD 只做技术代决且记台账。
|
||||
3. 不越权拍板：产品级取舍由用户确认并同步 GDD；技术实现的完整结论写在 TDD，重要取舍按需记分析。
|
||||
4. 表里不写散文：单元格只有数据和枚举；规则写在契约文档，不写在表里。
|
||||
|
||||
|
||||
@@ -104,7 +106,7 @@ GDD 喂的（系统文档交接节就是订单）；程序侧的加载与验证
|
||||
|
||||
## A2 顶层设计分册（简介）
|
||||
|
||||
本分册说明顶层循环、资源流、节奏、取舍、范围和验证标准。完整内容请阅读 `resources/skills/top_design.md`；顶层设计模板请阅读 `resources/templates/top-design.md`。
|
||||
本分册说明游玩过程、关键规则与反馈、资源与进展、选择后果、版本范围和验证计划。完整内容请阅读 `resources/skills/top_design.md`；顶层设计模板请阅读 `resources/templates/top-design.md`。
|
||||
|
||||
## A3 系统架构分册（简介）
|
||||
|
||||
|
||||
@@ -1,194 +1,43 @@
|
||||
## A2 顶层设计分册（game-gdd-top-design）
|
||||
|
||||
---
|
||||
name: game-gdd-top-design
|
||||
description: 写游戏策划案（GDD）顶层设计时使用。在概念层定稿之后，
|
||||
回答"玩家为什么一直玩"——把概念变成可玩的时间结构（循环/资源/取舍/节奏），
|
||||
并向架构层交付系统范围。配套：templates/top-design.md、templates/analysis.md（全局一份）、
|
||||
exemplars/stardew-top-design.md、templates/stardew-analysis.md（全局一份）。
|
||||
---
|
||||
|
||||
# 顶层设计写法（策划 · 顶层设计分册）
|
||||
|
||||
> 本文件是顶层设计唯一承载写作流程的教学件。
|
||||
> 模板与例子文件保持纯净：不含任何步骤、检验提示与标记。
|
||||
产物：`project/01_top_design/design.md`。
|
||||
参考资源：`templates/top-design.md`、`exemplars/stardew-top-design.md`；全局分析文档的模板与样例：`templates/analysis.md`、`templates/stardew-analysis.md`。
|
||||
|
||||
## 〇、结构适配原则
|
||||
## 判断立场
|
||||
|
||||
根据游戏类型、项目规模、用户要求和概念层定稿选取本分册的适用内容，同类项可合并；复杂项目可以拆分补充，简单项目可以压缩为最小可用规格。
|
||||
将概念展开为可以理解的游玩过程，说明主要行动、关键规则、反馈与变化，明确当前范围及需要验证的设计问题，为系统划分提供依据。
|
||||
|
||||
## 一、这一层的判断立场
|
||||
你是资深游戏策划，正在写全 GDD 最重要的一份文档——概念说"凭什么成立"，
|
||||
顶层说"好玩在哪"。核心循环无趣，后面写再多系统也救不回来。在这个层里你相信：
|
||||
- 循环优先：先把大循环、小循环、最小体验单位三层跑通，再谈其他一切。
|
||||
- 用玩家的手写，不用系统的嘴写：写"玩家在做什么、在想什么"，
|
||||
不写"系统提供了什么功能"。
|
||||
- 每个时间段的痛苦和甜都要有来处：取舍表接概念层的张力，节奏接情绪摆动。
|
||||
- 资源守恒直觉：每种资源必问来源、储存、消耗——无来源是白给，
|
||||
无消耗是废物，环环相扣成套利。
|
||||
- 你不替概念层翻案（张力与定稿已定），也不替架构层拆系统（只划边界）。
|
||||
从玩家行为说明玩法，结合必要的系统功能解释结果。设计应服务于已确定的核心体验，不把自己的建议写成用户已经作出的决定。
|
||||
|
||||
## 二、动笔前
|
||||
1. 概念层 design.md 已定稿可用——顶层定位与取舍表直接从它长出来。
|
||||
2. 读取 exemplars/stardew-top-design.md 了解内容组织方式，
|
||||
往 templates/top-design.md 里填。
|
||||
3. 把概念层已确认的核心张力作为输入；存在对应取舍时再挂上编号。
|
||||
## 动笔前
|
||||
|
||||
## 三、顶层设计的组织维度：写什么、为什么、怎么咬合
|
||||
结合已获批的 `project/00_concept/design.md`、已有对话和项目资料开展设计，模板与样例按需参考。发现概念与新的约束冲突时，说明影响并讨论相关决定；不因套用样例自行改变方向。
|
||||
|
||||
顶层文档回答四个问题：
|
||||
**玩家在玩什么（1~9）→ 玩家面对什么选择与后果（10~11）→
|
||||
交给架构什么（12~14）→ 没想清什么、定了什么（15~16）。**
|
||||
## 内容组织
|
||||
|
||||
第 1 节承概念定稿开篇，第 16 节给架构硬约束收口，首尾呼应；
|
||||
中段三层循环互检，资源流从底下供血。
|
||||
根据项目实际玩法选择组织方式，同类内容可以合并，复杂部分可以拆分。不适用的内容省略，有意义但信息不足的内容保留已知信息与待补问题。
|
||||
|
||||
| # | 节 | 是什么 | 为什么写 | 和谁咬合 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | 顶层定位与规模锚点 | 承概念定稿 + 按需说明易混淆方向及排除理由 + "让玩家每天都在想"念头句 + 规模参数表（循环单位/段落/复杂度/长期主轴） | 循环单位定错全盘错；定位句防止顶层漂离概念 | 承概念层"概念定稿"；念头句是概念层玩家念头的时间维度版 |
|
||||
| 2 | 设计目标 | 几种回报、如何互相供给 | 回报并列=小游戏拼盘；互相供给才是循环 | 供给关系落到 4~5 的循环里 |
|
||||
| 3 | 核心推动力 | 按项目实际存在的即时、阶段或长期推动力组织 | 玩家"什么时候被什么推着走"的推动结构 | 与实际节奏结构对应 |
|
||||
| 4 | 大循环 | 跨较长时间的循环：文字箭头 + 核心循环图 | 长期留存的结构骨架 | 与 5、7 三层互检：大循环的每环应有小循环供血 |
|
||||
| 5 | 小循环 | 按项目实际存在的局内或短周期动词链组织 | 记录真正被玩到的循环 | 按实际循环层级互检 |
|
||||
| 6 | 资源流与输入输出 | 按项目实际存在的资源流、输入输出和反馈组织 | 说明循环中的实际供给与结果 | 与实际循环环节对应 |
|
||||
| 7 | 最小体验单位 | 多短一段玩法就能体现独有乐趣 + 反馈铁律 | 原型只做这一个单位——定原型规模 | 是 5 的最小切片；14 验证标准的试验对象 |
|
||||
| 8 | 核心活动流程 | 段落表：阶段/玩家行为/**设计目的** | "玩这个游戏的一天"的可复述剧本 | 设计目的列写不出的段=该删的段 |
|
||||
| 9 | 取舍表 | 决策/立即收益/延迟收益/主要代价 | 张力的具体化——玩家决策的路口 | **逐条对应概念层核心张力**（对上接口） |
|
||||
| 10 | 节奏结构 | 按项目实际存在的时间层级和情绪变化组织 | 说明玩法节奏如何变化 | 与实际推动力层级对应 |
|
||||
| 11 | 失败与回收 | 亏损定性 + 情况/结果表 | 失败的形态决定调性——"少拿"还是"毁掉" | 对齐概念层情绪基调的边界句 |
|
||||
| 12 | 系统范围 | 系统/顶层目的/**边界** 表 | 架构层接口：系统地图的种子 | **对下接口**：架构照此拆系统 |
|
||||
| 13 | 范围与非目标 | 最小完整版本清单 + 不做清单 | 立项交付物的边界 | 承概念层"不是什么"；给 14 提供验证范围 |
|
||||
| 14 | 验证标准 | 验证点/成功标准（行为判据） | "好玩"不可测，"玩家能复述循环"可测 | 判据对象=7 的最小体验单位 |
|
||||
| 15 | 开放问题 | 留给架构前必须想清的 | 显式债务清单 | 进分析文档或架构层开题 |
|
||||
| 16 | 顶层定稿 | 收口重锤 + 给架构的硬约束（必须__/不得__） | 检验全文档没写散；架构的紧箍咒 | 回环呼应 1；承概念层定稿的接力棒 |
|
||||
- **玩法目标**：说明主要行动和回报怎样实现概念中的体验，以及玩家为什么愿意推进。
|
||||
- **游玩过程与节奏**：说明玩家如何开始、行动、获得反馈，过程如何变化或结束。存在重复或长期推进结构时再展开循环及其联系，不预设循环层级、日历节奏或反馈层数。文字、表格和图按表达需要选用。
|
||||
- **资源与进展**：说明实际存在的资源、状态或进展怎样获得、变化、使用及受到限制。永久解锁、知识或经验等累积结果不必设计消耗环节。
|
||||
- **选择与后果**：说明重要选择的结果、收益和代价，以及它们怎样服务于目标体验。是否存在最优解取决于玩法，不要求所有选择等价。存在失败时，按场景说明损失、保留内容和恢复方式。
|
||||
- **系统范围与版本边界**：说明支撑玩法所需的能力、目的、边界及相互关系，明确当前版本包含和排除的内容。这里的系统范围供架构层拆分、合并，不要求每项对应一个独立系统。
|
||||
- **原型验证与开放问题**：说明需要判断什么，以及为此需要哪些内容、流程和游玩跨度。原型验证范围与当前完整版本范围分别写清；原型不固定为单个体验片段。根据问题采用试玩观察、完成情况、玩家反馈或指标，说明如何据此判断设计是否成立。尚未验证的预期不写成已验证结论。
|
||||
|
||||
咬合一图：
|
||||
关键约束写在相关内容中，无需结尾重复定稿。影响当前玩法成立或范围确定的问题应先解决，其他问题按影响保留给后续设计。
|
||||
|
||||
```
|
||||
概念层定稿（硬约束 + 张力）
|
||||
↓ 承接
|
||||
1 定位与规模锚点 ───张力落位───► 9 取舍表（逐条对应）
|
||||
↓ 展开
|
||||
2 设计目标 → 3 核心推动力 → 4 大循环 ⇄ 5 小循环 ⇄ 7 最小体验单位
|
||||
↓ 供血
|
||||
6 资源流与输入输出（防无来源/无消耗/套利）
|
||||
↓ 后果侧
|
||||
8 活动流程（段落表）→ 10 节奏结构 → 11 失败与回收
|
||||
↓ 交付
|
||||
12 系统范围（→架构系统地图的种子）＋ 13 范围 ＋ 14 验证标准
|
||||
↓ 收口
|
||||
15 开放问题 → 16 顶层定稿（给架构的硬约束）
|
||||
```
|
||||
## 展开深度
|
||||
|
||||
三个接口：**对上**承概念定稿、张力逐条变取舍表；**对内**三层循环互检
|
||||
（大⇄小⇄最小单位）+ 资源三段全；**对下**系统范围表喂架构的系统地图、
|
||||
顶层定稿当架构的紧箍咒、验证标准当原型试玩判据。
|
||||
写清理解和判断玩法所需的关键规则与参数，详细系统规格和实现方案留待后续展开。必要的数值、操作方式和界面信息可以保留。
|
||||
|
||||
## 四、怎么写（模板参考结构，建议按此组织）
|
||||
（本节是带写法要领的教学版；实际填写的纯净模板在 templates/top-design.md）
|
||||
## 分析参考
|
||||
|
||||
### 1. 顶层定位与规模锚点
|
||||
承接概念定稿说明核心定位；存在容易混淆的方向时，说明排除方向及理由，表述按项目需要组织。
|
||||
顶层设计让玩家每天都在想：
|
||||
> "__（玩家每天惦记的那件事）"
|
||||
规模锚点表：循环单位 / 段落构成 / 操作复杂度 / 经营复杂度 / 长期主轴排序。
|
||||
→ 循环单位先行，定错全盘错。复杂度行可内联参照与"不做"。
|
||||
可关注玩法节奏、行动回报、重要取舍及范围选择的依据。按需参考 `templates/analysis.md` 和 `templates/stardew-analysis.md`。
|
||||
|
||||
### 2. 设计目标
|
||||
玩家在 __ 循环中同时获得 __、__、__，三者互相供给：__。
|
||||
→ 检验：砍掉任何一种回报，另外两种是否受伤。
|
||||
## 交付检查
|
||||
|
||||
### 3. 核心推动力
|
||||
- 动机主次：__。
|
||||
- 即时推动 __；日程推动 __；季节推动 __；长期推动 __。
|
||||
→ 只展开项目实际存在的时间层级；不存在的层级不设字段。
|
||||
|
||||
### 4. 大循环
|
||||
**__ → __ → __ → __ → 回到 __。**（附核心循环图）
|
||||
→ 检验：断掉任何一环，后面是否塌；每一环应有对应小循环供血。
|
||||
|
||||
### 5. 小循环（按项目实际数量）
|
||||
**__循环**：__ → __ → __ → __ → __。
|
||||
→ 必须具名（"农务循环"不是"资源循环"）；动词链完整到可以直接照做。
|
||||
|
||||
### 6. 资源流与输入输出
|
||||
（资源流图：每种核心资源 来源 → 储存 → 消耗 三段全）
|
||||
主要输入 __；主要输出 __；按项目需要记录反馈层级。
|
||||
→ 三问：这资源哪来的？存在哪？花在哪去？答不出=资源设计未完成。
|
||||
|
||||
### 7. 最小体验单位
|
||||
__（多短一段玩法体现独有乐趣——原型只做这一个单位）。
|
||||
保留的玩家行动应有与玩法相称的可理解反馈；反馈形式和数量按项目决定。
|
||||
|
||||
### 8. 核心活动流程（段落表）
|
||||
| 阶段 | 玩家行为 | 设计目的 |
|
||||
→ 设计目的列必填；写不出目的的段落删掉。这份表要能让陌生人复述
|
||||
"玩这个游戏的一天"。
|
||||
|
||||
### 9. 取舍表
|
||||
| 决策 | 立即收益 | 延迟收益 | 主要代价 |
|
||||
→ 每行挂概念层张力编号；避免唯一最优解；不同选择应产生不同但都合理的玩法方式。
|
||||
|
||||
### 10. 节奏结构
|
||||
日内 __ → 周内 __ → 季节/章节 __ → 长期 __。
|
||||
整体情绪在"__"与"__"之间摆动（恢复来源 __；变化来源 __）。
|
||||
|
||||
### 11. 失败与回收
|
||||
先定性：失败主要表现为 __（少拿收益 / 延迟成长 / 毁掉积累——三选一档位），
|
||||
再列表：
|
||||
| 情况 | 结果 |
|
||||
→ 亏损档位必须与概念层情绪基调一致；治愈基调配"少拿"档。
|
||||
|
||||
### 12. 系统范围（架构层接口）
|
||||
| 系统 | 顶层目的 | 边界（本层不做什么） |
|
||||
→ 只写目的与边界，不写系统内部规则；每行将来对应架构层一个 Sxx。
|
||||
|
||||
### 13. 范围与非目标
|
||||
最小完整版本包含：__。不做清单：__。
|
||||
|
||||
### 14. 验证标准
|
||||
| 验证点 | 成功标准 |
|
||||
→ 成功标准必须是行为判据（"玩家能复述__""玩家出现__行为"），
|
||||
"感觉好玩"不算。
|
||||
|
||||
### 15. 开放问题
|
||||
→ 逐条列出；值得跨轮保留的进分析文档，其余留待架构层开题。
|
||||
|
||||
### 16. 顶层定稿（收口重锤）
|
||||
顶层当前定稿为：__（循环单位、核心结构、关键档位一句话说全）。
|
||||
后续架构必须围绕 __ 拆系统；不得 __。
|
||||
|
||||
若某节对本项目没意义，直接省略。
|
||||
|
||||
## 五、分析文档（全局一份，按层分节）
|
||||
|
||||
**全局共用 `project/analysis.md`**：论证按发生层归节，决定登记表全项目共用，
|
||||
跨层引用查这里。模板与例子：资源 `templates/analysis.md`、
|
||||
`templates/stardew-analysis.md`。已决论证与登记写入分析文档，
|
||||
灵感池、代决、待原型等活队列写入决策台账。
|
||||
|
||||
- 条目格式：`## 问题：<一句话>` ＋ 状态（agent_proposal / user_confirmed /
|
||||
superseded，登记 D-__）＋ 广度分析（牵动面＋候选 ≥2）＋ 深度分析
|
||||
（逐候选利弊依据，必须引 T 原则/锚点/张力编号，写不出依据的偏好不进分析）
|
||||
＋ 综合判断（建议取 __ 因为 __；推翻条件：__）。
|
||||
- 分诊三条件全满足才进：① 影响项目方向或边界；② ≥2 合理候选；③ 一时定不了。
|
||||
不满足的：就地小权衡直接进登记表一行，不写条目。
|
||||
- 本层标准两问：① 一天/一局怎样形成清楚但不拖沓的循环；② 风险、收益与长期成长怎样互相支撑。
|
||||
- 数量纪律：顶层期问题通常 ≤5（结构性争议天然更多）；堆问题时先回读第 1 节定位句。
|
||||
- user_confirmed 后三件事：结论一句话迁入 design.md 对应节（留修订痕迹）；
|
||||
登记表加行（编号全项目连续，跨层引用写 D-__）；本条目改状态记 D 号保留不删。
|
||||
推翻时新增行挂旧行编号，旧行不删。
|
||||
|
||||
|
||||
## 六、自查参考
|
||||
- 三层循环互检了吗：大循环每环有小循环供血？最小单位切得出来？
|
||||
- 概念层张力每条都在取舍表有对应行吗？
|
||||
- 每种资源三段全吗（来源/储存/消耗）？
|
||||
- 验证标准是行为判据吗，还是写了"好玩"？
|
||||
- 架构层拿到系统范围表能直接开工吗——有没有该划没划的系统？
|
||||
- 失败档位和概念层基调一致吗？
|
||||
|
||||
## 七、红线（只有三条）
|
||||
1. 不冒充用户决定：用户没说的方向标"待确认"，正文不写死。
|
||||
2. 不越层：向上不翻概念层的案，向下不写系统内部规则与具体数值。
|
||||
3. 不凑数：章节对项目有意义但信息不足时，记录已确定内容与待补问题；章节对项目无意义时，直接省略。
|
||||
- 能否理解玩家实际怎样玩，行动怎样产生反馈和后续变化。
|
||||
- 关键规则、资源或进展、选择与后果是否符合核心体验，是否存在矛盾或缺口。
|
||||
- 当前版本范围是否明确，是否足以让架构层判断所需能力及其关系。
|
||||
- 验证是否针对真实的设计问题，范围与方法是否足以支持判断。
|
||||
- 是否为了填模板编造循环、资源或取舍，或把未确定、未验证的内容写成定论。
|
||||
|
||||
@@ -1,41 +1,11 @@
|
||||
### C1 模板_分析.md（全局一份；→ templates/analysis.md）
|
||||
|
||||
# 分析：《游戏名》
|
||||
|
||||
> **全局唯一一份分析文档**：论证按发生层归节；决定登记表全项目共用，跨层引用只查这里。
|
||||
> 论证按发生层归节；决定登记表全项目只此一张，跨层引用只查这里。
|
||||
> 状态池（灵感池/代决/待原型等"活的"队列）在决策台账，不放本文件——本文件管已决的档案。
|
||||
> 仅记录值得跨轮保留的重要问题；普通讨论、临时灵感和完整对话不写入。策划提案不等于用户确认。
|
||||
按需记录影响后续设计的重要取舍。可按问题或主题组织，简单问题几句话即可，复杂问题再展开比较；不必预建各阶段的空章节。
|
||||
|
||||
## 概念期问题（通常 ≤3 条）
|
||||
下面仅是条目的参考写法，可合并或省略不需要的部分：
|
||||
|
||||
## 问题：__（一句话）
|
||||
状态：agent_proposal / user_confirmed / superseded（登记 D-__）
|
||||
- 广度分析：牵动面（波及哪些锚点/张力/节）＋ 候选方向（≥2）
|
||||
- 深度分析：逐候选 利/弊/依据（必须引定调记录 T 原则、锚点、张力编号或参照资料，写不出依据的偏好不进分析）
|
||||
- 综合判断：建议取 __，因为 __。推翻条件：__。
|
||||
## 问题：__
|
||||
|
||||
## 顶层期问题（通常 ≤5 条）
|
||||
背景与主要依据：__。
|
||||
|
||||
（同上格式）
|
||||
|
||||
## 架构期问题
|
||||
|
||||
（同上格式；本层不写独立分析文档，结构争议全归此处）
|
||||
|
||||
## 系统期问题（按系统号分条，如 S06）
|
||||
|
||||
（同上格式）
|
||||
|
||||
## 技术文档期问题
|
||||
|
||||
（同上格式；复用能力选型分歧、表结构二义等）
|
||||
|
||||
## 全局决定登记表
|
||||
|
||||
| D# | 决定 | 层 | 权威 | 依据 | 推翻条件 | 状态 |
|
||||
|---|---|---|---|---|---|---|
|
||||
| D-01 | __ | 概念 | user / agent（代决带理由） | 本文件问题__ / T__ | __ | 已确认/已推翻/待原型 |
|
||||
|
||||
- 编号全项目连续；跨层引用直接写"D-__"；推翻时新增行挂旧行编号，旧行不删。
|
||||
- 就地小权衡（不满足分诊三条件的）直接登记一行，不写问题条目。
|
||||
当前结论或建议：__。尚未确定的事项及下一步：__。
|
||||
|
||||
+5
-3
@@ -5,7 +5,7 @@
|
||||
# 系统架构：《游戏名》
|
||||
|
||||
## 架构定位与目标
|
||||
本阶段确定"哪些系统支撑一轮玩法"，不展开单系统内部规则。
|
||||
本阶段确定哪些系统支撑已确定的玩法与版本范围，不展开单系统内部规则。
|
||||
划分原则：__。
|
||||
|
||||
一句话架构：
|
||||
@@ -66,9 +66,9 @@ flowchart LR
|
||||
- 系统之间通过稳定 ID 关联。
|
||||
- 任何系统不复制另一系统的主数据。
|
||||
|
||||
## 核心循环覆盖检查
|
||||
## 玩法覆盖检查
|
||||
|
||||
| 顶层循环环节 | 认领系统 |
|
||||
| 顶层玩法环节或关键规则 | 负责或协作系统 |
|
||||
|---|---|
|
||||
| __ | __ |
|
||||
|
||||
@@ -80,6 +80,8 @@ flowchart LR
|
||||
| 03_systems/S02__/ | __ |
|
||||
|
||||
## MVP 最小闭环
|
||||
依据顶层版本范围与验证计划，记录最先实现的完整可玩流程，可为线性推进或循环。
|
||||
|
||||
1. __
|
||||
2. __
|
||||
3. __
|
||||
|
||||
+10
-45
@@ -1,58 +1,23 @@
|
||||
### C1 模板_概念设计.md（→ templates/concept-design.md）
|
||||
|
||||
本模板是参考结构，不是固定清单。填写前按项目类型、规模和用户要求筛选章节与字段；同类内容可合并，若某节对项目没有实际意义则删除，复杂项目可增加必要内容。表格和列表中的示例项可按实际内容扩展，不代表数量上限。
|
||||
|
||||
# 概念设计：《游戏名》
|
||||
|
||||
## 一句话概念
|
||||
《__》是一款 __：玩家通过 __，把 __ 逐步 __。
|
||||
以下为参考结构，可按项目需要合并、拆分或省略。提示问题用于帮助组织内容，不要求逐项填写。
|
||||
|
||||
## 定调与设计锚点
|
||||
## 游戏概念
|
||||
|
||||
### 定调记录（全项目调性真源，级联决策的依据库）
|
||||
- 参照选择：以《__》为主（__, 学 __）；不参考 __。
|
||||
- 调性滑杆：压力感 __ / 战斗比重 __ / 管理深度 __ / 叙事比重 __ / 节奏 __。
|
||||
- 调性锚（按项目需要逐条具名，下游开放问题按需从这里级联）：
|
||||
T__ __。
|
||||
游戏是什么，玩家主要做什么，吸引力在哪里？
|
||||
|
||||
### 设计锚点（六仲裁位）
|
||||
- 核心幻想：__。
|
||||
玩家念头："__"
|
||||
- 目标体验：__。
|
||||
- 玩家动机（按项目实际存在的时间尺度填写）：__。
|
||||
- 核心循环：__ → __ → __ → __ → 回到 __。
|
||||
- 跑偏风险：__。
|
||||
- 非目标：__（详见《不是什么》）。
|
||||
## 体验与玩法
|
||||
|
||||
## 玩家身份与基调
|
||||
- 玩家身份：__。
|
||||
- 情绪基调：__；可以 __，不可以 __。
|
||||
玩家在什么情境下获得什么感受？哪些行动、反馈或目标推动游玩？存在重要取舍时，选择及代价是什么？
|
||||
|
||||
## 风格与世界观
|
||||
世界观为 __ 服务；叙事通过 __ 展开。
|
||||
## 身份、基调与世界观
|
||||
|
||||
哪些身份、情绪基调、风格或世界规则有助于理解游戏？有参照时，具体借鉴什么？
|
||||
|
||||
## 目标玩家与情境
|
||||
- 目标玩家：与 __ 的受众重合；吸收 __ 的 __ 需求；但不会变成它，因为 __。
|
||||
- 适合情境：__。
|
||||
- 体验门槛：需要理解 __；不应要求 __。
|
||||
|
||||
## 不是什么
|
||||
| 不是 | 因为 |
|
||||
|---|---|
|
||||
| __ | __ |
|
||||
|
||||
## 核心张力
|
||||
- __ 有限，但 __。
|
||||
- __ vs __。
|
||||
面向哪些玩家，适合怎样的游玩情境，体验门槛是什么？
|
||||
|
||||
## 边界与约束
|
||||
- 概念层只定 __；__ 留给顶层及以后。
|
||||
- 规模与回流：__。
|
||||
- 参照声明：__。
|
||||
|
||||
## 概念定稿
|
||||
《__》的核心不是 __，而是：
|
||||
> __
|
||||
|
||||
交给下一层的约束：__。
|
||||
（调性已在第 2 节定死；顶层及以下一切开放问题先回定调记录级联。）
|
||||
有哪些容易混淆的方向和排除理由？哪些范围扩张会影响核心体验？团队与项目有哪些实际限制，后续设计需要遵守什么？
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user