OracleAbyss

个人练习2026-05-17 更新

OracleAbyss 是一个卡牌 Roguelite 垂直切片系统设计案例，围绕神明介入、局内决策反馈和配置驱动内容管线，展示我如何把玩家行为、神明态度、地图节点、战斗奖励和可验证数据结构组织成可扩展闭环。

项目类型卡牌 Roguelite demo

项目周期2026

平台Unity 垂直切片

展示范围FinalGDD 系统案例

职责摘要体验 / 反馈 / 闭环 / 验证

项目背景

01OracleAbyss 不是为了证明“能做一个随机爬塔”而建立的项目，而是把成熟的节点式爬塔、回合制卡牌、局内构筑和事件选择作为底座，用来验证一套更有辨识度的神明介入体验。
02FinalGDD 将核心体验定义为“由神明主持的试炼”：玩家需要在 10 分钟内理解当前是哪位神明主持本局，并能说出至少一个触发神明反馈的原因。路线、战斗、事件选项、资源取舍和风险承担，都会被解释为神明判断玩家的行为证据。
03因此，神明反馈、地图节点推进、战斗神令、奖励结算和配置驱动不能分散处理。它们必须统一进入 RunState、行为标签、favor / wrath、奖励历史和原因反馈链路，才能让玩家感到“刚才的选择真的被记住了”。
04当前展示边界是卡牌 Roguelite 竖向 demo / 最终 GDD 级系统案例：优先证明战争之神路线、可玩闭环、信息透明和配置可扩展性，不包装成完整商业体量卡池、遗物池或最终平衡版本。

设计目标

理解神明主持体验验证玩家能否在短时间内理解当前是哪位神明主持本局，以及本局规则为什么不只是普通随机路线。
解释玩家行为证据验证路线选择、战斗打法、事件选项、资源取舍和风险承担能否被转成可追溯的行为标签与反馈原因。
让神令改变战斗策略验证战斗中的神令是否至少一次改变玩家出牌顺序、攻击目标或风险判断，而不是只停留在战斗外叙事。
形成节点推进节奏验证地图节点、事件、祭坛、商店、休整和战斗能否让玩家在路线价值、神明态度和当前资源之间做综合判断。
闭合战斗奖励写回验证战斗、非战斗结果和奖励候选能否经过 Reward Settlement 与 RunState 写回，避免奖励预览、候选和真实拥有状态混在一起。
支撑配置扩展与验收验证地图、卡牌、敌人、事件、奖励、神明反馈和语言 key 能否由配置承载，并通过校验与人工路线证明链路稳定。

我的职责

核心体验与设计目标定义主导把项目从普通卡牌 Roguelite 描述收束为“神明主持试炼”的系统案例，明确 10 分钟理解、反馈原因、神令改变策略和终局审判等验证目标。
神明反馈链路设计拆解行为标签、证据强度、favor / wrath、原因摘要、神令、神罚、神赐和注视效果之间的关系，让神明介入有可追溯依据。
地图节点与局内闭环组织组织地图可达节点、风险预览、战斗、事件、祭坛、商店、休整、奖励结算和回地图推进，使一局能形成清晰流程。
配置驱动内容结构整理将地图、卡牌、敌人、事件、奖励、神明反馈和语言内容放入可校验的配置口径，保留战争之神内容库和后续三神扩展位。
UI 信息与资源接入判断围绕玩家能看懂神明、favor / wrath、神令、节点倾向和奖励状态来安排界面信息，并保留公开展示图作为作品馆素材。
GDD、配置与验收材料沉淀用 FinalGDD、模块 owner、调试入口、测试目标和人工验收路线记录系统边界，让内容案例可以被复查、继续补内容和迭代。

我的方案/核心设计

行为证据到神明态度设计对象是玩家路线、战斗、事件和资源取舍。组织方式是先写入 Risk、Avoidance、Greed、Promise、Defiance、Sacrifice 等行为标签和证据强度，再由不同神明解释为 favor / wrath 变化；判断是同一行为必须允许被不同神明差异化解读，收益是反馈有原因、可追溯、可扩展。
神令进入战斗决策设计对象是战斗中的神明临时规则题。组织方式是为神令配置触发时机、成功条件、失败条件、完成奖励、违逆代价和可见进度；判断是神明压力必须改变出牌目标，而不是只做战斗外评价，收益是玩家会在攻击、破阵、斩首和资源保留之间重新决策。
节点内容形成单局循环设计对象是地图、战斗、事件、祭坛、商店、休整和奖励结算。组织方式是地图只提供可达性、风险、神明倾向和内容引用，内容节点产出结果或奖励候选，Reward Settlement 统一确认，RunState 再写回节点、资源、牌组、神明状态和历史；判断是预览、候选和拥有状态必须分离，收益是循环稳定且状态不串线。
配置驱动承载扩展设计对象是地图、卡牌、敌人、事件、祭坛、奖励、神明反馈、语言和 UI key。组织方式是通用内容库先提供基础密度，战争之神内容库提供首个展示路线，并用配置校验保障主键、跨表引用和语言 key；判断是内容扩展不应散落在一次性逻辑里，收益是后续补卡池、事件池和三神差异时有清晰入口。
验证流程证明闭环设计对象是可玩闭环与内容稳定性。组织方式是 DebugTools 支持原型期定位问题，但正式验收走玩家可见 UI：主菜单、神明注视、地图、战斗或事件、反馈原因、奖励确认、RunState 写回、回地图；判断是展示案例必须证明玩家能理解反馈，而不只是开发者能调通流程，收益是作品馆内容更可信。

战斗循环

行为证据到神明态度设计对象是玩家路线、战斗、事件和资源取舍。组织方式是先写入 Risk、Avoidance、Greed、Promise、Defiance、Sacrifice 等行为标签和证据强度，再由不同神明解释为 favor / wrath 变化；判断是同一行为必须允许被不同神明差异化解读，收益是反馈有原因、可追溯、可扩展。
神令进入战斗决策设计对象是战斗中的神明临时规则题。组织方式是为神令配置触发时机、成功条件、失败条件、完成奖励、违逆代价和可见进度；判断是神明压力必须改变出牌目标，而不是只做战斗外评价，收益是玩家会在攻击、破阵、斩首和资源保留之间重新决策。
节点内容形成单局循环设计对象是地图、战斗、事件、祭坛、商店、休整和奖励结算。组织方式是地图只提供可达性、风险、神明倾向和内容引用，内容节点产出结果或奖励候选，Reward Settlement 统一确认，RunState 再写回节点、资源、牌组、神明状态和历史；判断是预览、候选和拥有状态必须分离，收益是循环稳定且状态不串线。
配置驱动承载扩展设计对象是地图、卡牌、敌人、事件、祭坛、奖励、神明反馈、语言和 UI key。组织方式是通用内容库先提供基础密度，战争之神内容库提供首个展示路线，并用配置校验保障主键、跨表引用和语言 key；判断是内容扩展不应散落在一次性逻辑里，收益是后续补卡池、事件池和三神差异时有清晰入口。
验证流程证明闭环设计对象是可玩闭环与内容稳定性。组织方式是 DebugTools 支持原型期定位问题，但正式验收走玩家可见 UI：主菜单、神明注视、地图、战斗或事件、反馈原因、奖励确认、RunState 写回、回地图；判断是展示案例必须证明玩家能理解反馈，而不只是开发者能调通流程，收益是作品馆内容更可信。

验证材料与边界

Demo 范围3 神 / 3 章 / 6 类节点
内容规模35-45 张卡 / 12-15 事件 / 8-10+ 敌人
神明反馈规模9-12 神令 / 各 6-9 神罚神赐
公开配置记录39 张表 / 43 事件 / 25 遭遇组
测试与验收45 EditMode / 13 PlayMode / 8-10 分钟人工路线
当前结论与边界闭环可展示 / 平衡未定稿

迭代过程

收束核心差异/先把项目定位从随机地牢底座收束为“神明主持试炼”，明确行为会被观察、解释并改变后续规则。
稳定基础闭环/先保证开局、神明注视、地图选点、战斗或非战斗、奖励确认和回地图推进能跑通。
接入神明反馈/把行为标签、favor / wrath、神令、神罚、神赐和原因摘要叠到关键决策点，让反馈进入局内策略。
整理内容管线/用通用内容库和战争之神内容库分层承载基础密度与神明定制解释，保留戏谑之神、慈悲之神扩展位。
固化验收边界/通过配置校验、DebugTools 和玩家可见人工路线区分“可展示闭环”与“后续商业化扩展”。

关键产出

FinalGDD 系统主轴形成以神明主持试炼为核心的最终 GDD 口径，明确核心体验、demo 范围、系统职责和不做范围。
神明导演系统结构把行为证据、favor / wrath、原因反馈、神令、神罚、神赐、注视效果和终局审判组织成可解释链路。
单局流程与 RunState 写回用 GameFlow、Map、Battle、Reward Settlement 和 RunState 分离流程、内容结果、奖励领取和真实状态。
配置驱动内容管线沉淀地图、卡牌、敌人、事件、奖励、神明反馈和语言 key 的配置化边界，支持后续内容扩展与校验。
展示图集与验收材料保留主界面、地图、神明百科、升级卡牌、结算、事件、休整、战斗和祭坛等公开图，并用测试目标说明验证范围。

项目复盘

证明系统设计组织能力：FinalGDD 证明我能把题材差异化拆成可运行系统：玩家行为先成为证据，再进入神明态度、规则压力、奖励结果和终局评价。

沉淀反馈链路方法：项目留下了“行为标签 -> favor / wrath -> 原因摘要 -> 规则结果 -> RunState 历史”的组织方法，可复用到其他需要解释玩家行为的系统。

明确展示边界：当前页面只公开竖向 demo 与最终 GDD 级系统案例，不夸大为完整商业卡池、最终数值平衡、联网规则或全量三神内容池。

后续扩展方向：若继续推进，应补完整三神内容池、长期神罚神赐效果器、终局审判文本、更多 playtest 记录和卡牌/敌人/事件平衡数据。