252 lines
14 KiB
Markdown
252 lines
14 KiB
Markdown
# CodeX M2 执行计划
|
||
|
||
> 依据：`docs/TODO.md` 当前口径，默认 `M1` 已完成并已收口。
|
||
> 目标：把 `M2（P1）- 核心深度` 拆成可直接开工的执行顺序、具体工作包与验收边界。
|
||
|
||
## 当前代码现状判断
|
||
|
||
- `EventNodeComponent`、`DREvent`、`EventForm` 已有最小骨架，`Event.txt` 已有 3 个样例事件，但 `EventFormUseCase.SelectOption()` 仍停留在 `TODO`，尚未真正执行条件校验、概率结算、消耗/奖励效果。
|
||
- `ShopNodeComponent` 与 `ShopFormUseCase` 已支持“生成 4 个商品并购买组件”的最小链路，但还没有出售、复杂定价、耐久折价、卖塔加成，也没有把商店能力沉到统一规则入口。
|
||
- `RunState` 已完成 A1 扩展，当前已承载 `runId / runSeed / current theme / theme stage / current theme pool / theme history / current node continue challenge layer / run items / node sequence / inventory snapshot`，并且事件、商店、战斗都已经改为通过统一节点完成快照回写这些状态。
|
||
- `LevelThemeType` 已有 `Volcano / Mountain`，战斗侧已有按主题取关卡、掉落按主题偏置的基础入口，因此主题玩法更适合在现有战斗调度器上继续补钩子，而不是重做主流程。
|
||
|
||
## 当前进度更新
|
||
|
||
- `A1` 已完成：`RunState` 长期状态字段、`RunNodeExecutionContext`、`RunNodeCompletionSnapshot`、`ProcedureMain` 统一推进写回链路都已落地。
|
||
- `A2` 已完成：已经补上三组最小 `EditMode` 测试入口，分别覆盖事件定义工厂、商店价格规则入口、当前可见的继续挑战倍率公式。
|
||
- 当前下一步应直接进入 `P1-01`，收口事件执行链路，不再继续停留在基础设施阶段。
|
||
|
||
## M2 总体推进顺序
|
||
|
||
1. 先收口事件系统 `P1-01 ~ P1-02`，因为代码骨架已经在，投入最小，能最快形成第二类节点的真实玩法。
|
||
2. 再收口商店系统 `P1-03 ~ P1-04`，把“买/卖/定价”统一到同一套库存与价格规则中。
|
||
3. 之后补运行中长期状态承载：道具系统 `P1-05` 与继续挑战 `P1-06`。
|
||
4. 再做主题玩法底座与两个主题规则 `P1-07 ~ P1-09`，避免火山、山地各自临时写一套。
|
||
5. 最后做大关后主题选择 `P1-10`，因为它依赖新的 run 分段结构与主题状态流转。
|
||
|
||
## 开工前置
|
||
|
||
### A1. 先补 M2 状态承载
|
||
|
||
- 当前状态：已完成。
|
||
- 目标：在不破坏 M1 固定 10 节点闭环的前提下，为 M2 新功能预留明确状态字段。
|
||
- 交付物：
|
||
- `Assets/GameMain/Scripts/Procedure/ProcedureMain/RunModel.cs`
|
||
- `Assets/GameMain/Scripts/Procedure/ProcedureMain/` 下相关推进服务
|
||
- 具体工作：
|
||
- 给 `RunState` 增加继续挑战层数、主题阶段索引、当前主题池、运行中道具列表或等价结构。
|
||
- 明确哪些状态属于 `RunState`，哪些属于 `PlayerInventory`，避免“金币在 run、道具在 inventory、主题选择在 UI 临时变量”这种分散写法。
|
||
- 为节点完成事件补足 M2 需要的快照字段，保证事件/商店/战斗都能通过统一推进入口回写状态。
|
||
- 验收补充：
|
||
- 不影响现有 M1 测试。
|
||
- 新字段默认值明确，未启用 M2 功能时不会改变 M1 行为。
|
||
|
||
### A2. 为 M2 先补最小测试底座
|
||
|
||
- 当前状态：已完成。
|
||
- 目标：先把容易回归的规则放进 `EditMode`，避免事件和定价后面越改越散。
|
||
- 交付物：
|
||
- `Assets/Tests/EditMode/`
|
||
- 具体工作：
|
||
- 先建三组测试入口：事件需求/效果执行、商店定价、继续挑战倍率。
|
||
- 对主题玩法先补纯规则测试，场景表现与路径交互后续再补 PlayMode。
|
||
- 验收补充：
|
||
- 至少保证新增核心公式与随机种子行为可回归。
|
||
|
||
## P1 详细计划
|
||
|
||
### P1-01 事件节点系统（选项、概率、奖励/惩罚执行器）
|
||
|
||
- 核心目标：把现有“能打开事件 UI”补完成“能稳定结算并推进节点”的正式系统。
|
||
- 交付物：
|
||
- `Assets/GameMain/Scripts/CustomComponent/EventNodeComponent.cs`
|
||
- `Assets/GameMain/Scripts/UI/Game/UseCase/EventFormUseCase.cs`
|
||
- `Assets/GameMain/Scripts/Definition/Event/`
|
||
- 必要时新增 `Assets/GameMain/Scripts/Procedure/` 下的事件结算服务
|
||
- 具体拆分：
|
||
- 增加统一事件执行入口：`检查 Requirements -> 执行 CostEffects -> 掷概率 -> 执行 RewardEffects -> 生成结算结果 -> EndEvent`。
|
||
- 概率结算改为基于 `runSeed + sequenceIndex + eventId + optionIndex` 的稳定随机，避免同局回放不一致。
|
||
- Requirements 不满足时，UI 侧需要明确禁止点击或提示原因，不能点了再静默失败。
|
||
- Effects 不要散落在 UI 控制器里，统一走一个事件执行服务或等价显式流程函数。
|
||
- 明确失败语义：要求不足属于“不可选”，概率失败属于“已执行但收益为空或惩罚生效”。
|
||
- 验收补充：
|
||
- 可稳定配置并执行至少 10 个事件。
|
||
- 事件结束后金币、库存、耐久等变化能正确写回节点完成快照。
|
||
- 同一种子重复运行时，事件随机结果一致。
|
||
|
||
### P1-02 落地 3 个示例事件（赌马 / 组件交换 / 耐久换金币）
|
||
|
||
- 核心目标：用 3 个真实事件验证 `P1-01` 的执行器不是一次性硬编码。
|
||
- 交付物：
|
||
- `Assets/GameMain/DataTables/Event.txt`
|
||
- 若现有效果不足，补 `Assets/GameMain/Scripts/Definition/Event/EventEffect/`
|
||
- 若现有条件不足，补 `Assets/GameMain/Scripts/Definition/Event/EventRequirement/`
|
||
- 具体拆分：
|
||
- 保留并收口“赌马”事件，验证 `GoldAtLeast + AddGold + Probability`。
|
||
- 把“组件交换”改成真正符合设计的链路：支付指定品质组件，返回不低于原品质的新组件；现有“换金币”样例不足以覆盖该目标。
|
||
- 新增“耐久换金币”事件，复用当前耐久体系，明确扣减对象、扣减数量、损坏后的处理与节点结束后的清理。
|
||
- 事件表扩充到 10 个可用事件时，先按低风险/中风险/功能型三类分层，避免全是纯金币事件。
|
||
- 验收补充：
|
||
- 三个示例事件在局内都能完整触发、结算、回写状态。
|
||
- 不会出现组件被扣掉但奖励未发、或耐久扣成负值这种半成功状态。
|
||
|
||
### P1-03 商店节点：购买 / 出售组件
|
||
|
||
- 核心目标：把当前“仅购买组件”的商店补成完整交易节点。
|
||
- 交付物：
|
||
- `Assets/GameMain/Scripts/UI/Shop/`
|
||
- `Assets/GameMain/Scripts/CustomComponent/ShopNodeComponent.cs`
|
||
- 必要时新增 `Assets/GameMain/Scripts/Utility/` 下的交易规则工具
|
||
- 具体拆分：
|
||
- Shop UI 增加玩家库存展示与出售入口，至少支持出售三类组件。
|
||
- 交易结算统一走一个买卖接口，不要在 UI 层分别修改金币和库存。
|
||
- 商品购买后状态、库存变化、金币变化要同时刷新，不允许 UI 还显示可买但实际已买。
|
||
- 明确商店节点退出条件与节点完成时机，避免出现开店即完成或出售后不回流的问题。
|
||
- 验收补充：
|
||
- 买卖后库存与金币实时正确更新。
|
||
- 关闭商店后重新打开同一节点时，商品状态与本节点交易结果一致。
|
||
|
||
### P1-04 商店定价规则：买价、半价回收、卖塔 +10%、耐久折价
|
||
|
||
- 核心目标：把价格从“按品质随机区间”升级为可解释、可测试的公式。
|
||
- 交付物：
|
||
- `Assets/GameMain/Scripts/Utility/`
|
||
- `Assets/GameMain/Scripts/Entity/` 或库存相关域对象
|
||
- 视需要调整 `Assets/GameMain/DataTables/ShopPrice.txt`
|
||
- 具体拆分：
|
||
- 抽出统一价格解析入口：基础买价、出售价、塔出售加成、耐久折价都走同一公式服务。
|
||
- 明确“组件价格”和“整塔价格”关系，不能在 UI 里临时把三组件价格相加后再乘一个魔法数。
|
||
- 明确耐久折价规则：按当前耐久比例折价，还是按损坏阈值分段折价；先写死规则文档，再落代码。
|
||
- 如果 `ShopPrice.txt` 只够表达品质区间，新增字段或新表承载倍率，不要继续在代码里硬编码。
|
||
- 验收补充：
|
||
- 买价、回收半价、卖塔 +10%、耐久折价都可通过测试直接验证。
|
||
- 同类物品在同一规则下价格可解释，不出现随机漂移。
|
||
|
||
### P1-05 道具系统（影响初始金币、掉金倍率等）
|
||
|
||
- 核心目标：引入 run 内长期生效的被动效果，支撑中期构筑深度。
|
||
- 交付物：
|
||
- `Assets/GameMain/Scripts/Entity/`
|
||
- `Assets/GameMain/DataTables/*.txt`
|
||
- `Assets/GameMain/Scripts/Procedure/ProcedureMain/`
|
||
- 具体拆分：
|
||
- 先定义“道具”最小模型：唯一 Id、名称、描述、叠加规则、效果列表。
|
||
- 道具效果统一挂在 run 状态，不要把“初始金币加成”写进开局逻辑、“掉金倍率”写进敌人掉落逻辑、“商店折扣”又写进商店 UI。
|
||
- 第一批只做能复用现有链路的效果：初始金币、掉金倍率、商店折扣、额外奖励候选、事件收益倍率。
|
||
- 明确获取来源：先只接战斗奖励或事件奖励，暂不同时开启商店售卖与局外解锁。
|
||
- 验收补充：
|
||
- 至少 5 个道具可叠加生效。
|
||
- 多个道具同时存在时，叠加顺序和公式固定且可测试。
|
||
|
||
### P1-06 战斗后“继续挑战”机制（高强度高爆率）
|
||
|
||
- 核心目标：把当前战斗结算从单向结束改成“收手 / 继续”的风险收益选择。
|
||
- 交付物：
|
||
- `Assets/GameMain/Scripts/Procedure/`
|
||
- `Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatScheduler/`
|
||
- 需要时补 `Assets/GameMain/Scripts/UI/Combat/` 或现有结算 UI
|
||
- 具体拆分：
|
||
- 战斗胜利后新增继续挑战分支，不改变失败结算语义。
|
||
- 给 run 增加当前节点继续挑战层数，并把它传入敌人强度和掉落倍率计算。
|
||
- 强度提升与爆率提升必须都走显式公式，且支持按层数递增。
|
||
- 继续挑战退出时，节点奖励如何结算、是否覆盖原奖励、是否保底，需要在实现前先写清楚。
|
||
- 验收补充：
|
||
- 选择继续后敌人强度明显提升且爆率提升。
|
||
- 连续多次继续时，奖励和风险曲线都可感知，不出现“白打”。
|
||
|
||
### P1-07 火山主题规则（高温、岩浆格、抗火敌人）
|
||
|
||
- 核心目标：做出第一个真实改变战斗结果的主题规则，而不是只换关卡皮肤。
|
||
- 交付物：
|
||
- `Assets/GameMain/Scripts/Scene/`
|
||
- `Assets/GameMain/Scripts/Entity/`
|
||
- 必要时新增主题规则配置表
|
||
- 具体拆分：
|
||
- 先抽主题战斗规则入口，统一在战斗调度或关卡运行时挂载主题效果。
|
||
- 高温规则先定义为全局环境修正；岩浆格是地图局部修正；敌人抗火是单位侧修正，三者不要混成一个大脚本。
|
||
- 岩浆格必须有清晰表现和可命中逻辑，不能只有视觉特效。
|
||
- 与现有 Tag / 属性体系冲突处优先显式列出，不在第一版做复杂联动。
|
||
- 验收补充：
|
||
- 岩浆效果可视，且确实会改变塔或敌人的战斗结果。
|
||
|
||
### P1-08 山地主题规则（高度、悬崖、位移致死）
|
||
|
||
- 核心目标：做出第二个与火山玩法差异明显的主题。
|
||
- 交付物：
|
||
- `Assets/GameMain/Scripts/Scene/`
|
||
- `Assets/GameMain/Scripts/Entity/`
|
||
- 必要时新增高度或地形标记配置
|
||
- 具体拆分：
|
||
- 为地图格子补高度/悬崖属性，而不是把高度写死在某一张图脚本里。
|
||
- 塔攻击高打低、低打高的距离或命中修正单独实现，避免和基础攻击范围直接耦死。
|
||
- 敌人上下坡移速修正与悬崖击退致死分开结算，便于后续加其他位移效果。
|
||
- 先支持对现有敌人和击退能力最小接入，不追求一次做完整地形系统。
|
||
- 验收补充：
|
||
- 高低地形会影响攻防与移速。
|
||
- 悬崖击退击杀能真实生效并参与结算。
|
||
|
||
### P1-09 主题地图掉落偏好（按主题偏置组件）
|
||
|
||
- 核心目标：让主题不只影响战斗规则，也影响构筑倾向。
|
||
- 交付物：
|
||
- `Assets/GameMain/DataTables/*.txt`
|
||
- `Assets/GameMain/Scripts/CustomComponent/InventoryGeneration/`
|
||
- 具体拆分：
|
||
- 在现有 `OutGameDropPool` 或新增偏置表中表达主题掉落权重，不要把火山/山地偏置硬编码在掉落代码里。
|
||
- 主题偏置只影响权重，不直接写死掉落结果，保留随机性。
|
||
- 明确偏置作用对象：组件槽位、品质、Tag、或其组合，第一版建议先偏置组件/Tag。
|
||
- 验收补充：
|
||
- 不同主题统计掉落分布显著不同。
|
||
- 偏置结果与 `P1-07 / P1-08` 的主题反制方向一致。
|
||
|
||
### P1-10 大关完成后可选下一主题地图
|
||
|
||
- 核心目标：把当前“固定单主题 10 节点 run”扩成“按大关推进并选择下个主题”。
|
||
- 交付物：
|
||
- `Assets/GameMain/Scripts/Procedure/`
|
||
- `Assets/GameMain/Scripts/UI/Templates/GameScene/` 或现有节点地图相关 UI
|
||
- 具体拆分：
|
||
- 先定义“大关”与“节点序列”的关系：是每个大关 10 节点，还是一个 run 内包含多个主题段。
|
||
- Run 流程需要新增“主题选择阶段”，不能继续只靠 `CurrentNodeIndex++` 线性推进。
|
||
- 主题选择 UI 至少展示 2 个候选主题、主题效果摘要、预期掉落倾向。
|
||
- 选择后要能重建后续节点池、关卡池和掉落偏置，而不是只改一个 `ThemeType` 字段。
|
||
- 验收补充：
|
||
- 通关后至少可在 2 个主题间选择。
|
||
- 主题选择会真实影响后续关卡、掉落和规则。
|
||
|
||
## 推荐分批提交
|
||
|
||
### 批次 1：事件系统收口
|
||
|
||
- `A1` 中与事件相关的状态补充
|
||
- `P1-01`
|
||
- `P1-02`
|
||
|
||
### 批次 2：商店系统收口
|
||
|
||
- `P1-03`
|
||
- `P1-04`
|
||
|
||
### 批次 3：run 深度状态
|
||
|
||
- `P1-05`
|
||
- `P1-06`
|
||
|
||
### 批次 4：主题玩法底座与内容
|
||
|
||
- 主题规则统一入口
|
||
- `P1-07`
|
||
- `P1-08`
|
||
- `P1-09`
|
||
|
||
### 批次 5：多主题推进
|
||
|
||
- `P1-10`
|
||
|
||
## 当前建议的第一开工项
|
||
|
||
1. 立刻收口 `P1-01`，把 `EventFormUseCase.SelectOption()` 从占位实现改成正式结算。
|
||
2. 基于 A2 里已经补好的事件定义测试入口，新增事件执行链路测试，覆盖 requirement、cost、probability、reward 和完成快照回写。
|
||
3. 用 `P1-02` 的三个示例事件验证执行器能力，再扩表到 10 个事件。
|
||
4. 之后再进入商店买卖与定价，不建议现在同时并行推进主题地图。
|