Compare commits

..

10 Commits

Author SHA1 Message Date
lhk229 b6847a3232 简化系统层规则与类型模板
Project CI / AI game creator shell Rust crates (pull_request) Successful in 1m22s
Project CI / AI game creator shell Rust smoke (pull_request) Successful in 1m57s
Project CI / Backend tests (pull_request) Successful in 3m56s
Project CI / Frontend tests (pull_request) Successful in 2m13s
Project CI / Native shell tests (pull_request) Successful in 5m53s
Project CI / AI game creator shell Rust lane 2/2 (pull_request) Successful in 9m9s
Project CI / AI game creator shell web tests (pull_request) Successful in 1m29s
Project CI / Repository checks (pull_request) Successful in 1m56s
Project CI / AI game creator shell Rust lane 1/2 (pull_request) Successful in 10m14s
精简系统总纲,按实际行为、协作与结果组织内容,取消固定章节和填写纪律
简化十二类系统规则与模板,保留领域问题、已定参数和架构职责,移除预设玩法
修正战斗样例的原型范围、撤退与倒下后果,并同步 TDD 来源版本和规则
取消 TDD 对固定交接章节的依赖,保留当前施工范围的自足性要求
同步策划技术方案与共享决策记录
2026-09-27 17:23:39 +00:00
lhk229 35c0859ae8 简化架构层规则与下游文档衔接
按职责与协作重写架构规则、模板和样例,取消固定数量、P0 必需性与无环硬要求
明确权威数据归属及系统文档映射,区分策划文档目录与实现代码组织
同步系统规则、类型资料与 TDD 引用,保留当前施工范围的自足性要求
对齐星露谷首个原型、速览卡与 TDD 样例,列明基础采集、跨日结算和验算缺口
更新策划技术方案与共享决策记录
2026-09-27 16:57:48 +00:00
lhk229 89a901e329 简化顶层设计规则与架构衔接
Project CI / AI game creator shell Rust crates (pull_request) Successful in 1m31s
Project CI / AI game creator shell Rust smoke (pull_request) Successful in 2m2s
Project CI / Backend tests (pull_request) Successful in 3m57s
Project CI / Frontend tests (pull_request) Successful in 2m6s
Project CI / Native shell tests (pull_request) Successful in 5m59s
Project CI / AI game creator shell Rust lane 2/2 (pull_request) Successful in 8m53s
Project CI / AI game creator shell web tests (pull_request) Successful in 1m25s
Project CI / Repository checks (pull_request) Successful in 1m53s
Project CI / AI game creator shell Rust lane 1/2 (pull_request) Successful in 9m39s
精简顶层写作规则与模板,取消固定循环层级、资源消耗链和失败档位要求
重组星露谷顶层样例,修正选择收益与损失描述并区分原型和完整版本范围
同步架构玩法覆盖检查、顶层阶段提示和TDD简介,保留施工完备要求
更新策划Agent技术文档和共享决策记录
2026-09-27 15:59:20 +00:00
lhk229 46024b5043 简化概念层写作规则与参考文档
取消概念层固定问询、字数、唯一卖点、六项锚点和调性级联要求
合并概念模板与样例中的重复内容,按项目需要组织体验和边界
同步顶层、系统、TDD及速览卡的内容引用,保留TDD自足性要求
更新策划Agent技术文档和共享决策记录
2026-09-27 15:12:34 +00:00
lhk229 8484a30d49 统一简化策划文档维护与技术决策登记
Project CI / AI game creator shell Rust crates (pull_request) Successful in 1m31s
Project CI / AI game creator shell Rust smoke (pull_request) Successful in 1m58s
Project CI / Backend tests (pull_request) Successful in 3m58s
Project CI / Frontend tests (pull_request) Successful in 2m11s
Project CI / Native shell tests (pull_request) Successful in 6m2s
Project CI / AI game creator shell web tests (pull_request) Successful in 1m31s
Project CI / Repository checks (pull_request) Successful in 2m0s
Project CI / AI game creator shell Rust lane 2/2 (pull_request) Successful in 9m40s
Project CI / AI game creator shell Rust lane 1/2 (pull_request) Successful in 10m17s
简化分析文档、决策台账、对话记录与速览卡的维护要求
清理阶段分册、模板和样例中的重复登记协议
简化技术决策记录,保留只凭TDD完成当前范围实现的要求
修正未决问题与施工完备性矛盾的样例并同步项目文档
2026-09-27 13:14:01 +00:00
lhk229 c6a0844b50 精简概念分册文件头与判断立场
删除元信息、重复标题和教学件说明,保留参考资源入口
精简判断立场,保留核心体验、具体表达与用户决定边界
同步技术方案并说明其余章节尚未调整
2026-09-27 12:52:29 +00:00
lhk229 c7ac4f3bab 简化策划智能体常驻提示词
删除修改后固定汇报和不确定内容分类要求
同步策划智能体技术方案中的简化说明
2026-09-27 12:40:50 +00:00
lhk229 155f0d316a 新增 external v1 游戏场景生成路由并迁移 AGC 美术包背景阶段 (#516)
Project CI / AI game creator shell Rust smoke (push) Successful in 1m50s
Project CI / AI game creator shell Rust crates (push) Successful in 1m15s
Project CI / Backend tests (push) Successful in 4m29s
Project CI / Native shell tests (push) Successful in 6m27s
Project CI / Frontend tests (push) Successful in 1m59s
Project CI / AI game creator shell Rust lane 2/2 (push) Successful in 9m12s
Project CI / AI game creator shell web tests (push) Successful in 1m33s
Project CI / AI game creator shell Rust lane 1/2 (push) Successful in 10m3s
Project CI / Repository checks (push) Successful in 2m1s
- api-server 新增 POST /api/external/v1/editor/scenes/generations,复用 editor:image-generate scope、幂等键和站内场景生图队列
- editor_project.rs 抽取站内与外部共用的场景生图 payload 构造函数,站内 handler 改为调用共享函数
- 同步更新 external v1 OpenAPI 契约与 MCP 派生排除标记,登记 docs/README.md 索引
- AGC 客户端美术包背景阶段改走新场景路由,stylePreset 固定 custom + customStyle 保留现有风格文案
- external_generation_state 快照与 recovery_scan 账本白名单支持新场景路由
- direct_runtime 背景资源识别同时兼容新场景路由与旧通用路由,新增旧路由回放测试
- 更新 genarrative-external-editor-api skill 参考文档
- 新增主规范、里程碑规范与实施计划三份 SDD 文档

Reviewed-on: #516
2026-09-27 18:39:01 +08:00
lhk229 6ed1fd26ed 修复 Linux 沙箱命令退出回收的偶发竞态
Project CI / AI game creator shell Rust crates (pull_request) Successful in 1m33s
Project CI / AI game creator shell Rust smoke (pull_request) Successful in 2m7s
Project CI / Backend tests (pull_request) Successful in 3m49s
Project CI / Frontend tests (pull_request) Successful in 1m53s
Project CI / Native shell tests (pull_request) Successful in 5m51s
Project CI / AI game creator shell Rust lane 2/2 (pull_request) Successful in 8m57s
Project CI / Repository checks (pull_request) Successful in 1m55s
Project CI / AI game creator shell Rust lane 1/2 (pull_request) Successful in 9m19s
Project CI / AI game creator shell web tests (pull_request) Successful in 1m24s
Project CI / AI game creator shell Rust crates (push) Successful in 1m30s
Project CI / AI game creator shell Rust smoke (push) Successful in 2m9s
Project CI / Backend tests (push) Successful in 4m49s
Project CI / Frontend tests (push) Successful in 2m9s
Project CI / Native shell tests (push) Successful in 6m54s
Project CI / AI game creator shell Rust lane 2/2 (push) Successful in 9m56s
Project CI / AI game creator shell Rust lane 1/2 (push) Successful in 10m14s
Project CI / Repository checks (push) Successful in 2m2s
Project CI / AI game creator shell web tests (push) Successful in 1m30s
统一正常退出、取消和超时的有界进程组退出确认,保留归属校验
提前记录启动身份,修补终态协议错误的清理及输出任务回收
补充确定性竞态回归并同步运行时规范和排障记忆
保持现有 CI 并行、分片和重试策略不变
2026-09-24 16:45:07 +00:00
lhk229 4912aa4df0 删除创作首页登录送泥点营销文案
Project CI / AI game creator shell Rust crates (pull_request) Successful in 1m34s
Project CI / AI game creator shell Rust smoke (pull_request) Successful in 2m14s
Project CI / Backend tests (pull_request) Successful in 3m51s
Project CI / AI game creator shell Rust lane 1/2 (pull_request) Failing after 6m40s
Project CI / Frontend tests (pull_request) Successful in 2m0s
Project CI / Native shell tests (pull_request) Successful in 5m52s
Project CI / Repository checks (pull_request) Successful in 2m8s
Project CI / AI game creator shell Rust lane 2/2 (pull_request) Successful in 8m50s
Project CI / AI game creator shell web tests (pull_request) Successful in 2m17s
删除 CreationLandingView hero 区“登录即送 100 泥点,可以免费制作 50 个素材”文案
删除 CreationLandingView.test.tsx 中对应的文案断言
清理 index.css 中已无调用方的 creation-landing__hero-benefit 样式
更正 decision-log 中已过期的“注册赠送固定为 100 泥点”决策记录,注明金额由线上钱包配置决定
2026-09-24 16:08:42 +00:00
90 changed files with 1790 additions and 4074 deletions
@@ -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:
+9 -21
View File
@@ -192,7 +192,7 @@ _Avoid_: mock 先行堆积、前后端各自发散、先做排行榜 UI
## 项目开发对话(DirectProject)
**DirectProject 专属聊天模块**:
AGC 普通项目聊天的独立容器,拥有 DirectProject 的聊天状态、运行态订阅、历史读取、待发消息队列的投影、附件和中止交互,并把聊天投影交给专属表现层渲染;它不承接 Supervisor、Design Agent 或 Planning V2 的运行态。
AGC 普通项目聊天的独立容器,拥有 DirectProject 的聊天状态、运行态订阅、历史读取、发送队列、附件和中止交互,并把聊天投影交给专属表现层渲染;它不承接 Supervisor、Design Agent 或 Planning V2 的运行态。
_Avoid_: 把 DirectProject 作为项目总控聊天的一个布尔分支、把四种 Agent 会话抽象成同一事实源
**项目工作台布局**:
@@ -208,32 +208,20 @@ Thread Manager 向订阅者推送的当前回合原始事件流,只服务运
_Avoid_: 进度通知、快照轮询、第二套历史
**逻辑回合**:
Thread Manager 拥有的一对回合边界(开始与结束),由放行动作开启、由这一轮的占用对象写出,不镜像 Codex 原生回合;界面忙碌态与回合结果只认它。
Thread Manager 拥有的一对回合边界(开始与结束),由接单动作开启、由这一轮的占用对象写出,不镜像 Codex 原生回合;界面忙碌态与回合结果只认它。
_Avoid_: Codex 原生回合、原生日志、进程生命周期
**待发消息队列**:
Thread Manager 按项目持有的待发用户消息序列,只支持按入队顺序追加与按身份移除,状态由运行态事件派生,不落盘、不构成第二份事实源。
_Avoid_: 前端本地队列、队列副本、待发消息的持久化记录
**接单**:
把一条用户消息交给宿主开始执行的动作,成立即表示这一轮已经存在;此后结果只由运行态事件回答。
_Avoid_: 发送成功、命令调用、接口返回
**待发消息**:
已经通过入队检查、等待被放行的用户消息;它在放行之前不是回合,不写用户条目、不产生回合事件。
_Avoid_: 回合、在途回合、草稿
**入队**:
把一条用户消息交给宿主的动作:宿主跑完入队检查后把它放进待发消息队列;入队成立只表示这条消息会按顺序被放行。
_Avoid_: 发送成功、已经开跑、回合成立
**入队失败**:
入队检查未通过(身份、形状、容量、权限、目录、参数、工程准备未就绪)时拒绝这次请求,只回一条可展示原因,不入队、不产生回合事件,也不写用户条目。
**拒单**:
接单成立之前拒绝这次请求(并发、权限、目录、参数、工程准备未就绪),只回一条可展示原因,不产生回合事件,也不写用户条目。
_Avoid_: 回合失败、执行失败、失败事件
**放行**:
Thread Manager 在一个回合收口之后把队首的待发消息送进回合:同一临界区里登记占用、落盘用户条目、发出逻辑回合开始事件并起整轮;放行之后的结果只由运行态事件回答。
_Avoid_: 前端放行、定时轮询、放行失败
**在途回合**:
界面本地已经入队、宿主还没有对应回合开始事件的那一小段状态。
_Avoid_: 运行中回合、乐观锁、前端发送队列
界面本地已经把这条用户消息发出去、宿主还没有对应回合开始事件的那一小段状态。
_Avoid_: 运行中回合、乐观锁、发送队列
**聊天投影**:
把项目对话历史条目与运行态事件转换成消息气泡和工具卡片的读取期转换;不持久化,也不构成事实源。
@@ -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 @@
当前阶段:顶层设计。明确玩家持续游玩的循环、资源流、节奏和系统范围。
当前阶段:顶层设计。明确游玩过程、关键规则与反馈、版本范围和验证计划,为系统划分提供依据。
@@ -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 挂新行,受影响文档节重写(本台账只记录,不代改)。
- 概念层变更定稿后:速览卡"决定状态与原型验证项"字段随本文件最新版同步。
- 体力与战斗是否共享资源:涉及探索压力和恢复规则,结合用户对战斗体验的要求确认,再更新相关系统设计。
- 背包使用格子还是重量限制:在确定存档和界面结构前确认,选择依据记录在分析文档。
- 战斗判定窗口的手感:通过矿井原型试玩观察是否易懂、是否拖慢探索,依据见分析文档“战斗判定窗口是否需要调整”。
- 天气权重是否合适:用前几天的游玩样本检查连续雨天或长期无雨的影响,再调整配置。
@@ -1,59 +1,58 @@
# 速览卡:《星露谷物语》金样项目
> 字段来源见每节尾注(概念层/定调记录/决策台账)。概念层变更定稿后本卡必须同步更新。
> 本卡概括当前游戏;仅在核心体验、范围、平台等概览内容变化时更新。具体规则和取舍依据见对应设计与分析文档。
## 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 系统(本例首期范围)
| 系统 | 最小功能 | 为什么必须有 | 验证方法 |
|---|---|---|---|
| 时间与日程 | 时钟/日终结算/季节天气 | 全局节拍器 | 一个游戏日全流程可完成并结算 |
| 体力与状态 | 单池体力/昏倒惩罚 | 一切取舍的成本源 | 玩家主动在体力耗尽前收手 |
| 农场经营 | 锄种浇收+加工队列 | 核心产出与规划场 | "买种→收获→出售"闭环成立 |
| 物品与制作 | item_id/背包/配方解锁 | 资源身份与转化 | 拾取/堆叠/制作全链无回翻 GDD |
| 经济与商店 | 基准价+价差+出货箱 | 投资回报换算 | 第 4 日现金流回正(前五日验算) |
| 时间与日程 | 时钟、天气、日终协调与跨日推进 | 组织日常活动 | 单日行动与多日状态持续一致 |
| 体力与状态 | 行动成本、休息恢复 | 支持日常计划与取舍 | 结合行动调整和玩家反馈判断压力 |
| 农场经营 | 耕种、浇水、生长与收获 | 核心产出与规划场 | 连续数日完成生长、收获与再投资 |
| 探索与地图 | 农场、小镇与基础采集区域 | 支持外出和活动选择 | 移动、出入口与资源点状态正确 |
| 采集与钓鱼 | 本期基础采集,钓鱼后续加入 | 提供农场外的资源来源 | 采集结果正确入账且不重复领取 |
| 物品与制作 | 本期物品身份、背包与工具使用 | 连接活动成果与投资 | 拾取、消耗及存读档结果一致 |
| 成长与技能 | 基础农务或采集成长 | 为后续活动提供目标 | 多日成果产生可理解的能力变化 |
| 经济与商店 | 买种、出售与基础投资 | 连接产出与后续投入 | 收益可用于下一轮活动,具体节奏待验算与试玩 |
## 10. 制作边界 ←概念层"不是什么"表
## 10. 制作边界 ←概念层「边界与约束」
不做:硬核生存(无饥饿/债务/死亡惩罚);效率至上的工厂经营;以战斗为核心的动作游戏;剧情驱动的任务链主线;多人竞争;无边界开放世界(区域小网络全步行可达)。
## 11. 创作者提示(先做与验证)←概念层"先做与验证"节
- 先做:第 1 日循环(买种→播种→浇灌→收获→出售→日终结算)+一个可进入的矿井遭遇。
## 11. 创作者提示(本例原型验证安排)
- 先做:单日农务与基础采集,继续数日覆盖作物生长、收获、出售、投资和基础成长,包含必要的 UI 与存读档。
- 暂不做:装备刷取、随机构筑、复杂剧情、节日全量、联机。
- 这样验证:测试者玩完第 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. 待原型验证项
- 矿井中的轻度战斗能否提供节奏变化,同时保持探索流畅;通过原型试玩观察判定是否易懂、战斗是否拖慢探索。
@@ -1,200 +1,94 @@
# 系统架构:《星露谷物语》
## 架构定位与目标
本阶段确定"哪些系统支撑一轮玩法",不展开单系统内部规则。
划分原则:将生活模拟 RPG 拆成职责清晰、可独立讨论的规则系统,同时保留少量跨系统入口,避免"每个功能都能互相调用"造成架构失控。系统划分服务于顶层循环:安排一天、执行活动、获得进展、投入成长、解锁新选择。
## 系统与职责
一句话架构:
> 玩家在有限的时间与体力下,通过农场、探索与社交三组活动系统产出资源与关系,经物品与经济系统转化为投资,由时间系统推进日终,把一天的成果变成下一天的选择。
架构承接顶层的农场生活体验:安排一天、执行活动、获得进展、投入成长,再形成后续计划。战斗服务于探索中的风险与节奏变化,不作为装备成长主轴。以下系统覆盖完整版本,首个原型只实现其中必要的能力。
变更记录:
- 2026-09-05:战斗与敌人系统定为伴生风险定位,深度刻意受限,不进入最小闭环核心链(依据:概念分析 D-03)。
## 系统地图
| 编号 | 系统 | 一句话职责 | 优先级 |
| 编号 | 系统 | 职责与权威维护的状态 | 首个原型范围 |
|---|---|---|---|
| S01 | 时间与日程 | 推进游戏时间、日期、季节、天气、营业时间、NPC 日程和日终结算 | P0 |
| S02 | 体力与状态 | 管理体力、负面状态、恢复、昏倒和行动成本 | P0 |
| S03 | 农场经营 | 管理土地、作物、畜牧、农场设施和生产状态 | P0 |
| S04 | 探索与地图 | 管理区域、出入口、可交互资源点、地图解锁和移动 | P0(基础) |
| S05 | 采集与钓鱼 | 管理野外采集、钓鱼活动、资源品质和获得物 | P1 |
| S06 | 战斗与敌人 | 管理矿区或危险区域中的战斗、伤害、敌人行为和战利品 | P1 |
| S07 | 物品、背包与制作 | 管理物品实例、堆叠、工具、装备、配方和制作队列 | P0 |
| S08 | 成长与技能 | 管理技能经验、等级、工具升级、职业选择和能力解锁 | P0(基础) |
| S09 | 经济与商店 | 管理货币、买卖、价格、商店库存、订单和资金流 | P0 |
| S10 | NPC 与关系 | 管理 NPC 日程、对话、好感度、礼物偏好和关系事件 | P1 |
| S11 | 任务与社区目标 | 管理任务状态、阶段目标、奖励、社区修复和区域解锁条件 | P1 |
| S12 | 事件与节日 | 管理季节事件、节日活动、条件触发和特殊奖励 | P1 |
| S01 | 时间与日程 | 时钟、日期、季节、天气,时间通知与日终流程协调 | 基础时间、天气与跨日推进 |
| S02 | 体力与状态 | 体力、恢复、昏倒和状态效果,处理活动提交的成本 | 农务与采集的行动成本、休息恢复 |
| S03 | 农场经营 | 土地、作物、畜牧、设施生产状态与生产规则 | 耕种、浇水、生长与收获 |
| S04 | 探索与地图 | 区域、出入口、角色位置、资源点位置与可用状态,执行移动和区域开放 | 农场、小镇与基础采集区域 |
| S05 | 采集与钓鱼 | 活动判定、获得物与品质规则 | 基础采集;钓鱼后续加入 |
| S06 | 战斗与敌人 | 战斗过程、敌人状态、伤害和战利品请求 | 后续矿井遭遇原型 |
| S07 | 物品、背包与制作 | 物品身份、实例、容器、配方、工具装备及通用制作队列 | 种子、工具、采集物和农产品的持有与使用 |
| S08 | 成长与技能 | 经验、等级、能力与配方解锁条件 | 基础农务或采集成长 |
| S09 | 经济与商店 | 货币、价格、交易、库存及营业条件 | 买种、出售与基础投资 |
| S10 | NPC 与关系 | NPC 日程内容与执行进度、对话、好感和关系事件 | 后续关系原型 |
| S11 | 任务与社区目标 | 任务状态、奖励、社区进度和区域解锁条件 | 后续社区目标原型 |
| S12 | 事件与节日 | 节日内容、触发条件、活动流程与完成状态 | 后续节日内容 |
支撑层(不拥有核心规则):
- 存档与进度系统:保存跨日、跨季节和跨阶段的持久状态。
- UI 与文本呈现层:展示状态、提供操作入口、呈现反馈与文本。
存档保存各系统的持久状态并按归属恢复;UI 与文本呈现展示结果、提供操作入口。它们需要实现规格,但不另行维护玩法规则,规格在 TDD 中展开。
P0 段:
容易混淆的边界:
| 系统 | 目的 | 输入 | 输出 | P0 原因 |
|---|---|---|---|---|
| S01 时间与日程 | 全局时钟与日终 | 各系统行动完成信号、日终触发 | 日期/季节/天气变化、日终结算、跨天 tick | 没有"一天",规划与取舍失去标尺 |
| S02 体力与状态 | 全局行动成本 | 各系统行动请求、食物与休息 | 体力变化、昏倒、状态效果 | 没有它,"想做的事多于做得到的"不成立 |
| S03 农场经营 | 核心产出与规划场 | 时间 tick、种子与工具、体力 | 作物畜产品、设施生产状态 | 概念核心承诺的载体 |
| S04 探索与地图 | 活动场景与空间约束 | 移动指令、区域解锁条件 | 位置、区域状态、资源点入口 | 没有空间结构,农/矿/镇一体失去意义 |
| S07 物品与制作 | 资源身份与转化 | 各系统获得物、配方请求 | 物品实例、制作结果 | 所有系统产出的公共语言 |
| S08 成长与技能 | 长期回报层 | 各活动经验提交 | 等级、能力与配方解锁 | 长期动机的最小载体 |
| S09 经济与商店 | 投资与回报换算 | 物品、金钱 | 价格、交易、库存 | 没有它,"变现 vs 投资"张力无载体 |
- S01 提供时钟与日期,S10 根据自身日程决定 NPC 的目标和行动,通过 S04 执行移动;S09 判断商店是否营业。时间系统不维护另一套居民日程或商店规则。
- S04 维护资源点的位置和是否仍可采集,S05 判定本次采集的结果;物品入账由 S07 处理,经验由 S08 处理。
- S03 管理农场设施的生产状态,S07 管理背包与通用制作。共用配方时引用同一配方定义,不各自复制材料与产出规则。
- S11 判断社区目标是否满足解锁条件,S04 维护实际开放的区域;S08 管理技能解锁,S07 据此判断配方或工具能否使用。
## 系统职责
## 协作与数据归属
| 系统 | 主要职责 | 不负责 → 移交谁 |
|---|---|---|
| S01 时间与日程 | 时间推进、日期、季节、天气、营业与日终 | 直接决定某项活动的奖励 → 各活动系统 |
| S02 体力与状态 | 行动消耗、恢复、昏倒、状态效果 | 农作物或敌人的具体配置 → S03/S06 |
| S03 农场经营 | 土地、作物、畜牧、设施生产 | 商店买卖规则和角色技能 → S09/S08 |
| S04 探索与地图 | 区域连接、进入条件、资源点位置、移动 | 具体掉落概率和战斗公式 → S05/S06 |
| S05 采集与钓鱼 | 采集和钓鱼行为、成功条件、获得物 | 物品价格和任务奖励 → S09/S11 |
| S06 战斗与敌人 | 战斗流程、敌人状态、伤害与战利品请求 | 角色长期成长和商店价格 → S08/S09 |
| S07 物品与制作 | 背包、物品、配方、制作与工具装备 | 物品最终经济价值的平衡目标 → S09 |
| S08 成长与技能 | 经验、等级、技能分支、能力解锁 | 单次行动的基础奖励 → 各活动系统 |
| S09 经济与商店 | 货币、交易、库存、订单、价格 | 任务剧情与 NPC 情感变化 → S10/S11 |
| S10 NPC 与关系 | 日程、互动、好感、关系事件 | 全局季节推进和商店库存 → S01/S09 |
| S11 任务与社区 | 目标、前置、奖励、社区进度和解锁 | NPC 的日常行为表现 → S10 |
| S12 事件与节日 | 周期事件、特殊流程和限定内容 | 常规日常行动的基础规则 → 各活动系统 |
以下表格描述行动处理和通知,不把所有关系混成同一种依赖箭头。
职责说明:
### S01 时间与日程系统
负责一天制的节奏规则:什么时候推进日期、哪些系统收到跨天 tick、日终结算何时发生。它不负责奖励结算,也不负责作物成长规则——只负责"什么时候"和"谁被通知"。
### S06 战斗与敌人系统
负责战斗内状态、敌人行为与战利品请求。它不直接修改商店价格或 NPC 好感,不负责角色长期成长;战利品只提交请求,由 S07 物品系统入账。定位是矿井探索的风险与节奏变化,不是成长主轴(D-03)。
### S07 物品、背包与制作系统
负责物品身份、容器、堆叠与配方队列。它是全项目的公共语言层——任何系统的产出都以 `item_id` 入账;它不负责物品的经济价值平衡,价格只由 S09 维护。
## 依赖与数据流
```mermaid
flowchart TD
S1[S01 时间与日程] --> S2[S02 体力与状态]
S1 --> S3[S03 农场经营]
S1 --> S4[S04 探索与地图]
S1 --> S10[S10 NPC 与关系]
S1 --> S12[S12 事件与节日]
S3 --> S7[S07 物品与制作]
S4 --> S5[S05 采集与钓鱼]
S4 --> S6[S06 战斗与敌人]
S5 --> S7
S6 --> S7
S7 --> S9[S09 经济与商店]
S7 --> S8[S08 成长与技能]
S8 --> S7
S10 --> S11[S11 任务与社区]
S12 -.读取日期季节.-> S1
UI[UI 与文本呈现] -.读取状态.-> S1
UI -.读取状态.-> S3
UI -.读取状态.-> S7
SAVE[存档与进度] -.订阅持久状态.-> S1
```
```mermaid
flowchart LR
T[时间/体力] --> ACT[玩家行动]
ACT --> GAIN[物品·金钱·经验·关系·任务进度]
GAIN --> INV[制作·交易·升级·解锁]
INV --> NEW[新的行动选择]
NEW --> ACT
```
主要状态:
- 全局状态:日期、季节、天气、当前时间、已解锁区域、社区进度。
- 玩家状态:位置、体力、生命、技能等级、工具、装备、背包和金钱。
- 场景状态:土地、作物成长、设施生产、资源点、敌人和宝箱。
- 社会状态:NPC 位置、关系值、已触发事件、任务阶段和节日参与状态。
主数据归属规则:
- 规则文档描述"如何计算"和"何时发生";数据表描述"有哪些对象"和"每个对象的配置"。
- 系统之间通过稳定 ID 关联(物品 ID、NPC ID、区域 ID、任务 ID、配方 ID)。
- 任何系统都不复制另一系统的主数据;任务只引用物品 ID,不重新定义物品价格。
## 核心循环覆盖检查
| 顶层循环环节 | 认领系统 |
| 行动或时机 | 协作与结果归属 |
|---|---|
| 查看天气、日程与目标 | S01、S11、S12、UI |
| 选择活动并移动 | S04、S02 |
| 农务与生产 | S03、S07、S02 |
| 采集、钓鱼与战斗 | S04、S05、S06、S07 |
| 出售、购买与投资 | S09、S07、S03 |
| 社交与委托 | S10、S11、S07 |
| 日终结算与保存 | S01、S12、存档、UI |
| 播种与农务 | S03 检查地块及行动条件,S07 检查种子或工具,S02 检查行动成本;确认可执行后更新各自状态。失败时不留下仅扣种子或体力的部分结果 |
| 采集 | S04 确认资源点可用,S05 判定获得物,S07 入账,S08 接收活动经验;成功后由 S04 更新资源点状态 |
| 出售与购买 | S09 校验营业、库存与价格,S07 校验物品和容器;交易成功时双方分别更新所拥有的状态,失败时保持原状态 |
| 成长与解锁 | 活动系统报告成果,S08 更新经验与能力;S07 等使用方读取解锁结果,不自行维护另一套技能进度 |
| 日终 | S01 停止当日行动并协调结算;S03 推进作物与生产、S09 结算出货、S08 结算成长,之后汇总反馈并保存。跨日通知让各系统准备次日状态 |
| 居民行动与节日 | S10、S12 读取 S01 的日期与时间,按各自规则决定活动;需要移动时交给 S04,不反过来推进全局时钟 |
## 目录映射
跨系统行动的提交方式、失败处理和精确结算顺序在系统文档与 TDD 中展开,须满足上述结果一致性。日终保存应包含已经完成的结算,不能读档后重复发放同一次收益。
| 目录 | 本阶段定位 |
系统通过 `item_id`、`npc_id`、`region_id`、`recipe_id` 等稳定标识关联。物品身份与实例归 S07,价格归 S09,关系值归 S10;任务、界面和存档可以引用或展示这些结果,不独立修改对应事实。UI 从权威状态刷新,只读展示副本不承担结算;存档快照在结算完成后生成,读档时恢复到对应系统。
跨系统共享的约束:
- 时间与生产使用一致的游戏时间单位,行动成本、制作时长与跨日成长须说明对应关系。顶层暂定常规游戏日约 10~20 分钟,实际换算与暂停规则在后续规格中明确并试玩验证。
- 金钱由 S09 统一结算,各活动提供产物或交易请求;经验是持续积累的进展,不作为货币消费。
- 失败后果按顶层场景分别处理:矿井倒下可能损失部分钱物,换季可能使作物枯萎,同时保留大部分长期进展。涉及体力、物品、金钱或位置的变化由各自负责系统执行。
- 存档、UI 和活动系统使用相同的状态含义,避免显示已获得但实际未入账、或已结算却未保存的结果。
## 系统文档映射
本例分别展开各系统,以下是策划工作区的文档目录;实现代码如何拆模块由 TDD 决定。
| 系统 | 文档目录 |
|---|---|
| 03_systems/S01_time_schedule/ | 时间推进、日期季节天气、营业时段、日终结算 |
| 03_systems/S02_stamina_status/ | 体力、状态效果、昏倒与恢复 |
| 03_systems/S03_farm_management/ | 土地、作物、畜牧、设施生产 |
| 03_systems/S04_exploration_map/ | 区域、连接、资源点、解锁与移动 |
| 03_systems/S05_foraging_fishing/ | 采集、钓鱼、品质与获得物 |
| 03_systems/S06_combat_enemies/ | 战斗、敌人行为、伤害与战利品请求 |
| 03_systems/S07_items_inventory_crafting/ | 物品、背包、配方与制作队列 |
| 03_systems/S08_progression_skills/ | 技能经验、等级、工具升级、能力解锁 |
| 03_systems/S09_economy_shop/ | 货币、买卖、价格、库存与订单 |
| 03_systems/S10_npc_relationship/ | NPC 日程、对话、好感与关系事件 |
| 03_systems/S11_quests_community/ | 任务、社区目标、奖励与解锁条件 |
| 03_systems/S12_events_festivals/ | 季节事件、节日、条件触发 |
| 支撑层不单开系统文档 | 存档与 UI 随实现层组织,规则不独立成文 |
| S01 时间与日程 | `project/03_systems/S01_time_schedule/` |
| S02 体力与状态 | `project/03_systems/S02_stamina_status/` |
| S03 农场经营 | `project/03_systems/S03_farm_management/` |
| S04 探索与地图 | `project/03_systems/S04_exploration_map/` |
| S05 采集与钓鱼 | `project/03_systems/S05_foraging_fishing/` |
| S06 战斗与敌人 | `project/03_systems/S06_combat_enemies/` |
| S07 物品、背包与制作 | `project/03_systems/S07_items_inventory_crafting/` |
| S08 成长与技能 | `project/03_systems/S08_progression_skills/` |
| S09 经济与商店 | `project/03_systems/S09_economy_shop/` |
| S10 NPC 与关系 | `project/03_systems/S10_npc_relationship/` |
| S11 任务与社区目标 | `project/03_systems/S11_quests_community/` |
| S12 事件与节日 | `project/03_systems/S12_events_festivals/` |
## MVP 最小闭环
1. 玩家在一个游戏日内完成开垦、播种、浇灌,并看到成长状态反馈。
2. 在时间与体力约束下选择当日主目标(农场劳动或外出)。
3. 外出采集(或矿井轻度战斗)带回资源。
4. 通过出售或加工获得金钱,投资种子或工具。
5. 日终结算展示当日变化并保存。
6. 次日作物状态变化,玩家据此形成新计划。
7. 数个游戏日内出现第一次技能提升与配方解锁。
## 实现范围与验证
如果这条闭环不成立,不应继续增加钓鱼深度、节日、社区目标或更多区域。
首个原型包含 S01、S02、S03、S04、S05、S07、S08、S09 的上述基础能力,加上必要的 UI 与存读档。完整版本还需展开钓鱼、制作、畜牧、战斗、居民关系、社区目标与节日等能力;完整清单不等于首个原型的施工范围。
## 统一数值基准
本案例采用"宽松治愈型"数值风格。全局单位:时间片、游戏日、货币、体力、经验;所有数值字段必须注明单位。
- 时间节奏基准:单次常规行动控制在短时间片内;玩家一天应能完成农务、一个主要外出目标和少量顺路活动;早期玩家不应因一次路线失误失去整天进度。
- 货币量级基准:主要货币只有一种;初期基础种子可用少量日常产出购买;一次普通收获不应立刻买下最高阶升级;任务奖励以补足短期资金为主,不替代生产交易。
- 成长回报基准:前几级在正常尝试一种活动的数个游戏日内出现;升级奖励优先采用节省时间体力、扩大选择和解锁配方,而非单纯提高伤害售价;专长分支宽松可恢复。
- 体力与风险基准:体力是规划提示不是严苛倒计时;普通农务与移动成本低,战斗、钓鱼和重型工具才产生明显取舍;失败成本采用时间、少量金钱或位置变化,不损毁进度。
首个流程从查看天气和选择目标开始,经农务或外出采集获得进展,再通过出售、购买和日终进入下一天。单日用于观察计划与取舍;连续数日用于覆盖作物生长、收获、投资和基础成长,不要求作物一天内完成播种到收获。
(具体换算数值与前五日验算由技术文档层·数值策划承接。)
## 系统边界
- 农场经营只管理农场内的生产状态,不负责所有资源的通用背包逻辑。
- 探索与地图只管理"在哪里"和"能否进入",不管理每种活动的具体奖励。
- 战斗只管理战斗内状态和战利品请求,不直接修改商店价格或 NPC 好感。
- NPC 与关系负责互动和关系变化;任务与社区负责可验证目标,二者通过事件和条件连接。
- UI、文本和表现不反向承载核心规则;所有关键变化必须由规则系统确认。
- 本案例不拆出独立多人、拍卖、复杂天气模拟、动态市场或高复杂度叙事工具系统。
## 优先级与范围
- P0(最小可玩闭环):时间与日程、体力、农场、物品背包、经济、基础地图、基础成长和日终结算。
- P1(形成完整案例):采集、钓鱼、轻度战斗、NPC 关系、任务、社区目标、制作、商店、季节和节日。
- P2(扩展内容):更多区域、敌人、作物、配方、关系事件、节日小游戏和终局后的自由活动。
拆分系统不等于所有系统都要在最小版本同时实现;系统独立性是为了便于协作和后续裁剪。
## 风险与校验
| 风险 | 校验方式 |
| 验证问题 | 内容与判断依据 |
|---|---|
| 农场变成例行公事,失去规划感 | 玩家是否在目标选择阶段出现真实取舍与计划调整 |
| 矿井战斗反客为主 | 战斗收益是否仍以"农场难以产出的材料"为主,而非直接金钱 |
| 时间压力变成打卡义务 | 休闲型玩家能否自由调低日程重量而不被惩罚 |
| 经济成长过快,后期失去决策 | 升级价格是否持续制造"效率 vs 规模"的选择 |
| UI 泄题,探索失去意义 | 关键信息是否保留为探索发现而非全量直读 |
| 系统间主数据重复维护 | 交叉检查:同一事实是否只有一个系统拥有写权 |
| 基础系统是否共同支持日常计划 | 试玩农务与采集,观察时间、体力、物品和金钱变化是否一致,结合玩家说明判断选择是否有意义 |
| 跨日成果能否支持后续计划 | 连续游玩并存读档,检查作物、交易与成长是否持续且无重复结算,结合玩家反馈判断是否形成新的目标 |
| 战斗是否改善探索节奏 | 后续加入 S06 与矿井所需的地图、状态和物品能力,观察战斗理解、损失恢复及其对日常活动的影响 |
| 关系与社区是否形成长期目标 | 后续加入 S10、S11 及对应内容,观察多日投入与目标选择;单日原型不据此判断长期体验 |
## 开放的结构问题
- 体力与生命是否保持为两个状态,还是在轻度战斗中共享一套风险资源?
- NPC 日程、任务条件和节日事件之间采用统一条件格式还是各自维护?
- 农场设施生产是否由农场系统统一管理,还是交给通用制作队列?
- 采集、钓鱼和战斗是否共享统一的"活动结果"接口?
- 哪些系统需要独立数据表,哪些小型配置应合并为一张内容表?
以上是验证计划,尚未形成试玩结论。出现问题时先判断是玩法目标不成立、协作职责遗漏还是实现错误,再调整相应设计与范围。
## 风险与未决问题
- 时间、体力和收益可能共同把休闲生活变成赶任务:沿用顶层验证计划,比较不同玩家的计划调整与压力反馈。
- 农场生产、制作和交易可能重复消费或入账:在系统规格中明确提交与失败处理,在实现阶段验证中断和日终存读档后的结果。
- 社区目标采用章节、可选收集还是组合仍需展开:在该内容进入实现范围前确定,并补齐 S11 与 S04 的解锁协作。
- 体力与战斗生命是否共享、战斗最低深度如何确定:不阻塞基础日常原型,在战斗原型前解决,再补齐 S02、S06 及相关 TDD 规格。
@@ -1,63 +1,43 @@
# 概念设计:《星露谷物语》
## 一句话概念
《星露谷物语》是一款以经营农场为基础、融合探索、采集、制作、轻度战斗、角色成长与社区叙事的乡村生活模拟 RPG;玩家通过安排每日时间与体力,把荒废农场逐步建设成理想家园,并与周围居民建立关系。
## 游戏概念
## 定调与设计锚点
《星露谷物语》是一款以经营农场为基础、融合探索、采集、制作、轻度战斗、角色成长与社区叙事的乡村生活模拟 RPG。玩家安排每日时间与体力,把荒废农场逐步建设成理想家园,并与周围居民建立关系。吸引力在于按自己的节奏塑造生活:今天的选择让明天更从容,社区关系让独居逐渐变成归属。
### 定调记录
- 参照选择:以牧场物语系为主(无压力日常方面学动物森友会);不参考任何高难动作与生存类游戏。
- 调性滑杆:压力感 低 / 战斗比重 低 / 管理深度 中 / 叙事比重 中低 / 节奏 慢。
- 调性锚:
T1 轻松治愈、自己的节奏(目标体验);T2 不劝退、无唯一最优解(体验门槛);T3 战斗轻度、非高难动作(非目标);T4 以"游戏日"为单位、可反复的单人体验(情境);T5 时间体力有限但休闲不打卡(跑偏风险);T6 小团队可维护的规模(关键约束);T7 日常叙事而非宏大主线,隐藏信息不迫使玩家查攻略(非目标/跑偏风险)。
## 体验与玩法
### 设计锚点
- 核心幻想:离开令人疲惫的城市生活,继承一片荒废土地,在自己的节奏中经营、探索、成长,并成为社区的一员。
玩家念头:"再玩一天就好——今天做完想做的事,明天的一切都会更顺手。"
- 目标体验:治愈、自由规划、持续成长、发现秘密,以及"今天的选择会让未来更轻松"的掌控感。
- 玩家动机:改善农场与生活条件;发现新区域和资源;完成社区目标;提升技能;与 NPC 建立关系;按照自己的偏好塑造生活方式。
- 核心循环:安排一天的时间与体力 → 进行农业、采集、钓鱼、采矿、战斗或社交 → 获得资源、金钱、经验与关系进展 → 投资工具、设施、种子和物品 → 解锁更高效或更丰富的活动。
- 跑偏风险:系统过多导致目标分散;时间与体力限制把休闲体验变成每日打卡;隐藏信息迫使玩家依赖外部攻略;经济成长过快使后期失去决策。
- 非目标:不做多人竞争、高难度动作战斗、唯一最优效率经营、主线剧情取代日常(详见《不是什么》)。
玩家通过改善农场、发现资源与区域、提升技能、完成社区目标和发展人际关系,获得自由规划、持续成长与发现秘密的乐趣。既可以追求效率,也可以把时间用于装饰、社交或探索。
## 玩家身份与基调
- 玩家身份:一名辞职逃离城市、继承祖父荒废农场的归乡人——不是拯救世界的英雄,是重新学会生活的人。季节与节日构成一年的节拍,日落结算构成每天的呼吸。
- 情绪基调:温暖治愈,慢而踏实。可以有忙碌与轻度压力(时间、体力),不做生存焦虑(饥饿、债务倒计时)与黑暗题材;孤独感只作为被社区逐渐治愈的起点,不成为基调本身。
主要游玩过程是:安排一天的时间与体力 → 进行农业、采集、钓鱼、采矿、战斗或社交 → 获得资源、金钱、经验与关系进展 → 投资工具、设施、种子和物品 → 解锁更高效或更丰富的活动,在下一天重新安排计划。
## 风格与世界观
复古像素风的温暖乡村世界。玩家来到一个正在现代化与传统生活之间摇摆的小镇,农场、商店、社区设施、自然区域和矿井共同构成可步行抵达的生活网络。世界观服务于生活模拟而非复杂设定解释:季节、天气、节日、居民日程和区域变化,让同一张地图随着时间产生生活感。叙事主要通过 NPC 日常对话、关系事件、任务和社区目标逐步展开。
其中的重要取舍包括:
- 时间与体力有限,玩家需要安排今天的优先级,做一件事意味着少做另一些事。
- 出售资源能立即获得资金,保留资源制作设备和升级工具则能提高未来效率。
- 农场提供可预测的收益;探索可能带来新资源和发现,也会消耗时间、承担风险。
- 赚钱占用社交时间;发展关系会减缓眼前收入增长,但能带来配方、剧情和情感回报。
- 季节、节日和社区目标提供方向;追赶这些目标会占用自由安排日常的空间,错过部分机会则需要等待或调整计划。
## 身份、基调与世界观
玩家是一名辞职离开城市、继承祖父荒废农场的归乡人,在经营与探索中重新建立生活,并成为社区的一员。日落结算构成每天的节拍,季节与节日带来更长周期的变化。
情绪基调温暖治愈,节奏慢而踏实。时间与体力可以带来忙碌和轻度压力,但不以饥饿、债务倒计时或黑暗题材制造生存焦虑;孤独感是逐渐融入社区的起点。
视觉采用复古像素风的温暖乡村。农场、商店、社区设施、自然区域和矿井组成可步行抵达的生活网络。季节、天气、节日、居民日程和区域变化让同一张地图产生生活感;叙事通过日常对话、关系事件、任务和社区目标展开。
参照牧场物语系的农场生活组织方式,以及动物森友会的自定义、装饰和按自己节奏整理日常的体验;农业经营中的时间、体力、季节取舍与社区修复仍是本例的重要内容。参照用于说明体验,不复制具体角色、文本、美术、地图或数值。
## 目标玩家与情境
- 目标玩家:与牧场物语系受众高度重合——喜欢种田与小人际的慢节奏成长玩家;同时吸收动物森友会式"无压力日常整理"的需求(自定义、装饰、按自己的节奏玩)。但它不能变成纯装饰沙盒,因为农场经营的时间、体力与季节取舍,以及社区修复目标必须始终存在。
- 适合情境:单人、可反复游玩、每次一个游戏日或几个游戏日;可以高效规划,也可以把时间用于装饰、社交或探索。
- 体验门槛:需要理解基础资源转换和时间安排,不应要求预先掌握复杂数值或寻找唯一正确答案。
## 不是什么
| 不是 | 因为 |
|---|---|
| 硬核生存农场模拟 | 没有饥饿、债务、死亡惩罚;压力止于温和的时间与体力 |
| 效率至上的工厂经营 | 不要求唯一最优解,装饰与闲逛是合法玩法而非浪费 |
| 以战斗为核心的动作游戏 | 战斗只是采矿与探索的伴生风险,深度刻意受限 |
| 剧情驱动的叙事游戏 | 社区叙事是日常的背景与情感回报,不是任务链主线 |
| 多人社交平台 | 单人体验为前提,人际关系由 NPC 关系承载 |
| 无边界开放世界 | 地图是功能明确的小区域网络,全部可步行抵达 |
面向喜欢种田、人际关系与慢节奏成长的玩家,也容纳偏好装饰、收集和自由安排日常的玩家。
## 核心张力
- 时间与体力有限,但想做的事情很多:玩家必须决定今天的优先级。
- 立即变现与长期投资:出售资源能快速获得资金,制作设备和升级工具则能提高未来效率。
- 稳定经营与未知探索:农场提供可预测收益,矿井、钓鱼和新区域提供风险与发现。
- 个人效率与社区关系:把时间用于赚钱会挤压社交,但关系又会带来配方、剧情和新的情感目标。
- 自由生活与阶段目标:玩家可以自由安排日常,同时受到季节、节日、任务和社区修复目标的轻度牵引。
本例围绕可反复游玩的单人体验,每次可玩一个或几个游戏日。玩家需要理解基础资源转换和时间安排,不应依赖复杂数值计算或寻找唯一正确答案才能推进。
## 边界与约束
- 概念层只定义核心幻想、目标用户、体验基调与排除方向;具体战斗公式、作物成长天数、礼物偏好、掉落率、系统清单和 MVP 内容,留给顶层及以后决定。
- 设计规模以单人或小团队可理解、可维护为前提;地图采用多个功能明确的区域,而非无边界开放世界。
- 所有系统都必须回流到"安排一天并获得长期改善"的核心循环;独立小游戏或装饰功能不能成为主要范围扩张来源。
- 案例声明:本文以《星露谷物语》为案例展示设计的组织方式,不复制其具体角色、文本、美术、地图或数值。
## 概念定稿
《星露谷物语》的核心不是"种田赚钱",而是:
> 在自己的节奏里经营一片土地与一段生活——今天的选择让明天更从容,而社区让独居变成归属。
交给下一层的约束:时间与体力必须构成温和而非焦虑的取舍;战斗、采矿、社交等支线必须回流农场生活循环;成长权重要允许玩家自定义(效率型与休闲型玩家都成立)。
(调性已在第 2 节定死;顶层及以下一切开放问题先回定调记录的 T1~T7 级联。)
- 战斗服务于采矿与探索,不扩展为高难度动作游戏;社区叙事提供日常背景与情感回报,不用宏大主线取代农场生活。
- 时间和体力形成温和的取舍,避免把休闲变成每日打卡。装饰、闲逛和社交都有价值,不以唯一最优效率为目标。
- 本例按单人或小团队规模控制内容,地图采用功能明确的小区域网络,不扩展为无边界开放世界或多人社交平台。
- 各系统服务于日常生活及其长期改善。独立小游戏或装饰内容的扩张不能挤占核心体验;同时避免经济成长过快使后期失去选择,或隐藏信息迫使玩家依赖攻略。
- 后续设计应允许效率型和休闲型玩家按自己的偏好成长;具体系统范围、版本内容、战斗公式、作物成长天数和掉落率等再逐步展开。
@@ -1,120 +1,56 @@
# 战斗与敌人系统:S06
## 系统目的
为危险区域提供轻度、可理解的战斗挑战,使玩家在探索中承担风险,并通过装备、补给和技能成长验证长期准备。战斗是生活模拟循环的支柱之一,不是游戏的唯一核心。
版本:v2
## 支撑的玩家体验
- 玩家能观察敌人行为,选择攻击、躲避、补给或撤退。
- 战斗结果主要取决于准备、判断和适度操作,而不是高强度连招。
- 深入危险区域会带来更高资源和成长回报,也会增加生命、时间和补给压力。
- 失败有明确原因和可恢复成本,不应摧毁长期农场进度。
## 职责与原型范围
## 进入与退出
### 进入
- 玩家进入允许战斗的危险区域或触发敌人遭遇。
- 检查区域、时间、装备、生命、背包和任务条件。
- 初始化当前战斗区域、敌人组合、战斗状态和可撤退条件。
### 退出
- 击败敌人并完成战斗奖励结算。
- 玩家主动撤退或离开战斗区域。
- 玩家生命归零,由体力与状态系统执行昏倒或失败惩罚。
- 特殊事件、日终或区域状态强制结束战斗。
战斗服务于矿井探索中的风险与节奏变化,不扩展为高难度动作或装备构筑主轴。S06 负责敌人行为、攻击与伤害判定、战斗结果和战利品请求;通过 S02、S04、S07、S08 等系统完成玩家状态、位置、物品和经验更新。
## 玩家行动
- 移动、观察敌人攻击范围和行为状态。
- 普通攻击、重攻击或使用装备技能。
- 防御、闪避、格挡或利用场景短暂规避伤害。
- 使用食物、药剂等消耗品。
- 拾取战利品、调查宝箱或选择继续深入。
- 在满足条件时撤退,保留已结算的奖励。
战斗不属于首个日常原型。后续矿井原型暂按实时操作展开,先验证移动避让、普通攻击、补给与撤退;重攻击、独立闪避或格挡技能、首领等内容暂未纳入。以下是供验证的方案,尚未形成试玩结论;生命与体力关系、具体判定参数等缺口需在战斗进入施工范围前补齐。
通用流程:
`进入遭遇 → 读取敌人状态 → 玩家行动 → 敌人响应 → 结算伤害/效果 → 判断胜负或撤退`
## 遭遇与行动
## 取舍表
玩家经 S04 进入可战斗区域,S06 根据该区域的遭遇配置和已有敌人状态建立遭遇。进入区域本身不消费补给或发放奖励;消耗发生在实际行动成功时。
| 决策 | 立即收益 | 延迟收益 | 主要代价 |
|---|---|---|---|
| 继续深入还是安全撤退 | 更多资源 | 更高风险与返程压力 | 已得战利品可能损失 |
| 消耗品现在用还是留着 | 维持当前探索 | 应对更强敌人 | 局部战况恶化 |
| 快速击败还是稳健闪避 | 节省时间 | 降低受伤风险 | 补给与时间消耗 |
| 高伤高耗装备还是基础攻击 | 更快击杀 | 稳定与低消耗 | 资源消耗大 |
| 资金投武器防具还是农场设施 | 战斗能力 | 农场产能 | 另一侧进度放缓 |
玩家观察敌人位置与攻击准备,选择接近攻击、移动避让、使用补给或沿可用出口撤退。普通攻击先检查武器、距离、方向和动作间隔,再按命中规则结算;攻击范围、伤害计算与动作间隔的具体定义尚待补齐。补给的持有和消耗由 S07 处理,恢复效果交 S02 更新,使用失败不能只扣除物品。
## 状态与规则
### 玩家战斗状态
- 当前生命、最大生命和状态效果。
- 装备中的武器、防具、饰品和消耗品。
- 攻击、防御、移动、闪避和技能冷却状态。
- 当前战斗区域、遭遇编号和撤退状态。
### 敌人状态
敌人状态至少包括待机、警觉、攻击前摇、攻击中、受击、眩晕、死亡和撤退。
每个敌人的实例数据(生命、位置、目标、状态效果、掉落引用)的字段定义由技术文档层承接。
### 战斗规则
- 只有满足攻击距离、方向、冷却和装备条件时,攻击才可结算。
- 伤害由攻击来源属性、目标防御、技能倍率和状态效果共同决定。
- 敌人攻击必须有可识别的前摇或预警,给予玩家反应与撤退机会。
- 生命降至零时进入死亡或昏倒状态;具体惩罚由体力与状态系统处理。
- 敌人死亡后只结算一次经验与战利品,并写入遭遇状态,避免重复领取。
- 撤退后已完成的战斗奖励保留,未击败敌人按区域刷新规则处理。
### 区域遭遇
- 危险区域由敌人组、刷新规则、深度或阶段配置组成。
- 进入更深区域可以提高敌人强度、资源价值和特殊遭遇概率。
- 区域难度应通过可理解的装备、区域和任务条件表达,不依赖突然的数值墙。
- 宝箱、精英敌人和首领可作为独立遭遇类型,但不在最小版本中同时扩张。
击败一个敌人后可继续探索,不自动结束区域活动。沿出口离开时保留已入账的物品与经验;玩家倒下时进入失败处理,不能按安全撤退结算。日终等中断与伤害、拾取同时发生时的处理顺序,需要在矿井原型前明确。
## 数值与数据交接(→技术文档层)
本系统交由技术文档层(数值策划)定义的数据类别:敌人配置、敌人行为配置、武器配置、技能配置、遭遇配置、战利品配置、状态效果配置。
## 敌人行为与结果
随交接附下的设计侧定性约束:
- 敌人数据拆分为"是什么 / 怎么行动 / 掉什么"三类,使难度与经济可独立调节。
- 普通敌人不应稳定掉落大量高价值物品;战斗收益主要由矿物、经验和区域发现组成。
- 稀有材料是"有明确用途的探索奖励",但必须保留任务、宝箱等补充渠道,避免战斗失败后无法推进。
- 基础战斗允许玩家一日内完成少量遭遇并安全返程,不要求连续刷怪。
- 失败保留已结算的普通战利品,主要损失是时间、位置或少量金钱,不清空背包。
- 自动化收益节省日常体力,但不能让玩家跳过农场维护的全部决策。
- 收益回流方向:区域 → 敌人 → 材料 → 加工 → 农场自动化;战斗不直接取代农场收入。
本原型以能接近玩家并进行近身攻击的普通敌人为起点:发现玩家后接近,进入攻击距离后给出可识别的准备动作,再执行攻击并恢复。失去目标后的行为、受击是否打断、离开区域后的恢复方式还需补齐;不为所有敌人预设眩晕、撤退等完整状态集合。
## 反馈
- 攻击命中、受击、闪避、格挡和暴击提供清晰的视觉与声音反馈。
- 敌人显示生命、预警、当前状态和可攻击时机。
- 玩家生命、补给、冷却和撤退可用性持续可见。
- 战斗胜利显示经验、战利品和区域进度。
- 失败说明主要原因,并明确损失、保留内容和可恢复路径。
攻击准备应让玩家看懂危险并有机会应对,实际时长和表现通过试玩调整。伤害只在有效命中时结算,不能因动画或反馈重复播放而多次扣除。敌人被击败后停止行动,并为该次击败结算一次战利品和经验;拾取或存读档不能再次领取同一次奖励。
## 内部循环
### 单次战斗循环
`观察敌人 → 选择攻击或防御 → 处理敌人响应 → 造成或承受伤害 → 调整策略 → 击败或撤退`
### 危险区域循环
`准备装备与补给 → 进入区域 → 战斗与搜刮 → 判断继续深入或返程 → 带回资源 → 升级能力`
### 长期循环
`获得战斗经验与装备 → 提升生存能力 → 挑战更深区域 → 获得稀有资源 → 解锁新制作、任务或地图`
继续深入可以获得更多资源和经验,也会消耗时间、生命或补给并增加倒下风险;提前撤退保留当前收获,但放弃本次继续探索的机会。矿井中倒下沿用顶层设计:损失部分金钱或物品,保留大部分长期积累,补充准备后可以再次探索。具体损失范围和幅度尚未确定,不承诺所有已入账战利品都免于失败损失。
## 输入、输出与依赖
### 输入
- 探索与地图系统提供战斗区域、位置和遭遇入口。
- 时间系统提供当前时间、季节和日终信号。
- 体力与状态系统提供生命、体力、状态效果和失败处理。
- 物品系统提供武器、防具、消耗品和战利品接收入口。
- 成长系统提供属性、技能和装备解锁。
- 玩家通过核心玩法系统提交战斗行动。
### 输出
- 向物品系统提交战利品和消耗品变化。
- 向成长系统提交战斗经验和能力进度。
- 向地图系统提交敌人、宝箱和遭遇状态。
- 向任务与社区系统提交击败、调查和区域进度。
- 向 UI 输出战斗状态、反馈、胜负和撤退结果。
战斗收益服务于本例的探索与生活成长,具体掉落和经济关系结合物品用途及收益平衡确定;本例的取向不作为其他游戏的通用战斗限制。
## 边界与非目标
- 不负责通用生命与昏倒惩罚,只提交状态变化。
- 不负责武器物品的背包、耐久和售价主数据。
- 不负责字段定义、数值配置与表格结构——归技术文档层(数值策划)。
- 不做高难度动作连招、复杂多人战斗或精确帧竞速。
- 不让战斗成为获得普通农场资源的唯一方式。
- 不在本系统中定义全部敌人、武器和首领内容。
## 协作与数据归属
## 开放问题
- 战斗采用实时操作,还是更简化的节奏/指令判定?
- 体力是否影响攻击与闪避,还是只影响探索和农务?
- 武器是否有耐久度,还是通过升级与装备更换形成消耗?
- 战斗失败的主要成本采用金钱、位置、时间,还是有限组合?
| 内容 | 负责方与协作 |
|---|---|
| 敌人行为、战斗判定和击败记录 | S06 维护;通过 S04 执行位置变化,使用实际位置进行判定 |
| 玩家生命、体力、状态效果和倒下处理 | S02 接收 S06 的伤害或成本请求,协调失败后果;生命是否与体力共池尚待明确 |
| 区域、出入口与角色位置 | S04 提供,S06 据此判断遭遇和撤退;敌人刷新条件由 S06 与区域生命周期衔接 |
| 武器、补给、战利品身份和持有 | S07 维护;S06 引用物品标识与已确定的战斗属性,提交消耗或获得请求 |
| 战斗经验与能力 | S08 接收击败结果并更新经验;S06 使用已生效的能力结果 |
| 失败损失与时间 | S09 更新金钱,S07 更新物品,S04 更新位置;S01 提供时间及日终通知,各系统按明确的失败或中断结果更新 |
| 任务进度与呈现 | S11 接收相关击败结果;UI 展示权威状态、接受操作请求,不自行判定伤害或发奖 |
物品入账失败时,待领取奖励如何保留、离开区域后能否再取,需在矿井原型前确定。存档保存敌人、奖励与各系统已完成的结果,恢复后不得重复发奖。具体更新顺序、持久化与恢复协议由 TDD 落实。
实现所需的数据包括敌人行为与属性、攻击判定、区域遭遇、物品引用、奖励和失败后果。已确定的规则与参数保留在设计中,由 TDD 收编并补齐字段、配置、计算方式和默认值,不仅交接数据类别名称。
## 反馈与验证
玩家应能识别敌人的攻击准备、命中或受伤结果、当前生存状态与补给使用结果。无法攻击、使用物品或撤退时说明当前原因;倒下后说明损失、保留内容和返回位置。
| 场景 | 判断依据 |
|---|---|
| 遭遇普通敌人并攻击或避让 | 玩家能理解攻击准备,伤害与实际命中一致;结合试玩反馈判断操作压力是否符合轻度战斗定位 |
| 击败、拾取并存读档 | 物品与经验正确入账,同一次击败不会重复结算;入账受阻时按补齐后的奖励保留规则处理 |
| 安全撤退与矿井倒下 | 撤退保留已入账成果;倒下执行明确的部分损失,提示与各系统实际结果一致 |
| 使用补给或遭遇日终中断 | 物品与恢复结果一致,中断按补齐后的顺序结束处理,不留下部分扣除或重复收益 |
以上为待执行的验证场景。战斗进入实现范围前,还需明确生命与体力关系、敌人行为与刷新、伤害和动作参数、奖励入账受阻处理、失败损失及日终中断顺序,并同步 S02、S04、S07、S08、S09 和相应 TDD。
@@ -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 规格并同步程序分册 |
问题解决后更新对应正文并移出待办,施工方无需从外部台账查找最终规格。
@@ -1,19 +1,21 @@
# 数据与配表:《星露谷物语》(TDD 金样 · 数据与配表)
> 状态:accepted(结构定稿+首期全量填充验算通过) | 基于:各系统文档交接节汇总 + 归 TDD 素材两份提取件(S06 数值结构/架构字段字典) | 验收:check@C-2026-09-11-v1 结论 无 blocker
> 实证计数来源:星露谷 1.6.15 解包知识库 v3(13 张数据表,提取脚本断言通过;快照 stardew-1.6.15-7f1e5b8e)。写新项目时按本项目系统交接节重建,计数仅作规模参照。
> 状态:待补齐(基础采集配置、当前范围验算、背包容量与公共索引定义仍有缺口) | 基于:各系统规则与数据汇总 + 归 TDD 素材两份提取件(S06 数值结构/架构字段字典) | 已有数据验收:check@C-2026-09-11-v1;不代表当前范围规格已完备
> 实证计数来源:星露谷 1.6.15 解包知识库 v3(13 张数据表,提取脚本断言通过;快照 stardew-1.6.15-7f1e5b8e)。写新项目时按本项目的系统规则与数据需求重建,计数仅作规模参照。
## 数据表总清单
以下包含完整版本的数据类别;v0.1 只取首个日常原型需要的农务、基础采集、物品、交易、成长、时间与地图等内容。战斗、钓鱼、关系、任务和节日数据用于后续范围,不作为 v0.1 已实现能力。
| 表格组 | 建议表名 | 主要维护系统 | 实证规模(原作 1.6.15) |
|---|---|---|---|
| 物品与经济 | 物品表、品质表、商店表、商店库存表、价格表 | 物品与制作、经济与商店 | 物品 807×29 类;商店 77 店 897 条库存(含店级 PriceModifiers) |
| 农场内容 | 作物表、动物表、设施表、加工配方表 | 农场经营 | 作物 50 全字段;机器 39 台全 OutputRules |
| 活动内容 | 采集点表、钓鱼点表、鱼类表、敌人表、敌人行为表、遭遇表、战利品表 | 采集/钓鱼/战斗 | 怪物 51 条配置;怪物 AI 矩阵 30 类移动原型 |
| 物品制作 | 通用配方表、配方解锁表 | 物品与制作 | 配方 231(烹饪 81+工艺 150,全原料/产出/解锁) |
| 活动内容 | 资源点表、采集规则表、钓鱼点表、鱼类表、敌人表、敌人行为表、遭遇表、战利品表 | S04 管资源点位置、可用与刷新状态;S05 管采集/钓鱼判定及获得物;S06 管战斗与战利品规则 | 怪物 51 条配置;怪物 AI 矩阵 30 类移动原型 |
| 物品制作 | 通用配方表、配方解锁表 | S07 管配方定义;S08 管技能解锁,S11 管任务条件,使用方引用结果 | 配方 231(烹饪 81+工艺 150,全原料/产出/解锁) |
| 玩家成长 | 技能表、等级经验表、能力节点表、工具升级表、效果表 | 成长与技能 | 职业 30 全效果钩子(51 钩子+6 数据驱动);附魔 34 逐项数值;经验曲线代码常量 |
| NPC 与任务 | NPC 表、关系等级表、礼物偏好表、任务表、奖励表、事件条件表 | NPC/任务/事件 | NPC 送礼 34NPC×4 档+全局 5 档;事件 258/条件码 39 |
| 时间与世界 | 日期季节表、天气表、节日表、营业时段表 | 时间与日程、事件与节日 | —(代码常量+日程数据驱动) |
| 时间与世界 | 日期季节表、天气表、节日表、营业时段表 | S01 管日期天气,S12 管节日,S09 管营业条件;居民日程归 S10 | —(代码常量+日程数据驱动) |
| 文本与展示 | 文本表、UI 提示表 | UI 与文本呈现及各内容系统 | 11 语言按后缀拆分(含 zh-CN) |
(表格拆分是生产组织方式,不改变主数据归属。原作同套模型同时服务本体与模组生态——静态表为结构化 JSON-in-XNB,由 DataLoader 按需缓存。)
@@ -66,33 +68,40 @@
## 数值填充与验算
- 填充代决台账:
- 当前采用的数值与验证关注点:
| 表 | 字段 | 默认值 | 依据 | 推翻条件 |
| 表 | 字段 | 当前值 | 依据 | 验证关注点(按需) |
|---|---|---|---|---|
| 等级经验表 | 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 日验算不闭合 |
| 经济表 | 买卖价差 | 商店价=2×基价×品质系数;出售所得=其半 | 原作一对出售方法实证 | 新手期现金流断裂 |
| 战斗表 | 受击无敌帧 | 450ms(按武器类型 2/3 除) | 原作 takeDamage 实证 | 手感测试受击连按 |
- 前五日闭环验算(防风草路线,起始 500 金实证口径):
- v0.1 多日验算草案(农务、基础采集、交易与成长):
| 日期 | 主目标 | 关键行动 | 主要成本 | 主要获得 | 结果 |
|---|---|---|---|---|---|
| 第 1 日 | 建立基础生产 | 购防风草种子×15(20 金/包)、开垦播种浇灌、采集少量木材 | 300 金;约 30 体力;约 8 时间片 | 15 块已播种地;少量木材;农务经验 | 进入等待成长阶段 |
| 第 2 日 | 接社区引导 | 浇灌、采集木材、与工匠对话推进修路任务 | 约 25 体力;约 8 时间片 | 任务材料进度;少量经验 | 任务明确指向自然区域 |
| 第 3 日 | 补足任务材料 | 浇灌、采集木材与铜矿、返回小镇 | 约 35 体力;约 12 时间片 | 木材 20、铜矿 5(或进度);采集/战斗经验 | 可提交修路任务 |
| 第 4 日 | 收获+解锁 | 收 15 防风草(35 金×15=525 金、8 xp×15=120 xp→农务 1 级)、提交任务领奖 | 任务材料;约 10 时间片 | 525 金;基础洒水器配方;林间区域开放 | 现金流回正+新活动选择 |
| 第 5 日 | 验证扩展循环 | 浇灌、赴林间采集或钓鱼、出售部分产物 | 约 30~45 体力;约 14 时间片 | 新资源、活动经验、可售物品 | 循环从单一农务扩展为农场+探索 |
| 时段 | 关键行动 | 可据现有数值推算的部分 | 待补齐的验算输入 |
|---|---|---|---|
| 第 1 日 | 买种、播种、浇水与基础采集 | 起始 500 金,15 包种子各 20 金,购种后余 200 金 | 农务和采集成本、采集获得物与经验 |
| 第 2~4 日 | 维护作物,选择外出采集并出售部分成果 | 连续满足成长条件,等待四次跨日成长完成 | 每日时间体力收支、资源点刷新、采集收益 |
| 第 5 日 | 收获、出售、投资与基础成长 | 若 15 株均正常成熟且为普通品质,售得 525 金、收获经验 120 xp;种子投入的毛利为 225 金,不含其他收支 | 实际品质、其他活动收支、成长反馈与投资选择 |
- 收益链校验:`item_seed_parsnip(20金) → crop_parsnip(4 日) → item_parsnip(35 金) → 出货箱日终结算 → 种子复购(单包毛利 15 金)`(逐环引 ID,全链存在)。
- 验算结论:第 1 日不要求做完,播种即进展;第 4 日奖励同时给资金/配方/区域三样;第 5 日出现农场与探索取舍但两条路线都可行。
- 待校验的收益关系:`item_seed_parsnip(20金) → crop_parsnip(4 日) → item_parsnip(35 金) → 出货箱日终结算 → 种子复购`。仍需结合实际配置核对引用、成长条件、采集收益及跨日结算,不能以局部算术推算宣称完整验算通过。
- 当前结论:上述草案未完成 v0.1 的时间、体力和资源收支验算,也未证明玩法节奏成立。补齐输入后验算,并结合原型观察与玩家反馈判断。
## 验收
- 验收记录:check_id / workbook / sheet / data_version / check_type(primary_key·reference·enum·unit·range·business_rule·duplicate_ownership)/ severity(blocker·warning·note)/ result / issue / owner / resolution。
- 五查必过:主键唯一不空;外键存在且目标非弃用;枚举有清单(品质枚举 0/1/2/4 单独登记);单位可判且同列不混;无违规负数、`duration=0` 仅即时。
- 两查复核:业务规则(季节窗口相容、目标有验证系统、奖励一次、配方输入可达——防风草种子→收获→出售链全通);重复归属(价格只由经济表维护、品质只由收获规则维护)。
- 两查复核:业务规则(季节窗口相容、目标有验证系统、奖励一次、配方输入可达);重复归属(价格由 S09 维护,品质枚举由 S07 维护,农作物品质由 S03 的收获规则判定,采集品质由 S05 判定,不另行定义品质枚举)。
- 三级处置:blocker 禁止扩内容;warning 记负责人与计划;note 不阻断。
- 工具化实证口径(参照知识库做法):提取脚本逐表断言(行数/字段/枚举);对账器做表间交叉对账(代表资产级 50 键全对账);反例套件 5/5 拒绝。
- 最近验收结论:check@C-2026-09-11-v1——五查全过、两查复核通过、blocker 清零(结构、规则或字段语义一变,受影响链路全部重验)。
- 最近验收结论:check@C-2026-09-11-v1——已有数据的五查与两查复核通过;基础采集配置、当前范围验算、背包容量与公共索引定义仍需补齐,不能据此认定当前范围的数据规格完整。结构、规则或字段语义一变,受影响链路全部重验。
## 待解决问题
- 基础采集:补齐资源点位置与刷新、采集判定、获得物、品质和经验配置,与技术分册 S04/S05/S07/S08 的职责和接口一致。
- 当前范围验算:补齐日常行动成本和收益,明确跨日结算顺序,完成 v0.1 农务、基础采集、交易与成长的多日收支验算。
- 背包容量:与技术分册确认格子或重量规则后,补齐容器字段、容量约束及存档数据定义。
- 公共索引:补齐 condition/text/station/behavior 的索引定义与引用说明,再检查加载和引用完整性。
完成后将采用的规则写入本文对应数据规格并更新验收结论,移出待办。
@@ -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 | 首个日常原型所需的八个系统如何协作? | 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“S05”“S01”及“待解决问题”;补齐后同步数据分册 |
| 01、03 | 背包容量与体力规则影响行为、存档及界面 | 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 可实施”。
@@ -1,6 +1,7 @@
# 技术实现:《星露谷物语》(TDD 金样 · 技术实现)
> 状态:reviewed | 基于 GDD:架构层@v3 + P0 系统文档@v1(收编) | 数据侧契约:data/contracts@v2
> 状态:待补齐 | 基于 GDD:架构层@v3 + 当前范围系统文档@v1(收编) | 数据侧契约:data/contracts@v2
> 本例 v0.1 对应架构层的首个日常原型,仍缺基础采集的完整规格,背包容量和体力规则也未确定;尚不能作为完整施工依据。后续能力另行标明,纳入实现范围前须补齐。
> **目标运行时:HTML**(由 GDD 平台事实锁定;本项目按浏览器平台事实执行)
> 平台事实:双视口(桌面/移动)· 键鼠/触屏双输入 · 本地 HTTP 预览
> 实证数字来源:星露谷 1.6.15 反编译知识库 v3(快照 stardew-1.6.15-7f1e5b8e,2026-09-11);写新项目时替换为本项目数值。
@@ -9,7 +10,7 @@
### S01 时间与日程(基于系统文档@v1 收编)
- 玩家行动:查看时间天气(HUD 常驻);使用床提前结束一天;等待营业时段。
- 状态与规则:时间以时间片计、现实驱动、暂停时停表;时间片耗尽或就寝→日终结算(顺序固定:作物生长 tick→设施产出→出货箱结算→NPC 日程推进→存档→日记界面)→日期+1;28 日/季、四季/年;天气每日按季节权重抽取(晴/雨/风暴),雨天免浇水;结算后向 S03/S07/S10 发跨天 tick。
- 状态与规则:时间以时间片计、现实驱动、暂停时停表;时间片耗尽或就寝→协调日终结算→日期与天气更新→各系统准备次日状态→存档与汇总反馈。作物成长由 S03、设施或制作由对应生产系统、出货由 S09、成长由 S08 处理;28 日/季、四季/年;天气每日按季节权重抽取(晴/雨/风暴),雨天免浇水。居民内容加入后,S10 接收时间通知并推进自身日程;精确结算顺序仍需补齐。
- 反馈需求:HUD 时钟日期常驻;天气图标;日终面板逐项列当日变化。
- 实证参照(原作 1.6.15):`700ms = 10 游戏分钟`(累加器超 `7000 + 地点Extra×10`ms 触发十分钟拍,`timeOfDay += 10`,上限 2600);日结算顺序不可乱——出货先于邮件/任务(订单计数依赖)、地点 dayUpdate 先于玩家 dayupdate(作物推进后才有当日收获判定)。
@@ -20,37 +21,46 @@
- 实证参照:原作基础 MaxStamina=270、MaxHealth=100;午夜后体力惩罚为线性公式(Farmer.dayupdate);昏睡账单上限默认 1000g、姜岛 2500g(LocationContexts 数据驱动,非硬编码)。
### S03 农场经营(基于系统文档@v1 收编)
当前实现耕种、浇水、生长与收获;下述畜牧、设施和加工内容属于后续范围。
- 玩家行动:锄地/播种/浇水/收获/铲除;喂动物收集畜产;放置使用设施;整理布局。
- 状态与规则:地块状态机 荒地→耕地→(播种+浇水)→生长 N 日→可收获→收获后回耕地;未浇水当日不生长;生长按日终 tick;雨天视为已浇水;作物有适宜季节、换季枯萎;动物每日喂食→周期产出、未喂不产出不死亡;洒水器每晨自动浇固定格;加工设备按配方+时间片队列产出;品质分普通/银/金(技能等级+概率)。
- 反馈需求:生长阶段视觉可辨;成熟提示标记;设施完成音效图标;日终列农场产出。
- 实证参照:耕地是网格状态拥有者,作物挂在耕地下(HoeDirt 拥有湿度/肥料/作物引用);收获单一入口;**品质 roll 先于数量 roll 且共用同一随机流**(顺序影响结果);保水判定在作物推进之后(当天浇的水当天有效)。
### S04 探索与地图(基于系统文档@v1 收编)
当前实现农场、小镇与基础采集区域;矿井、钓鱼入口和任务解锁属于后续范围。
- 玩家行动:移动(8 向网格);穿出入口切换区域;查看地图;交互资源点入口(采集/钓鱼/战斗分别交 S05/S06)。
- 状态与规则:区域=独立场景、连接点切换淡入淡出≤1s;初始开放农场+小镇+海滩,林间/矿井由社区任务解锁(条件表);资源点固定刷新点按规则周期重生;隐藏信息保留为探索发现;矿井按层进入、固定池随机拼装+亮度递减。
- 反馈需求:地图标注已解锁区域与当前位置;解锁新区域明确提示与入口指引;资源点可交互高亮。
- 实证参照:原作矿井同日同层布局确定(每日世界种子 `DaysPlayed + 存档ID/2`);矿井布局池 61 张模板按层拼装;骷髅洞时间减速 28.6%(+200ms/分)仅单机生效。
### S05 采集与钓鱼(当前范围为基础采集,规格待补齐)
基础采集属于 v0.1,钓鱼属于后续范围。当前尚缺采集触发、获得物判定、资源点状态更新、物品入账失败处理及经验反馈的完整规格;须补齐本节及数据分册中的配置后,才能满足当前范围只看 TDD 即可实现的要求。
### S07 物品、背包与制作(基于系统文档@v1 收编)
当前实现基础物品、背包与工具使用;装备、制作队列和图鉴等能力后续展开。
- 玩家行动:整理背包;使用/装备/丢弃;设施处提交配方;查看图鉴。
- 状态与规则:一切以 item_id 为准,类别枚举(工具/种子/素材/食物/装备/家具/礼物);同类同品质堆叠(容量结构待 B 级决策,暂按格子制实现、预留字段);工具等级制(基础→铜→铁…,升级交材料+金+天数);装备槽武器/防具各一;配方=材料子表→输出→设施→condition_id 解锁;制作队列按时间片推进、日终照常完成。
- 反馈需求:拾取飘字音效同帧;背包变更即时刷新;制作完成提示;图鉴进度。
- 实证参照:原作 807 物品统一限定 ID 引用(如 `(O)123`);品质枚举值为 0/1/2/4(银=1、金=2、铱=4),所有 `(1 + 0.25×quality)` 型公式的乘数因此是 1.25/1.5/2.0;出售语义一对方法承载:`salePrice()`(=2×基价×品质系数,商店价)与 `sellToStorePrice()`(=salePrice/2,玩家所得)。
### S08 成长与技能(基于系统文档@v1 收编)
当前实现基础农务或采集成长;其他活动技能、分支与工具升级委托属于后续范围。
- 玩家行动:查看技能面板;升级时选加成方向;提交工具升级委托。
- 状态与规则:技能五项(农务/采集/采矿/钓鱼/战斗)独立经验池;执行对应活动得经验、只增不减;等级效果三类——效率(省时省体力)/解锁(配方/区域/工具位)/选择(每若干级一次分支,宽松可回转);工具升级期间该工具不可用(备用旧工具=开放问题暂不备);升级奖励优先省时省力扩选择,不加数值伤害。
- 反馈需求:经验条与升级音效;升级面板三选一;工具完成由铁匠通知。
- 实证参照:原作技能累计经验曲线为代码常量 `100/380/770/1300/2150/3300/4800/6900/10000/15000`(10 级);经验取整用银行家舍入(边界值注意);满级后经验转全局精通点(第二成长曲线)。
### S09 经济与商店(基于系统文档@v1 收编)
- 玩家行动:出售(出货箱日终/商店现卖);购买;查看价格库存;接装箱订单(P1)。
- 状态与规则:货币唯一;基准价+买卖价差,价格只由本系统维护(其他系统只提交产物或消费请求);商店各有营业时段(条件表)、库存按周期补货、部分商品有购买条件;出货箱投入→日终统一结算计入当日收入;订单 P1 最低配=每周装箱单换奖金。
- 玩家行动:出售(出货箱日终/商店现卖);购买;查看价格库存;装箱订单属于后续范围。
- 状态与规则:货币唯一;基准价+买卖价差,价格只由本系统维护(其他系统只提交产物或消费请求);商店各有营业时段(条件表)、库存按周期补货、部分商品有购买条件;出货箱投入→日终统一结算计入当日收入;后续订单的基础形式为每周装箱单换奖金。
- 反馈需求:交易金额飘字音效;日终面板单列收入明细;商店营业状态门口可见。
- 实证参照:原作 77 店 897 条库存,店级 PriceModifiers 数据驱动;基础材料(木/石/煤/铜/铁/金)售价走年度特例(第 2 年起涨价)而非通用公式。
### S06 战斗与敌人(P1,基于系统文档@v1 收编要点)
进入危险区域遭遇→敌人状态机(待机/警觉/前摇/攻击/受击/眩晕/死亡)→攻击需满足距离方向冷却装备条件→伤害=来源属性+目标防御+倍率+状态→敌前摇必须可识别→死亡只结算一次经验战利品→战利品按 item_id 提交 S07 入账→撤退保留已结算奖励。全规则见系统文档@v1(P1 施工时全文收编)。
### S06 战斗与敌人(后续范围,基于系统文档@v2 收编要点)
矿井原型暂按实时操作验证移动避让、普通攻击、补给与撤退,不预设重攻、独立闪避或格挡技能。普通敌人发现玩家后接近,攻击前给出可识别的准备动作;有效命中才结算伤害,同一次击败只发放一次战利品与经验。S06 管敌人行为和判定,S04 管位置,S02 管玩家生存状态,S07 管物品,S08 管经验。安全撤退保留已入账成果;倒下执行部分钱物损失,由 S02 协调 S09、S07、S04 更新结果。
生命与体力关系、敌人行为与刷新、伤害和动作参数、奖励入账受阻处理、失败损失及日终中断顺序尚未明确。纳入实现范围前须补齐这些设计,并将系统文档@v2 的完整规则及实现规格收编进本册;当前要点不构成战斗施工规格。
实证参照:怪物 51 条配置拆 15 字段(HP/伤害/掉落对/防御/闪避/速度/经验…);受击 `max(1, 伤害−防御)`、450ms 基准无敌帧;伤害链顺序固定:roll→暴击→+攻击→职业→附魔→怪物防御(改序即改平衡);暴击乘区在 +Attack×3 之前(攻击力不吃暴击)。
## UI 交互规格
@@ -65,14 +75,15 @@
(实证参照:原作对话文本中 `$表情` 标记驱动立绘切换,六表情索引 0-5;钓鱼小游戏是唯一不暂停时间的菜单。)
## 来自 GDD 的功能(P0 七系统)
## 来自 GDD 的功能(首个日常原型)
| 系统 | 一句话职责 | 拥有的主数据 |
|---|---|---|
| S01 时间与日程 | 全局时钟与日终结算 | 日期、季节、天气、日程 |
| S01 时间与日程 | 全局时钟与日终协调 | 日期、季节、天气;居民日程归 S10 |
| S02 体力与状态 | 全局行动成本与恢复 | 体力、状态效果 |
| S03 农场经营 | 核心产出与规划场 | 地块、作物、设施 |
| S04 探索与地图 | 场景与空间约束 | 区域、连接、资源点 |
| S05 采集与钓鱼 | 本期基础采集,钓鱼后续加入 | 采集判定与获得物规则;资源点状态归 S04,物品入账归 S07 |
| S07 物品与制作 | 资源身份与转化 | 物品、配方、背包 |
| S08 成长与技能 | 长期回报层 | 经验、等级、解锁 |
| S09 经济与商店 | 投资与回报换算 | 价格、交易、库存 |
@@ -107,7 +118,7 @@
## 代码组织概览
- 承架构目录映射:`src/systems/s01_time/ … s12_events/`(每系统一目录:state/rules/api 三件);`src/scenes/` 场景注册;`src/core/` 循环、渲染、输入、存档。
- 本例代码采用 `src/systems/s01_time/` 等系统模块目录,仅为当前实现范围建立所需模块;`src/scenes/` 负责场景注册,`src/core/` 负责循环、渲染、输入、存档。这是 TDD 的实现选择,不由 `project/03_systems/...` 的文档目录决定。
- 入口 `main.ts` → 场景管理器(注册表制,场景切换走统一接口)。
- 边界约定:系统间只经公开 api 与事件总线通信,禁跨目录直改他人 state。
- 实证参照(原作,仅作组织参考):玩法逻辑全在一个 6.27MB 程序集,入口链 原生启动器→主 dll→GameRunner 帧循环(Update/Draw 非固定步长,真实毫秒累加器驱动逻辑);静态表/本地化文本/地图/运行状态/存档五类数据分置 Content、内存、Saves 目录,按需缓存加载。
@@ -124,9 +135,9 @@
| 项 | 规定 | 依据 |
|---|---|---|
| 瓦片地图结构 | 16px 网格;农场 80×65、小镇 50×40、矿井按层生成 | 台账 D-05(区域分场景,非连续地图) |
| 瓦片地图结构 | 16px 网格;农场 80×65、小镇 50×40;基础采集区域的数据待补齐,矿井属于后续范围 | 各区域独立场景,通过连接点切换,不构建连续地图 |
| 镜头 | 跟随玩家+边界钳制;无缩放(固定整数倍) | GDD 顶层(无镜头玩法) |
| 场景切换 | 农场↔小镇↔矿井走连接点淡入淡出 ≤1s | 概念 D-05 定案"分区域切换" |
| 场景切换 | 农场、小镇与基础采集区域通过连接点淡入淡出 ≤1s;矿井后续加入 | 分区域加载,限制单次加载范围 |
| 关卡数据 | `data/maps/*.json`(自定义 JSON:层/网格/对象点) | 契约 v2 |
## 输入与操作
@@ -159,14 +170,18 @@
| 版本 | 内容 | 判据 |
|---|---|---|
| v0.1 | S01/S02/S03/S07+S04 基础 | 一个游戏日"买种→播种→浇灌→收获→出售"全流程可完成并触发日终结算 |
| v0.2 | 矿井+战斗(S06)+成长(S08) | 矿井进出一次、遭遇一场、掉落入账、经验到 1 级(累计 100xp) |
| v0.3 | NPC+任务+商店(S09/S10/S11) | 修路任务全链可交付并解锁洒水器配方 |
| v0.1 | S01/S02/S03/S04/S05/S07/S08/S09 基础,加 UI 与存读档 | 单日农务与采集均可执行;连续数日完成作物生长、收获、出售与投资,出现基础成长;存读档后状态一致且无重复结算 |
| v0.2 | 矿井与战斗(S06)及配套地图、状态和成长能力 | 矿井进出一次、遭遇一场、掉落与经验正确入账,撤退或倒下的后果符合补齐后的规格 |
| v0.3 | NPC 与社区目标(S10/S11)及配套交易内容 | 代表性关系事件和社区目标可完成,奖励与解锁正确触发 |
## 开放问题回执
## 待解决问题
| # | 问题 | 去向 |
| 问题 | 影响 | 下一步与需更新的正文 |
|---|---|---|
| 1 | 背包格子还是重量容量(影响存档与 UI 结构) | → 概念层决策卡(B 级阻断,台账 D-15) |
| 2 | 矿井逐层生成是否本期做 | → 台账代决(建议 P2,GDD 已标"不做无限地牢";台账 D-16) |
| 3 | 体力是否与战斗共享单池 | → 台账 D-14(B 级待拍,暂按共享实现) |
| 基础采集与采集区域规格尚未收编完整 | v0.1 缺少必需能力,无法只凭 TDD 实现 | 补齐 S05 行为规格、S04 资源点交互、场景数据及数据分册中的获得物配置 |
| 跨日精确结算顺序尚未确定 | 影响成长、生产、出货及存档的一致性 | 补齐 S01 协调顺序及各系统输入输出,验证存读档后不重复结算 |
| 背包采用格子还是重量容量 | 决定物品容器、存档和 UI 结构 | 与用户确认后补齐 S07 行为规格、UI 交互规格及数据分册中的容量字段;目前的格子制是暂定方案 |
| 后续矿井采用何种地图组织与生成方式 | 影响 v0.2 的地图结构与关卡数据,不阻塞 v0.1 | 在矿井进入实现范围前明确,再更新场景与镜头、关卡数据及版本里程碑 |
| 体力是否与战斗共享单池 | 影响 S02、战斗成本及恢复规则 | 与用户确认后补齐相关系统行为规格和数据定义;目前共享单池是暂定方案 |
问题解决后将实际采用的规则写入对应正文,检查关联分册并移出待办;这些记录不能代替施工规格。
@@ -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 直接展示与探索发现的边界:先保证原型的关键行动与结果可理解,再结合试玩展开详细信息设计。
这些问题若改变当前范围或关键玩法,应回到受影响的正文调整,不能只留在问题清单中。
@@ -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. 画风卡引用必带版本;工艺沿用既有复用能力的工艺卡,不即兴写流程。
@@ -29,9 +29,8 @@ description: 写"数据与配表"(数据侧)分册时使用。与总纲(
## 二、动笔前
1. 输入齐了吗:各系统文档「数值与数据交接」节(订单——每系统交来哪些
数据类别与定性约束)、架构层主数据归属规则(写权分配)、统一数值基准
(架构层的定性基准,在本件落成前 N 日验算)。
1. 输入齐了吗:各系统的数据类别、已确定的规则参数与待补规格,以及架构中
的数据归属和共享约束。将这些信息落实为完整字段、配置和可执行的验算。
2. 先读两份提取件:字段字典全套规则与验收模板已在那里成文,本件是
项目实例化,不是重新发明。
3. 读取金样 exemplars/stardew-tdd-data.md 了解数据清单、验算表与验收结论包含的信息类型(同层只读一次)。
@@ -39,7 +38,7 @@ description: 写"数据与配表"(数据侧)分册时使用。与总纲(
## 三、怎么写(模板即流程,按节)
### 1. 数据表总清单
表格组 → 建议表名 → 主要维护系统。从各系统交接节汇总;声明"表格拆分
表格组 → 建议表名 → 主要维护系统。从各系统的实际规则、数据与已定参数汇总,不要求固定交接章节;声明"表格拆分
是生产组织方式,不改变主数据归属"。
### 2. 字段字典与 ID 命名规范
@@ -74,18 +73,19 @@ draft 调试可见/两 disabled 不加载、deprecated 留 ID 占位防复用)
种子,防读档刷结果。
### 6. 数值填充与验算
结构定稿后才填数。每项代决记台账(默认值+依据+推翻条件)。**前五日
闭环验算必做**:按架构统一数值基准排五日表(主目标/关键行动/成本/获得/
结果),加收益链校验(`区域→敌人→材料→配方→产出`逐环引 ID)——验算
结论写回:第 1 日不要求做完、奖励多元不单一、第 5 日出现取舍但仍留两条
可行路线。
结构定稿后才填数。实际数值、单位、适用范围和默认值写在本册配表与字段
契约中;重要取舍按需记分析。依据当前玩法、共享约束和验证问题选择验算
场景与跨度,记录关键行动、成本、获得和结果;检查实际存在的收益与消耗
关系及引用 ID。验算结果应支持对节奏、可达性和资源收支的判断,不预设
必须采用五日表或得出固定结论。
### 6.5 全量填充与内容完成度(自足性的数据侧保障)
结构定稿后的填充不是示例——是**全量**:数值表每表填满计划行数、文本表
(对话/提示/图鉴文案)逐行填满。这是"纯看 TDD 做完游戏"的数据前提:
程序加载表即得完整内容,不再回 GDD 找"这里应该有 8 种作物"。验收在七查
之外加第八查——**内容完成度**:每表计划行数 vs 实填行数,缺口列清单回填;
填数每项代决记台账。文本表由文本系统文档的文案收编(带版本锁)。
未决的填充缺口记明影响和下一步,解决后补齐配表并关闭待办。文本表由文本
系统文档的文案收编(带版本锁)。
### 7. 验收(七查+三级)
主键/引用/枚举/单位/范围五查必须过;业务规则/重复归属两查需设计师复核。
@@ -98,11 +98,11 @@ note 不阻断。验收记录表留 check_id 与 data_version。**结构、规
- 每张表答得出"谁是拥有者系统"吗?
- 任意单元格有没有"约/待定/多值拼一格"?
- 条件表是否全项目一个入口?程序求值器只需实现一次吗?
- 前五日验算跑过吗?收益链每一环的 ID 都存在吗?
- 当前范围的关键场景验算跑过吗?涉及的资源与配置 ID 都存在吗?
- 最近一次验收:blocker 清零了吗?
## 五、红线(承总纲四条,本件特化)
1. 表里不写散文;规则进契约文档。
2. 数值填充的每个代决都进台账,无痕改数=违规。
2. 数值变更同步更新本册配表、字段契约和受影响的验算;重要取舍按需记分析,不以外部台账替代施工数据。
3. 有 blocker 不许扩内容——没有例外。
@@ -15,7 +15,7 @@ description: 写"技术实现"(程序侧)分册时使用。与总纲(技
- **自包含**:TDD 开头"来自 GDD 的功能"节必带——读者不回翻 GDD 就能开工。
- **平台事实置顶且禁改**:自包含 Web、双视口、键鼠+触控、本地 HTTP 预览。
一切技术选择先过这道闸;GDD 里出现平台做不到的需求,回执上报,不硬做。
一切技术选择先过这道闸;GDD 里出现平台做不到的需求,记明问题、影响与下一步,涉及产品取舍时请用户确认,不硬做。
- **能力边界说三态**:native(原生支持)/ emulated(需模拟封装)/ gated
(本期不做,写明替代方案)——程序侧不许答应 GDD 做不到的事。
- **性能预算是基准不是完美**:每项指标写上限、写测量方式,当取舍依据用,
@@ -25,7 +25,7 @@ description: 写"技术实现"(程序侧)分册时使用。与总纲(技
## 二、动笔前
1. 输入齐了吗:架构层系统范围表+P0 清单(拆模块依据)、数据侧表结构契约
1. 输入齐了吗:架构层当前实现范围、职责与协作(拆模块依据)、数据侧表结构契约
(加载与校验要引用)、可复用能力选型(实现类需求先查现成能力,不自造轮子)。
2. 读总纲判断立场;本件在数据侧表结构定稿后开写。
3. 读取金样 exemplars/stardew-tdd-tech.md 了解技术实现文档包含的信息类型(同层只读一次)。
@@ -33,10 +33,10 @@ description: 写"技术实现"(程序侧)分册时使用。与总纲(技
## 三、怎么写(模板即流程,按节)
### 0. 系统行为规格(收编章——本件的灵魂)
每个 P0 系统一节,**收编**该系统文档的「玩家行动/状态与规则/反馈需求」
三节全文(标注"基于系统文档@v{N}")。施工方 只读这里就该知道这个系统
怎么行为——不需要回 GDD。P1 系统收编一句话职责+开放状态,施工到该系统时
补收编。收编节只同步不改写:GDD 变了重同步,TDD 不在这里加观点。
按当前实现范围**收编**各系统的玩家行动、状态与规则、反馈需求等行为规格,
标注来源版本(如"基于系统文档@v{N}")。施工方只读这里就应知道当前范围
怎么实现,不需要回 GDD。后续范围可以保留职责与未决事项,纳入施工范围前
必须补齐规格。GDD 变更时同步受影响的收编内容,不能只更新范围清单。
### 0b. UI 交互规格(收编+落地章)
界面清单(每个界面一行:HUD/背包/商店/对话/结算面板…)+ 每界面的元素、
@@ -44,7 +44,7 @@ description: 写"技术实现"(程序侧)分册时使用。与总纲(技
规则在此落位(与圣经 UI 节同源)。
### 1. 来自 GDD 的功能
摘录系统范围表与 P0 清单,一行一系统。只摘,不评——评价回 GDD。
列出当前实现范围的系统与能力,承接架构中的职责、协作和数据归属。
### 2. 技术目标与平台事实
平台事实原样置顶(禁改);技术目标写可测量的两三条(如"首屏可玩≤N 秒")。
@@ -62,15 +62,17 @@ HTML 的 Canvas/WebAudio/localStorage)、**自封装**(基础 API 上自己
引擎项目按所选引擎的预览与导出流程验证。
### 5. 代码组织概览
承架构层目录映射:入口、场景、系统模块的文件组织,一图或一段写死。
根据职责与实现需求确定入口、场景、系统模块的代码组织;架构中的系统文档
目录不等于代码目录。用图或文字写清实际文件位置与模块关系。
命名与模块边界约定写清(面向生成代码的可读性:谁在哪个目录、什么前缀)。
### 6. 外部依赖与可复用能力
实现类需求先查可复用能力;记录来源、适用版本与实例化参数;没有现成能力时写明来源与理由。
### 7. 场景与镜头 / 输入与操作 / 音频
三节各一张表:场景(tilemap 结构/镜头行为,代决记台账);输入(动作×
键盘×触控对照);音频(用途×格式规格×触发点×依据)。
三节各一张表:场景(tilemap 结构/镜头行为,规格和参数写全);输入(动作×
键盘×触控对照);音频(用途×格式规格×触发点×依据)。各项实现默认值
也写在对应正文,重要取舍按需记分析,不让施工方依赖外部台账。
### 8. 构建与验证
构建流程 + 验证分级:自动(什么命令、什么输出为过)、半自动(双视口
@@ -88,6 +90,6 @@ HTML 的 Canvas/WebAudio/localStorage)、**自封装**(基础 API 上自己
## 五、红线(承总纲四条,本件特化)
1. 平台事实禁改;与 GDD 冲突走回执,不就地硬做。
1. 平台事实禁改;与 GDD 冲突时说明影响和下一步,涉及产品取舍时请用户确认并同步 GDD。
2. 可复用能力引用必带版本与参数。
3. 里程碑判据不许写"基本""大致""感觉"。
@@ -1,31 +1,11 @@
### C2 01_核心玩法编排/SKILL.md(→ modules/system-types/01_核心玩法编排/SKILL.md)
# 核心玩法编排
---
name: gdd-sys-01-orchestration
description: 写"核心玩法/日循环编排"类系统文档时使用。与 skills/systems.md
配套(通用纪律不在此重复)。配套模板:modules/system-types/01_核心玩法编排/模板.md。
---
当玩法需要跨系统组织玩家目标、行动与阶段推进时,参考本类型;单一系统已能完整表达的玩法无需另设编排层。
# 核心玩法编排 · 系统写法
- 说明玩家如何获得目标信息、选择行动、根据结果调整计划,以及何时进入下一阶段。阶段可以是回合、关卡、一天或项目实际采用的其他单位。
- 写清编排自身实际拥有的状态、状态变化与恢复方式。它可以拥有目标、进度、阶段等正式状态;其他系统的数据按实际权威来源读取或接收结果。
- 描述跨系统动作的触发、顺序、失败处理和结果去向,让实现者能区分编排规则与各系统内部规则。
- 玩家是否有有意义的选择、是否需要取舍,应由本项目的核心体验决定;取舍、反馈和依赖只写实际存在的机制。
- 已确定的参数与字段可以保留。技术设计需收编这些约束并补齐可实现的规格,职责和数据归属以项目架构为准。
**定位**:把各系统粘成"一天/一局"的编排层,自己几乎不拥有内容。
## 本类型要点
- 系统目的:写"若删除它,日循环崩解为无关小游戏"。
- 支撑体验三件:安排空间明确但无唯一解;资源有限使选择有意义;
可依新信息调整计划。
- 进入与退出三入口必写:新档日初、读档恢复、特殊事件后返回常规循环。
- 玩家行动:写"安排"类动词(定当日目标/选携带/执行/调整),
**不写具体生产动作**——那是各内容系统文档的事。
- 状态与规则:只写"编排态"(日期/位置/体力/当日已完成),
**不写任何内容公式**。
- 数值与数据交接:数据类别表加第四列「提供方/消费方」——本类型只做
路由,数据字段全部来自别家,此表证明它不拥有内容。
- 边界三不:不定义作物/敌人/钓鱼/好感公式;不拥有内容表;
不管渲染动画——三条写全。
- 典型开放问题:中途存档?结束一天的位置?昏倒影响范围?
## 本类型自查
- 全文有没有出现任何一条内容公式?(出现即越权)
- 提供方/消费方列填全了吗——有没有数据其实没有来源系统?
- 删掉本系统,玩家真的会"不知道今天干嘛"吗?不是的话它是伪编排层。
检查:跨系统流程中的推进、结算与恢复是否有明确负责方,是否重复维护了其他系统的状态?
@@ -1,73 +1,15 @@
### C2 01_核心玩法编排/模板.md(→ modules/system-types/01_核心玩法编排/模板.md)
# __系统:S__(核心玩法编排类)
## 系统目的
(本系统存在是为了 __;若删除它,日循环崩解为 __。)
按实际玩法选取内容,不为填满模板增设阶段、状态或依赖。
## 支撑的玩家体验
- 安排空间明确但无唯一解:__。
- 资源有限使选择有意义:__。
- 可依新信息调整计划:__。
(对应顶层设计目标第 __ 条。)
## 玩家目标与编排流程
(玩家从哪里得到目标,如何选择、执行、调整,以及什么条件推进到下一阶段?)
## 进入与退出
### 进入
- 新档日初:__。
- 读档恢复:__。
- 特殊事件后返回常规循环:__。
### 退出
- __
## 状态与关键规则
(本系统实际拥有的状态、转换、结算和恢复;跨系统动作的先后与失败处理。保留已确定的参数。)
## 玩家行动
- 定当日目标:__。
- 选择携带:__。
- 执行:__。
- 调整:__。
## 系统协作与反馈
(实际输入、输出、权威数据来源和玩家能看到的进展或结果。)
## 取舍表
| 决策 | 立即收益 | 延迟收益 | 主要代价 |
|---|---|---|---|
| __ | __ | __ | __ |
## 状态与规则
### 编排态
- 日期与时段:__。
- 玩家位置:__。
- 体力余量:__。
- 当日已完成/未完成:__。
## 数值与数据交接(→技术文档层)
| 数据类别 | 作用 | 提供方 | 消费方 |
|---|---|---|---|
| __ | __ | __系统 | __系统 |
随交接附下的设计侧定性约束:
- __
## 反馈
- __
## 内部循环
`日初信息确认 → 目标选择 → 执行与调整 → 日终结算 → 下一天`
## 输入、输出与依赖
### 输入
- __系统提供 __。
### 输出
- 向__系统提供 __。
### 依赖
- __
## 边界与非目标
- 不定义 __/__/__ 的内容公式 → 移交 __。
- 不拥有内容表。
- 不管渲染动画 → 移交呈现层。
- 不负责字段定义、数值配置与表格结构——归技术文档层(数值策划)。
## 开放问题
- 中途存档的粒度?
- 结束一天时玩家位于何处?
- 昏倒的影响范围?
## 待定设计
(只记录影响实现或体验的未决问题及需要验证的取舍。)
@@ -1,25 +1,10 @@
### C2 02_时间与日程/SKILL.md(→ modules/system-types/02_时间与日程/SKILL.md)
# 时间与日程
---
name: gdd-sys-02-time-schedule
description: 写"时间与日程"类系统文档时使用。与 skills/systems.md 配套。
配套模板:modules/system-types/02_时间与日程/模板.md。
---
玩法存在时间推进、暂停、恢复或时间窗口时,参考本类型。时间单位和节奏由玩法决定,不预设昼夜、季节或日终。
# 时间与日程 · 系统写法
- 说明时间如何表示和推进,哪些动作、事件或运行状态使它暂停、跳转或恢复;已有时长与换算参数可以保留。
- 说明时间窗口如何判定、开放与关闭,以及玩家从哪里得知当前状态和不可用原因。窗口可以由本系统或相应活动系统维护,按实际架构明确协作关系。
- 涉及存档、跨阶段或离线推进时,写清恢复后的时间及待处理事件如何确定。
- 活动耗时、居民日程、营业规则等按实际职责归属,不在本类型中预设统一拥有者。技术设计需收编已定规则与参数,补齐实现规格。
**定位**:世界时钟 + 开放窗口的唯一真源。
## 本类型要点
- 状态与规则:配置基准定性写清(时间片/日结构/季长/年结构各自的
设计意图);具体数值进 TDD 的配置基准表,本层只定结构与意图。
- 反馈三件套:HUD 持续显示 + 阈值预告(商店将关/日终将至)+
**不可用必给具体原因**("尚未开放/已关闭/今天不营业",不许只灰按钮)。
- 与架构层"统一数值基准"逐条对齐:1 日=多少时间片、一天应完成几件事的
量级感在本层说清,数值给 TDD。
- 边界:不负责活动本身的时间成本(只接收并推进已验证请求);
不模拟真实天文(潮汐/星象之类不做)。
## 本类型自查
- 每个开放窗口(营业/季节/节日)都有"何时开、何时关、关了怎么说"三答吗?
- 有没有任何活动的时间成本被写进了本系统?(该在活动系统里)
检查:同一时间点的可用性和推进结果是否可判定,暂停与恢复是否会重复或漏掉关键事件?
@@ -1,69 +1,15 @@
### C2 02_时间与日程/模板.md(→ modules/system-types/02_时间与日程/模板.md)
# __系统:S__(时间与日程类)
## 系统目的
(本系统存在是为了 __;若删除它,__。)
按实际时间机制选取内容,不预设日、季节或特定开放窗口。
## 支撑的玩家体验
(对应顶层设计目标第 __ 条。)
- __
## 时间结构与推进
(时间单位、推进来源、速度或消耗;暂停、跳转和恢复的条件。保留已确定的参数。)
## 进入与退出
### 进入
- 游戏启动/读档时恢复时间状态:__。
### 退出
- __(时间系统通常常驻;写清唯一停摆场景,如暂停菜单)
## 时间窗口与事件
(适用窗口的开放和关闭判定、冲突处理、错过后的结果,以及玩家得到的提示。)
## 玩家行动
- 查看时间/日期/季节:__。
- 查看日程与开放窗口:__。
## 状态与协作
(时间状态由谁持有,其他系统提供什么条件、读取什么结果;存档恢复或跨阶段如何处理。)
## 取舍表
| 决策 | 立即收益 | 延迟收益 | 主要代价 |
|---|---|---|---|
| __ | __ | __ | __ |
## 状态与规则
### 配置基准(定性,数值归技术文档层)
- 时间片结构:__(设计意图:__)。
- 日结构:__。
- 季长与年结构:__。
### 开放窗口规则
- 营业时段:__(开/关/关闭原因表达)。
- 季节窗口:__。
### 推进规则
- 时间随已验证的行动请求推进:__。
- 日终触发条件:__。
## 数值与数据交接(→技术文档层)
本系统交由技术文档层定义的数据类别:日期季节表、天气表、日程表、营业时段表。
随交接附下的设计侧定性约束:
- 一天应完成的量级:__(如一个主目标+一个外出目标+少量顺路)。
- 早期玩家不应因时间误算失去整天进度。
## 反馈
- HUD 持续显示:__。
- 阈值预告:__(商店将关/日终将至)。
- 不可用原因:__(尚未开放/已关闭/今天不营业)。
## 内部循环
`行动请求 → 时间推进 → 窗口变化 → 日终结算 → 下一天`
## 输入、输出与依赖
### 输入
- 各活动系统提供已验证的行动耗时请求。
### 输出
- 向全部系统提供当前日期/时段/季节/天气与跨天 tick。
### 依赖
- __
## 边界与非目标
- 不负责活动本身的时间成本 → 移交各活动系统。
- 不模拟真实天文(潮汐/星象)。
- 不负责字段定义、数值配置与表格结构——归技术文档层(数值策划)。
## 开放问题
- __
## 待定设计
(只记录影响节奏或实现的未决规则。)
@@ -1,28 +1,10 @@
### C2 03_生产种植经营/SKILL.md(→ modules/system-types/03_生产种植经营/SKILL.md)
# 生产种植经营
---
name: gdd-sys-03-farm-production
description: 写"生产/种植经营"类系统文档时使用。与 skills/systems.md 配套。
配套模板:modules/system-types/03_生产种植经营/模板.md。
---
玩法存在投入、加工、培育或周期性产出时,参考本类型。地块、作物、设施、动物和自动化都由具体项目选择。
# 生产种植经营 · 系统写法
- 说明生产对象、玩家投入、等待或维护、产出与再投入之间的关系;让玩家知道选择带来的收益、成本和时间差。
- 对实际存在的生产对象写清状态、转换条件、异常结果和中断后的恢复。状态可以按地块、作物、设施或其他对象组织,不套用固定状态列表。
- 说明投入如何被占用或消耗,产出如何判定、领取与进入后续系统;相关物品身份、容量、价格和时间由实际权威系统决定。
- 反馈应让玩家看懂当前进度、可操作条件和结果。已有产量、时长、品质等参数可以保留,并由技术设计收编、补齐实现规格。
**定位**:把土地/设施变成周期性产出的规则层。
## 本类型要点
- 状态与规则用**状态机写法**,逐对象写全转换:
地块(地形/开垦/湿度/生长阶段)、作物(生长→成熟→再生/枯萎的转换
条件)、设施(空闲/生产中/可取出)。
- 数据交接的关键定性声明:作物主表必须体现"种子与收获物是两个物品 ID"
的引用结构(生产系统不定义物品,只引用)。
- 反馈:地块状态图标(水分/阶段/可收/异常)+ 设施队列状态——
周期性产出的可读性全靠状态外显。
- 边界三不:不管背包/堆叠/售价;不管工具升级全树(只读条件);
不做动物 AI。
- 典型开放问题:维护复杂度(只浇灌 vs 肥力病害)?动物进首版吗?
自动化省什么、不省什么?
## 本类型自查
- 每种作物从种到收的完整转换链画全了吗(含异常分支:枯萎/季节截断)?
- 自动化收益有没有越线(让玩家跳过全部农场决策)?
检查:一次生产从投入到结果能否追踪;失败、中断或重复领取会怎样处理?
@@ -1,73 +1,15 @@
### C2 03_生产种植经营/模板.md(→ modules/system-types/03_生产种植经营/模板.md)
# __系统:S__(生产种植经营类)
## 系统目的
(本系统存在是为了 __;若删除它,__。)
按实际生产机制选取内容,不预设种植、畜牧或设施都存在。
## 支撑的玩家体验
(对应顶层设计目标第 __ 条。)
- __
## 生产过程与玩家选择
(生产对象、投入、维护或等待、产出与再投入;玩家面对的实际取舍。)
## 进入与退出
### 进入
- 进入农场/生产区域:__。
### 退出
- 离开区域/日终作物状态保持:__。
## 状态与产出规则
(对象状态、转换条件、中断或异常、产出判定与领取;保留已确定的参数。)
## 玩家行动
- 开垦:__。
- 播种:__。
- 浇灌/维护:__。
- 收获:__。
- 设施操作:__。
## 协作与反馈
(投入和产出的权威来源与去向;玩家如何看到进度、条件和结果。)
## 取舍表
| 决策 | 立即收益 | 延迟收益 | 主要代价 |
|---|---|---|---|
| __ | __ | __ | __ |
## 状态与规则
### 地块状态机
- 状态:未开垦 / 已开垦 / 已种植 / __。
- 转换:__ → __(条件:__);异常分支:__。
### 作物状态机
- 状态:生长 / 成熟 / 再生 / 枯萎。
- 转换:__(条件:浇水/时间片/季节);季节截断规则:__。
### 设施状态机
- 状态:空闲 / 生产中 / 可取出。
- 转换与时长结构:__。
## 数值与数据交接(→技术文档层)
本系统交由技术文档层定义的数据类别:作物主表、设施表、动物表。
定性声明:作物主表必须体现"种子与收获物各引一个物品 ID",生产系统不定义物品。
随交接附下的设计侧定性约束:
- __(如:维护复杂度上限、自动化省体力不省决策)
## 反馈
- 地块状态图标:水分 / 阶段 / 可收 / 异常。
- 设施队列状态:__。
## 内部循环
`开垦 → 播种 → 维护 → 等待 → 收获 → 再投入`
## 输入、输出与依赖
### 输入
- 时间系统提供跨天 tick;物品系统提供种子与工具;体力系统扣行动成本。
### 输出
- 向物品系统提交收获物入账。
### 依赖
- __
## 边界与非目标
- 不管背包/堆叠/售价 → 移交物品与经济系统。
- 不管工具升级全树(只读成长系统条件)。
- 不做动物 AI。
- 不负责字段定义、数值配置与表格结构——归技术文档层(数值策划)。
## 开放问题
- 维护复杂度:只浇灌还是加肥力病害?
- 动物进首版吗?
- 自动化省什么、不省什么?
## 待定设计
(只记录影响生产闭环的未决规则。)

Some files were not shown because too many files have changed in this diff Show More