_001.png){kind=small}
节点结果易断链
地图如果只展示入口，战斗、事件、奖励和回地图推进就很容易各自保存状态。
OracleAbyss 单局内容写回链
案例研究 / system-design
OracleAbyssRunState奖励确认单局闭环
我把 GameFlow、地图节点、战斗/事件结果、奖励确认和 RunState 写回组织成单局内容写回链，让内容结果先被玩家确认，再进入下...
_001.png)
项目阶段
原型
_001.png)
负责人
苏阿酥
协作团队
个人项目
摘要
我把 GameFlow、地图节点、战斗/事件结果、奖励确认和 RunState 写回组织成单局内容写回链，让内容结果先被玩家确认，再进入下一步地图状态。
_001.png)
系统定位
单局内容写回链，负责把节点结果、奖励确认和真实状态推进拆清楚。
_001.png)
项目类型
卡牌 Roguelite 竖向 demo，用玩家可见流程验证内容、奖励和地图推进。
_001.png)
证据口径
以 FinalGDD、项目页面、战斗系统方案和公开测试记录证明，不补写未公开内部字段。
设计问题
奖励容易串线
战斗或事件若直接发奖励，预览、候选、确认和已拥有状态会混在一起。
写回责任分散
Map、Battle、Reward 如果都能改最终状态，后续很难判断资源、牌组或神明状态是谁写坏的。
影响不可见
如果回地图后看不见刚才结果对路线、资源或神明反馈的影响，单局闭环就只停在后台状态。
设计目标
提升节点可预览
≥ 先展示
地图负责风险、倾向、内容引用和可达状态，不直接写最终结果。
提升结果可隔离
≥ 先候选
战斗或事件产出候选结果，避免奖励、资源和牌组提前串线。
提升奖励可确认
≥ 再领取
领取、跳过、替换和确认由统一结算层处理。
提升状态可推进
≥ 回地图
RunState 写回后，玩家能回到地图看见下一步路线和状态变化。
我的方案
阶段一·定义
01
流程路由入口
用 GameFlow 统一承接开局、地图、战斗、事件、奖励和回地图的流程切换，避免每个模块自行决定下一步。
_001.png){kind=small}
02
地图只做预览
地图节点只声明可达性、风险、神明倾向和内容引用，让玩家先理解选择，不在地图层直接改奖励或牌组。
03
内容产出候选
战斗或事件只输出战斗结果、事件结果、资源变化和奖励候选，让内容结果先停在可确认层。
阶段二·执行
04
奖励统一结算
用奖励结算层处理领取、跳过、替换和确认，保证候选奖励和真实拥有状态不混用。
05
RunState 写回
RunState 作为单局真相源，统一接收节点历史、资源、牌组、神明状态和奖励历史的最终变化。
06
神明反馈挂接
把写回后的行为证据和状态变化交给神明反馈链解释，让奖励、惩罚或原因摘要能追溯到刚才的选择。
阶段三·验证
07
回地图推进
回到地图时重新读取 RunState，刷新可达节点、资源状态、神明提示和后续风险，让玩家看见结果影响。
08
差异验收入口
验收时检查预览、候选、确认、已拥有和写回后的差异，定位问题来自节点、内容、奖励还是状态写回。
策略要点
先分层再扩内容
先把预览、候选、确认和已拥有状态拆开，再扩大事件、遭遇和奖励数量，避免内容越多越难查错。
先确认再写回
把玩家确认作为写回前置条件，避免战斗或事件直接污染真实拥有状态，保留跳过和替换空间。
先验玩家可见链
正式验收优先走玩家可见 UI，再用调试工具定位差异，避免只证明后台状态能跑通。
关键产出
_001.png){kind=small}
写回链路说明
形成从开局、地图、战斗或事件、奖励确认、RunState 写回到回地图推进的流程说明。
_001.png){kind=small}
模块职责边界
整理 GameFlow、地图、战斗/事件、奖励结算、RunState 和神明反馈各自负责什么、不能越界写什么。
_001.png){kind=small}
奖励状态规则
沉淀预览、候选、领取、跳过、替换、确认和已拥有之间的状态规则，证明奖励不会提前串线。
_001.png){kind=small}
RunState 清单
列出节点历史、资源、牌组、神明状态和奖励历史等写回对象，用于检查真实状态是否由同一入口承接。
_001.png){kind=small}
玩家验收路线
保留主菜单、神明注视、地图、战斗或事件、奖励确认、写回和回地图的玩家可见检查路径。
数据反馈
流程段落
8步↑
主菜单、神明注视、地图、战斗或事件、原因摘要、奖励确认、RunState 写回、回地图。
状态分层
4层↑
预览、候选、确认、已拥有，避免内容结果提前污染真实状态。
写回对象
5项↑
节点历史、资源、牌组、神明状态和奖励历史。
节点范围
6类↑
FinalGDD demo 范围覆盖地图、战斗、事件、祭坛、商店、休整等内容类型。
公开配置记录
39表/43事件/25遭遇↑
作为已公开历史验证材料保留，不覆盖 FinalGDD 的 demo 范围口径。
测试覆盖
58项↑
沿用公开记录中的 45 项 EditMode 与 13 项 PlayMode 验证口径。
复盘
这条链路让我确认，内容配置数量不是核心，关键是结果能否被玩家确认并稳定进入下一步单局状态。
后续应继续补奖励跳过、替换失败、重复进入、节点回退和写回失败等边界验收。
下一轮可以把写回前后的节点、资源、牌组和神明状态差异做成调试视图，降低定位成本。
_001.png)