82 lines
6.8 KiB
Markdown
82 lines
6.8 KiB
Markdown
# 存档系统需求
|
||
|
||
> 本文档为**需求层**文档，只描述"存档系统要做成什么样、对玩家承诺什么"，不涉及具体实现与数据结构。实现方案、数据结构等待需求确认后另行讨论。
|
||
|
||
## 一. 背景
|
||
|
||
本游戏是一个赛博医生题材的视觉小说游戏。游戏中不同患者有公共的插件检修和各种定制的检修玩法。
|
||
|
||
本项目中使用 YarnSpinner 作为剧情插件，已更新到 3.2 版本。
|
||
|
||
项目中原来有存档系统，仅有自动存档；读取时从章节选择进入，且仅能读到最新的一份。这套存档系统是很早期设计的，现在问题已经非常大、无法正常使用。**新方案不沿用旧实现的恢复锚点、存档文件组织等不可靠部分**；旧系统中仍可靠的底层能力（Yarn 变量存取、用于承接深度维修状态的数据容器等）在后续实现阶段再评估复用。
|
||
|
||
## 二. 设计总则
|
||
|
||
这几条是贯穿整套存档系统的约定，作为后续所有细节设计的前提。
|
||
|
||
1. **所见即所存**：读档后玩家看到的画面与状态，等于"**进入该可存节点那一刻**"的画面与状态。注意基准是"进入节点那一刻"，而**不是**玩家退出游戏那一刻——玩家不能精确回到退出瞬间。
|
||
2. **存档点是离散的、节点级的**：进度只在"可存节点"上落点。两个存档点之间的内容（一段对话播放途中、一段演出途中、一段深度维修途中）若退出，则会丢失，下次从上一个存档点重新开始。这是明确的体验约定，需在设计中被接受、而非视作缺陷。
|
||
3. **落盘可靠性**：自动存档在"进入可存节点"时即完成写盘，保证崩溃 / 断电情况下最多只丢失到上一个存档点。
|
||
|
||
## 三. 存档
|
||
|
||
### 1. 存档时机
|
||
|
||
由于 YarnSpinner 机制限制，无法从某一行直接开始；另外由于检修玩法复杂，很难随时记录状态并恢复。因此采用**进入节点时自动保存**。
|
||
|
||
手动存档不单独记录运行时状态，而是**保存最近一次自动保存的那份存档**（即把最近的自动存档点固化到一个手动档位）。
|
||
|
||
自动存档过程中是否给玩家可见反馈（保存图标 / 提示），**待定**。
|
||
|
||
### 2. 可存档范围
|
||
|
||
分情况讨论：
|
||
|
||
1. **诊所内维修**：仅在诊所中的对话和插线维修时保存；每个角色各自的深度维修过程中**不保存**。但深度维修可能会记录一些**阶段终点状态**，以处理"多段深度维修中间穿插诊所对话"的情况。维修 Yarn 的节点类型与**瞬跳节点**规则见 [Yarn 维修节点类型规范 §8](Yarn维修节点类型规范.md#8-瞬跳节点与存档边界)：`center` 及所有瞬跳节点不可存；默认可存的 `content` 若仅为路由/状态检查，须标 `no_save`。
|
||
2. **诊所外对话**（天桥、酒吧、诊室外等）：每个节点都保存。
|
||
3. **梦境状态**：情况较复杂，此时 Yarn 结构遵循 [Yarn 节点类型规范](Yarn节点类型规范.md)。在这种情况下，`hub` 节点与 `linear` 节点保存，`detour` 节点与 `function` 节点不保存。
|
||
|
||
> 说明：上述各情况"如何在运行时被判定"属于实现细节，后续讨论。需求层只约定"哪些时机算可存点"。
|
||
|
||
### 3. 存档内容
|
||
|
||
存档恢复遵循总则"所见即所存"。下面按**技术分类**列出存档应覆盖的内容范围（每一类的具体数据结构与还原方式后续单独讨论）：
|
||
|
||
1. **宏观阶段 / 状态**：包括但不限于场景、YarnProject、（部分情况下）FixState 等标志着当前游戏重要阶段的内容。
|
||
2. **表现类**：包括但不限于 UI 层的演出工具（UI 遮罩等）、环境状态、角色动画、Timeline 状态等。这些是大部分情况下都会出现在场景里的东西，内容和结构相对稳定，且严重影响当前状态的视觉展现。
|
||
3. **深度维修状态**：深度维修不需要做到每一刻都能保存或复原；只要能做到"一个大阶段完成后可以保存和复原"即可。部分深度维修**可以完全不做保存**（读档时回到进入该维修之前的存档点）。哪些深度维修支持阶段存档、哪些不支持，**待定（需逐个梳理清单）**。
|
||
4. **YarnSpinner 变量**：较清晰，可直接保存。
|
||
|
||
> 表现类状态究竟是"逐项还原"还是"读档时由该节点重新演出来还原"，属于数据结构层面的讨论，留待后续；本节只确定"所见即所存"这一对外承诺。
|
||
|
||
### 4. 档位设置
|
||
|
||
初步打算是**一个自动保存档位 + 多个手动保存档位**。
|
||
|
||
以下细节**待定**：自动档是单份覆盖还是保留多份滚动备份；手动档数量上限；手动档能否覆盖 / 删除 / 重命名；存档槽位在选择界面展示哪些信息（截图、章节标题、进度描述、真实时间、版本号等）。
|
||
|
||
### 5. 读档
|
||
|
||
可以从"继续游戏"读取最近的存档，也可以在存档选择界面选择自动存档或某个手动存档来读档。
|
||
|
||
以下细节**待定**："继续游戏"具体指向哪一份（最近自动档，还是最近的自动 / 手动档）；游戏进行中读档是否允许、是否二次确认。
|
||
|
||
## 四. 其他需求
|
||
|
||
1. **不可存时段与保存按钮置灰**：当前不处于可存档状态时，手动保存按钮置灰。典型为**深度维修过程中**（按设计这部分不能存档）。注意：**首次启动不置灰**——刚启动就会进入第一个节点，此时一般已经完成了自动保存，因此正常情况下总有可用的自动存档。
|
||
2. **设置数据与存档分离**：音量、画质、分辨率、语言、对话推进模式（自动 / 快进）等全局设置**不进入存档槽**，独立持久化，不随读档回滚。
|
||
3. **本地化跟随当前语言**：存档记录的是行 ID 等本地化引用而非最终文本，读档后对话文本 / 语音按**当前语言设置**显示，而不是存档时的语言。
|
||
4. **Steam 云存档**：需要支持 Steam 云存档 / 多机同步（存档目录规划与文件组织需为此预留）。
|
||
5. **不做防篡改**：作为叙事向单机游戏，存档不做加密 / 校验，允许玩家修改存档。
|
||
|
||
## 五. 待后续确定的事项（TODO）
|
||
|
||
- 自动档 / 手动档的数量、覆盖、删除、重命名规则。
|
||
- 存档槽位选择界面展示的字段（含是否截图）。
|
||
- "继续游戏"指向哪一份存档；游戏中读档是否允许及确认流程。
|
||
- 新游戏与既有存档的关系（是否覆盖 / 清空、是否需要覆盖确认）。
|
||
- 全局 / 跨周目数据（章节解锁、已读、画廊、成就等）与单局存档的边界划分。
|
||
- 各深度维修是否支持阶段存档的逐个清单。
|
||
- 自动存档是否需要可见反馈。
|
||
- 表现类状态的还原方式（逐项还原 vs 重进节点重演）——并入数据结构讨论。
|