basil
/
geometry-tower-defense
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
geometry-tower-defense/docs/CodeX-TODO.md

15 KiB
Raw Blame History

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 商店节点购买 + 背包出售组件 / 防御塔

  • 核心目标：保留商店节点的购买职责，把出售入口迁到背包 RepoForm，形成完整交易闭环。
  • 交付物：
    • Assets/GameMain/Scripts/UI/Shop/
    • Assets/GameMain/Scripts/UI/Game/
    • Assets/GameMain/Scripts/CustomComponent/ShopNodeComponent.cs
    • Assets/GameMain/Scripts/CustomComponent/PlayerInventory/
  • 具体拆分：
    • Shop UI 保持“4 个商品 + 购买 + 打开背包”主链，不再承担库存展示与出售交互。
    • Repo UI 增加明确的出售模式入口；进入后可批量选择未组装组件与非参战防御塔，并显示当前选择总价值。
    • 参战防御塔不能直接出售，必须先从参战区移出；出售整塔时，需要连同其绑定的 3 个组件一起从库存移除。
    • 交易结算统一走库存域的显式买/卖命令，不要在 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. 之后再进入商店买卖与定价，不建议现在同时并行推进主题地图。