aibis-dream/Docs/存档系统需求.md

存档系统需求

本文档为需求层文档，只描述"存档系统要做成什么样、对玩家承诺什么"，不涉及具体实现与数据结构。实现方案、数据结构等待需求确认后另行讨论。

一. 背景

本游戏是一个赛博医生题材的视觉小说游戏。游戏中不同患者有公共的插件检修和各种定制的检修玩法。

本项目中使用 YarnSpinner 作为剧情插件，已更新到 3.2 版本。

项目中原来有存档系统，仅有自动存档；读取时从章节选择进入，且仅能读到最新的一份。这套存档系统是很早期设计的，现在问题已经非常大、无法正常使用。新方案不沿用旧实现的恢复锚点、存档文件组织等不可靠部分；旧系统中仍可靠的底层能力（Yarn 变量存取、用于承接深度维修状态的数据容器等）在后续实现阶段再评估复用。

二. 设计总则

这几条是贯穿整套存档系统的约定，作为后续所有细节设计的前提。

1. 所见即所存：读档后玩家看到的画面与状态，等于"进入该可存节点那一刻"的画面与状态。注意基准是"进入节点那一刻"，而不是玩家退出游戏那一刻——玩家不能精确回到退出瞬间。
2. 存档点是离散的、节点级的：进度只在"可存节点"上落点。两个存档点之间的内容（一段对话播放途中、一段演出途中、一段深度维修途中）若退出，则会丢失，下次从上一个存档点重新开始。这是明确的体验约定，需在设计中被接受、而非视作缺陷。
3. 落盘可靠性：自动存档在"进入可存节点"时即完成写盘，保证崩溃 / 断电情况下最多只丢失到上一个存档点。

三. 存档

1. 存档时机

由于 YarnSpinner 机制限制，无法从某一行直接开始；另外由于检修玩法复杂，很难随时记录状态并恢复。因此采用进入节点时自动保存。

手动存档不单独记录运行时状态，而是保存最近一次自动保存的那份存档（即把最近的自动存档点固化到一个手动档位）。

自动存档过程中是否给玩家可见反馈（保存图标 / 提示），待定。

2. 可存档范围

分情况讨论：

1. 诊所内维修：仅在诊所中的对话和插线维修时保存；每个角色各自的深度维修过程中不保存。但深度维修可能会记录一些阶段终点状态，以处理"多段深度维修中间穿插诊所对话"的情况。维修 Yarn 的节点类型与瞬跳节点规则见 Yarn 维修节点类型规范 §8：center 及所有瞬跳节点不可存；默认可存的 content 若仅为路由/状态检查，须标 no_save。
2. 诊所外对话（天桥、酒吧、诊室外等）：每个节点都保存。
3. 梦境状态：情况较复杂，此时 Yarn 结构遵循 Yarn 节点类型规范。在这种情况下，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 重进节点重演）——并入数据结构讨论。