210 lines
11 KiB
Markdown
210 lines
11 KiB
Markdown
# CodeX TODO
|
||
|
||
最后更新：2026-03-07
|
||
|
||
## 当前目标
|
||
|
||
按 `docs/TODO.md` 的 M1 现状推进最小可玩闭环。当前代码已经具备：
|
||
- 基础战斗节点玩法
|
||
- 事件节点基础占位
|
||
- 仓库/组装 UI 骨架
|
||
- 局内掉落与战斗结算的一部分
|
||
|
||
但离“可从开始游戏一路完成一个大关”的 M1 验收还有明显缺口。后续重点是：
|
||
- 补真正的单局 Run 流程，而不是继续依赖 `TestMenuForm` 手动点节点。
|
||
- 把 10 节点固定大关、节点推进、Boss 终点串成闭环。
|
||
- 把组装、品质、Tag、耐久从“有数据结构/有 UI”补成“实际影响战斗结果”的规则闭环。
|
||
- 补商店节点真实实现，否则 M1 主流程无法跑通。
|
||
|
||
## 已完成
|
||
|
||
### 1. 战斗主链路已经能独立跑通一场
|
||
- `CombatNodeComponent` 能加载关卡、阶段和出怪表，并启动 `CombatScheduler`。
|
||
- `CombatScheduler` 已经具备加载地图、推进 phase、结算与返回的基础流程。
|
||
- 战斗内已有基地血量、建塔花费、敌人到家扣血、胜负结束等基础逻辑。
|
||
|
||
关键文件：
|
||
- `Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatNodeComponent.cs`
|
||
- `Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatScheduler/CombatScheduler.cs`
|
||
- `Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatScheduler/CombatStates/`
|
||
- `Assets/GameMain/Scripts/Entity/EntityLogic/MapEntity.cs`
|
||
- `Assets/GameMain/Scripts/Scene/Map/`
|
||
|
||
### 2. 战斗结算、掉落与奖励选择已有基础实现
|
||
- 战斗内敌人被击败后，已能发放 coin / gold / 组件掉落。
|
||
- `CombatInRunResourceManager` 已维护本场奖励背包快照。
|
||
- 结算链已经包含奖励计算、奖励选择 UI、FinishForm 返回等基础骨架。
|
||
|
||
关键文件：
|
||
- `Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatScheduler/CombatInRunResourceManager.cs`
|
||
- `Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatScheduler/EnemyDrop/EnemyDropResolver.cs`
|
||
- `Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatScheduler/CombatSettlementFlowService.cs`
|
||
- `Assets/GameMain/Scripts/UI/Combat/`
|
||
|
||
### 3. 背包与组装基础能力已经存在
|
||
- `PlayerInventoryComponent` 已有库存快照、金币读写、参战塔名单、组装塔入口。
|
||
- `RepoForm` 已能展示组件、塔、参战区和组装区。
|
||
- `CombineArea` 已有三槽约束，只有枪口/轴承/底座齐备时才会发起组合请求。
|
||
- `PlayerInventoryTowerAssemblyService` 已能基于三组件生成 `TowerItemData` 与 `TowerStatsData`。
|
||
|
||
关键文件：
|
||
- `Assets/GameMain/Scripts/CustomComponent/PlayerInventory/PlayerInventoryComponent.cs`
|
||
- `Assets/GameMain/Scripts/CustomComponent/PlayerInventory/PlayerInventoryTowerAssemblyService.cs`
|
||
- `Assets/GameMain/Scripts/UI/Game/View/RepoForm.cs`
|
||
- `Assets/GameMain/Scripts/UI/Game/View/CombineArea.cs`
|
||
- `Assets/GameMain/Scripts/UI/Game/Controller/RepoFormController.cs`
|
||
|
||
### 4. 事件节点有基础占位实现
|
||
- `EventNodeComponent` 已能读取 `Event.txt`，解析事件选项并随机打开一个事件。
|
||
- 事件完成后会发出 `NodeCompleteEventArgs` 返回上层流程。
|
||
|
||
关键文件：
|
||
- `Assets/GameMain/Scripts/CustomComponent/EventNodeComponent.cs`
|
||
- `Assets/GameMain/Scripts/UI/Game/UseCase/EventFormUseCase.cs`
|
||
- `Assets/GameMain/Scripts/UI/Game/Controller/EventFormController.cs`
|
||
|
||
## 还没完成
|
||
|
||
### 1. M1 真正的 Run 流程还不存在
|
||
- 当前入口仍是 `ProcedureMenu` 里打开 `MainForm + TestMenuForm`。
|
||
- 玩家目前是手动点击 `战斗 / 事件 / 商店` 按钮进入节点，不是通过单局大关顺序推进。
|
||
- 代码里没有明确的“当前节点 / 节点列表 / 节点索引 / 大关完成”运行时模型。
|
||
- `docs/TODO.md` 的 `P0-04 / P0-05 / P0-06` 从验收标准看都还没有完整落地。
|
||
|
||
直接证据：
|
||
- `ProcedureMenu` 进入后直接打开测试菜单。
|
||
- `TestMenuFormController` 直接转发到 `StartCombat / StartEvent / StartShop`。
|
||
|
||
关键文件：
|
||
- `Assets/GameMain/Scripts/Procedure/ProcedureMenu.cs`
|
||
- `Assets/GameMain/Scripts/UI/Menu/Controller/TestMenuFormController.cs`
|
||
|
||
### 2. 10 节点地图生成与 Boss 终点未实现
|
||
- 当前没有发现“固定 10 节点”或“第 10 节点固定 Boss”的节点生成器。
|
||
- `CombatNodeComponent.StartCombat()` 仍是从当前主题关卡池里随机抽一个 `DRLevel` 开战。
|
||
- 现有 Boss 相关逻辑只存在于战斗内部的 `EntryType.Boss / BossDead`，不是大关节点层面的第 10 节点约束。
|
||
|
||
关键文件：
|
||
- `Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatNodeComponent.cs`
|
||
- `Assets/GameMain/Scripts/CustomComponent/CombatNode/EnemyManager/EnemySpawnDirector.cs`
|
||
- `Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatScheduler/PhaseEndConditions/BossDeadPhaseEndCondition.cs`
|
||
|
||
### 3. 商店节点基本未实现，当前是主流程硬缺口
|
||
- `ShopNodeComponent.StartShop()` 仍然是空方法。
|
||
- 旧版 `ShopFormUseCase / ShopFormController / ShopForm` 基本都是整文件注释状态，不能视为可用实现。
|
||
- 因此 `战斗 -> 事件 -> 商店 -> 组装 -> 下一节点` 这条 M1 主链路实际上卡在商店节点。
|
||
|
||
关键文件：
|
||
- `Assets/GameMain/Scripts/CustomComponent/ShopNodeComponent.cs`
|
||
- `Assets/GameMain/Scripts/UI/Templates/GameScene/UseCase/ShopFormUseCase.cs`
|
||
- `Assets/GameMain/Scripts/UI/Templates/GameScene/Controller/ShopFormController.cs`
|
||
- `Assets/GameMain/Scripts/UI/Templates/GameScene/View/ShopForm.cs`
|
||
|
||
### 4. 三组件约束只做到了“组装时”，还没做到“出战时”
|
||
- `CombineArea` 已经要求枪口/轴承/底座三槽都填满才能发起组装。
|
||
- 但战斗入口并没有校验“玩家是否拥有可参战的完整塔”。
|
||
- 当前可以在没有任何参战塔时直接调用 `StartCombat()`，不符合 `P0-10` 的“未满足三组件时禁止出战”。
|
||
|
||
关键文件：
|
||
- `Assets/GameMain/Scripts/UI/Game/View/CombineArea.cs`
|
||
- `Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatNodeComponent.cs`
|
||
- `Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatScheduler/CombatScheduler.cs`
|
||
|
||
### 5. 品质/槽位/Tag 规则只做了最浅一层
|
||
- 塔品质目前只按三组件平均品质四舍五入得到。
|
||
- `TowerItemData` 里没有“配件槽位数量”之类的落地字段，槽位规则没有真正实现。
|
||
- Tag 当前不是按品质概率、数量、等级生成，而是：
|
||
- 掉落时直接复制 `PossibleTag`
|
||
- 组塔时直接把三组件 Tag 做并集
|
||
- `DRTag` 虽然存在，但没有看到被用于实际掉落/组装规则计算。
|
||
- `RarityType` 仍包含 `Red`，而 `docs/MVP-Scope.md.md` 里写的是 M1 不做红色，这里也还没统一。
|
||
|
||
关键文件：
|
||
- `Assets/GameMain/Scripts/CustomComponent/PlayerInventory/PlayerInventoryTowerAssemblyService.cs`
|
||
- `Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatScheduler/EnemyDrop/EnemyDropResolver.cs`
|
||
- `Assets/GameMain/Scripts/DataTable/DRTag.cs`
|
||
- `Assets/GameMain/Scripts/Definition/DataStruct/TowerItemData.cs`
|
||
- `Assets/GameMain/Scripts/Definition/Enum/RarityType.cs`
|
||
|
||
### 6. 耐久只停留在展示和扣数值，没有真正生效
|
||
- 当前组件耐久会显示在仓库描述和 UI 颜色上。
|
||
- 低血通关后会调用 `ReduceAllTowerEndurance(...)` 扣耐久。
|
||
- 但塔的真实战斗属性是组装时固化到 `TowerStatsData` 的，不会随着耐久变化动态衰减。
|
||
- 组件耐久归 0 后没有销毁、移除库存、拆塔或失效处理。
|
||
- 所以 `P0-12` 的“耐久影响属性，归零后物品移除”目前未完成。
|
||
|
||
关键文件：
|
||
- `Assets/GameMain/Scripts/Utility/ItemDescUtility.cs`
|
||
- `Assets/GameMain/Scripts/CustomComponent/PlayerInventory/PlayerInventoryTowerRosterService.cs`
|
||
- `Assets/GameMain/Scripts/Definition/DataStruct/TowerItemData.cs`
|
||
- `Assets/GameMain/Scripts/Definition/DataStruct/TowerCompItemData.cs`
|
||
|
||
### 7. M1 文档与当前实现还有几处范围不一致
|
||
- `docs/MVP-Scope.md.md` 写的是固定 10 节点与固定顺序，但当前代码没有对应系统。
|
||
- 文档写的是商店节点可购买/出售组件，但当前商店未实现。
|
||
- 文档写的是 M1 不做耐久系统，但 `docs/TODO.md` 又把耐久列在 M1 的 `P0-12`；当前代码只做了半套，需要先统一目标再继续推进。
|
||
- 文档写的是 M1 不做红色品质，但数据与枚举仍保留 `Red`。
|
||
|
||
关键文件：
|
||
- `docs/TODO.md`
|
||
- `docs/MVP-Scope.md.md`
|
||
- `docs/GameDesign.md`
|
||
|
||
## 推荐的后续执行顺序
|
||
|
||
1. 先补单局 Run 模型
|
||
- 明确 `当前节点索引 / 节点列表 / 当前主题 / 大关完成状态`
|
||
- 把 `ProcedureMenu + TestMenuForm` 临时入口替换成真实节点推进入口
|
||
|
||
2. 再补 10 节点固定大关
|
||
- 先做最小版本：固定顺序 10 节点
|
||
- 最后一个节点固定 Boss 战斗
|
||
- 节点完成后推进到下一节点
|
||
|
||
3. 立刻补商店节点最小实现
|
||
- 先只做 3 个随机组件、购买、返回
|
||
- 不提前做复杂定价与出售扩展
|
||
|
||
4. 收口组装到出战闭环
|
||
- 没有完整塔时禁止开始战斗
|
||
- 只有参战塔列表合法时才允许进入战斗节点
|
||
|
||
5. 最后补品质/Tag/耐久规则
|
||
- 先把 M1 真实要做的规则重新对齐
|
||
- 再决定是否保留红色品质、耐久和槽位到本阶段
|
||
|
||
## 当前做变更时要记住的约束
|
||
|
||
- 不要继续把 `TestMenuForm` 当作正式节点流程。
|
||
- 优先补“流程闭环”，不要先做 M2 的深度系统。
|
||
- 商店、节点推进、出战校验属于当前阻塞项，优先级高于数值打磨。
|
||
- 如果 M1 最终决定不做完整耐久/红色品质，要先同步更新文档，再改代码目标。
|
||
- 若继续保留 `PlayerInventory` 作为局内外共用库存入口，需要避免把单局 Run 状态也硬塞进去。
|
||
|
||
## 当前关键入口文件速查
|
||
|
||
- 流程入口：
|
||
- `Assets/GameMain/Scripts/Procedure/ProcedureMenu.cs`
|
||
- 临时节点菜单：
|
||
- `Assets/GameMain/Scripts/UI/Menu/Controller/TestMenuFormController.cs`
|
||
- 战斗节点 facade：
|
||
- `Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatNodeComponent.cs`
|
||
- 战斗状态机：
|
||
- `Assets/GameMain/Scripts/CustomComponent/CombatNode/CombatScheduler/CombatScheduler.cs`
|
||
- 事件节点：
|
||
- `Assets/GameMain/Scripts/CustomComponent/EventNodeComponent.cs`
|
||
- 商店节点：
|
||
- `Assets/GameMain/Scripts/CustomComponent/ShopNodeComponent.cs`
|
||
- 背包与组装：
|
||
- `Assets/GameMain/Scripts/CustomComponent/PlayerInventory/`
|
||
- 仓库 UI：
|
||
- `Assets/GameMain/Scripts/UI/Game/`
|
||
- 战斗 UI：
|
||
- `Assets/GameMain/Scripts/UI/Combat/`
|
||
|
||
## 备注
|
||
|
||
- 这份清单按“当前仓库真实实现状态”整理，不沿用旧版 `CodeX-TODO.md` 的 CombatNode 收口主题。
|
||
- 当前判断主要基于代码静态检查，没有跑 Unity Editor / PlayMode。
|
||
- 如果下一步要继续推进，最值得先做的是：`RunState + 10 节点流程 + ShopNode 最小可用版`。
|