basil/geometry-tower-defense
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

S4 收尾

Browse Source
This commit is contained in:
basil
2026-03-11 15:02:44 +08:00
parent 515fe95441
commit c019f9f527
103 changed files with 367 additions and 230 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/CodeX-TODO.md
+56 -14
View File
@@ -137,7 +137,7 @@
>
> 2026-03-09 更新：`S4-03` 文档口径已冻结；`TagSystemDesign.md` 已明确组件实例生成、塔级 `Stack` 汇总、四段触发阶段、`Tag.txt + TagRule` 双表方向，以及 MVP 正式首发 7 个 Tag：`Fire`、`Ice`、`Crit`、`Execution`、`Shatter`、`Inferno`、`AbsoluteZero`。`BurnSpread` 已明确后移。
>
> 2026-03-09 更新：`S4-04` 已落地 `InventoryTagRuleService` 与 `InventoryTagSourceType`；组件实例 Tag 现在统一按 `PossibleTag + Tag.txt.MinRarity + 品质预算` 生成，并只保留当前正式首发 7 个 Tag。`ShopFormUseCase`、`EnemyDropResolver`、`InventorySeedUtility` 已接入该入口，样例库存的组件与塔展示 Tag 已同步为统一结果；同时新增 `InventoryTagRuleServiceTests`。当前 CLI 下 `dotnet build GeometryTD.sln` 仍因本机缺少 Unity 引用和 `Unity.SourceGenerators*.dll` 失败，未能替代 Unity Test Runner 完成最终验证。
> 2026-03-09 更新：`S4-04` 已落地 `ComponentTagGenerationService` 与 `InventoryTagSourceType`；组件实例 Tag 现在统一按 `PossibleTag + Tag.txt.MinRarity + 品质预算` 生成，并只保留当前正式首发 7 个 Tag。`ShopFormUseCase`、`EnemyDropResolver`、`InventorySeedUtility` 已接入该入口，样例库存的组件与塔展示 Tag 已同步为统一结果；同时新增 `ComponentTagGenerationServiceTests`。当前 CLI 下 `dotnet build GeometryTD.sln` 仍因本机缺少 Unity 引用和 `Unity.SourceGenerators*.dll` 失败，未能替代 Unity Test Runner 完成最终验证。
>
> 2026-03-09 更新：`S4-05` 已新增 `TagRuntimeData` 与 `TowerTagAggregationService`；组塔与样例塔现在统一生成塔级 `TagRuntimes`，并保留兼容 `Tags` 投影。`RepoForm`、`CombatFinishForm`、`ItemDescForm` 的塔展示已切到聚合结果，重复 Tag 以 `xN` 文本显示；组件展示仍沿用组件实例 `Tags`。同时新增 `TowerTagAggregationServiceTests`；本轮改动后的最终验证仍以 Unity Test Runner 实跑结果为准。
>
@@ -145,11 +145,11 @@
>
> 2026-03-10 更新：`S4-06` 已补齐首发剩余 3 个 Tag。`Shatter` 已接入命中前数值修正链，并按“目标已减速”口径增伤；`Inferno` 与 `AbsoluteZero` 已按首发方案作为 `Fire` / `Ice` 的强化 Tag 落地，分别增强 DOT 时长/伤害与减速时长/强度；对应 EditMode 测试已同步补齐。`BurnSpread`、`IgniteBurst`、`FreezeMask`、`Pierce`、`Overpenetrate` 仍保持分类与占位路由，没有实际战斗效果，因此仍属于后续扩展，不计入 `S4-06` 当前完成标准。
>
> 2026-03-10 更新：`S4-07` 仍未开始正式收口。当前 Tag 参数仍主要承载在代码侧 `TagConfigRegistry` 与各 Tag 配置类中，`Tag.txt` / DataTable 仍只提供基础字典与 `MinRarity` 输入；文档中约定的 `TagRule` 表、触发阶段、权重、效果参数等尚未形成 DataRow 与运行时消费闭环。因此 `S4-07` 继续保持未完成状态。
> 2026-03-10 更新：`S4-07` 仍未开始正式收口。当前 Tag 参数仍主要承载在代码侧 `TagDefinitionRegistry` 与各 Tag 配置类中，`Tag.txt` / DataTable 仍只提供基础字典与 `MinRarity` 输入；文档中约定的 `TagRule` 表、触发阶段、权重、效果参数等尚未形成 DataRow 与运行时消费闭环。因此 `S4-07` 继续保持未完成状态。
>
> 2026-03-11 更新：`S4-07` 已进入第一阶段实现。当前已新增 `TagConfig.txt` 与 `DRTagConfig`，`ProcedurePreload` 会在加载 `TagConfig` 表后驱动 `TagConfigRegistry.LoadFromRows(...)`，把 `TriggerPhase`、`Description` 以及首发 7 个 Tag 的配置参数从表覆盖到运行时强类型 `TagConfig`。`ItemDescForm` 也已开始消费该配置说明；塔详情会优先使用 `TagRuntimes` 构建 `Ice x2` 这类叠层展示。因此 `S4-07` 不再是“完全未开始”，但当前仍只完成了 `TagConfig` 级别的参数映射与 UI 消费，尚未把文档中的完整 `TagRule`（如权重、生成规则等）全部收口。
> 2026-03-11 更新：`S4-07` 已进入第一阶段实现。当前已新增 `TagConfig.txt` 与 `DRTagConfig`，`ProcedurePreload` 会在加载 `TagConfig` 表后驱动 `TagDefinitionRegistry.LoadFromRows(...)`，把 `TriggerPhase`、`Description` 以及首发 7 个 Tag 的配置参数从表覆盖到运行时强类型 `TagConfig`。`ItemDescForm` 也已开始消费该配置说明；塔详情会优先使用 `TagRuntimes` 构建 `Ice x2` 这类叠层展示。因此 `S4-07` 不再是“完全未开始”，但当前仍只完成了 `TagConfig` 级别的参数映射与 UI 消费，尚未把文档中的完整 `TagRule`（如权重、生成规则等）全部收口。
>
> 2026-03-11 更新：`S4-07` 已继续推进到第二阶段。当前 `Tag.txt -> DRTag -> TagGenerationRuleRegistry` 已形成组件 Tag 生成规则闭环，`InventoryTagRuleService` 不再主要依赖内部 `MinRarity` 硬编码，而是统一消费 `DRTag` 提供的 `MinRarity + Weight`；`ShopFormUseCase`、`EnemyDropResolver`、`InventorySeedUtility` 也已切回这一统一入口。现阶段的职责边界明确为：`Tag.txt` 负责基础字典与生成规则，`TagConfig.txt` 负责触发阶段、描述与效果参数。
> 2026-03-11 更新：`S4-07` 已继续推进到第二阶段。当前 `Tag.txt -> DRTag -> TagGenerationRuleRegistry` 已形成组件 Tag 生成规则闭环，`ComponentTagGenerationService` 不再主要依赖内部 `MinRarity` 硬编码，而是统一消费 `DRTag` 提供的 `MinRarity + Weight`；`ShopFormUseCase`、`EnemyDropResolver`、`InventorySeedUtility` 也已切回这一统一入口。现阶段的职责边界明确为：`Tag.txt` 负责基础字典与生成规则，`TagConfig.txt` 负责触发阶段、描述与效果参数。
>
> 2026-03-11 补充验证：已通过手工扩充组件 `PossibleTag` 候选池并调整 `Weight` 验证生成权重实际生效；同时把所有 Tag 的 `MinRarity` 提升到 `Red` 后，低品质组件不再生成任何 Tag，说明 `Tag.txt` 中的 `MinRarity` 与 `Weight` 均已进入统一生成链。
@@ -186,19 +186,19 @@
- `S4-06` 已完成：战斗链已支持 Tag 透传与统一结算，正式首发 7 个 Tag `Fire`、`Ice`、`Crit`、`Execution`、`Shatter`、`Inferno`、`AbsoluteZero` 均已有可验证效果。
- `Shatter` 已接入命中前数值修正链；`Inferno`、`AbsoluteZero` 已按“强化现有 `Fire` / `Ice` 状态”的首发口径落地，状态类 Tag 的内部结构继续保持注册式运行时。
- `BurnSpread`、`IgniteBurst`、`FreezeMask`、`Pierce`、`Overpenetrate` 已进入分类与配置骨架，但仍属于后续扩展，不计入当前 `S4` 的完成标准。
- `S4-07` 已进入第一阶段实现。当前仓库已具备 `TagConfig.txt -> DRTagConfig -> TagConfigRegistry -> ItemDescForm` 的消费闭环，首发 7 个 Tag 的触发阶段、描述与核心参数已可由表覆盖。
- `S4-07` 已推进到第二阶段。当前仓库同时具备 `Tag.txt -> DRTag -> TagGenerationRuleRegistry -> InventoryTagRuleService` 与 `TagConfig.txt -> DRTagConfig -> TagConfigRegistry -> ItemDescForm` 两条消费闭环，首发 7 个 Tag 的生成规则、触发阶段、描述与核心参数都已开始由表驱动。
- `S4-07` 已推进到第三阶段。当前仓库新增 `RarityTagBudget.txt -> DRRarityTagBudget -> RarityTagBudgetRuleRegistry -> InventoryTagRuleService`，组件 Tag 数量预算不再写死在 `ResolveRarityTagBudget(...)` 的 `switch` 中，而是按品质从表驱动；至此生成链的候选过滤、权重抽取、数量预算三段都已进入 DataTable 消费闭环。
- `S4-07` 已进入第一阶段实现。当前仓库已具备 `TagConfig.txt -> DRTagConfig -> TagDefinitionRegistry -> ItemDescForm` 的消费闭环，首发 7 个 Tag 的触发阶段、描述与核心参数已可由表覆盖。
- `S4-07` 已推进到第二阶段。当前仓库同时具备 `Tag.txt -> DRTag -> TagGenerationRuleRegistry -> ComponentTagGenerationService` 与 `TagConfig.txt -> DRTagConfig -> TagDefinitionRegistry -> ItemDescForm` 两条消费闭环，首发 7 个 Tag 的生成规则、触发阶段、描述与核心参数都已开始由表驱动。
- `S4-07` 已推进到第三阶段。当前仓库新增 `RarityTagBudget.txt -> DRRarityTagBudget -> RarityTagBudgetRuleRegistry -> ComponentTagGenerationService`，组件 Tag 数量预算不再写死在 `ResolveRarityTagBudget(...)` 的 `switch` 中，而是按品质从表驱动；至此生成链的候选过滤、权重抽取、数量预算三段都已进入 DataTable 消费闭环。
- `S4-07` 仍未完成最终收口。当前采用的是 `Tag.txt + RarityTagBudget.txt + TagConfig.txt` 的分层方案，而不是文档原方案里的单独 `TagRule`；更深的元数据字段与完整命名口径仍待后续决定是否继续统一。
### S4-06 当前代码状态
- 命中链路已统一为 `AttackPayload -> HitContext -> TagEffectResolver`，子弹命中时不再只传裸 `damage`。
- `Tower` 侧的 `TagRuntimes` 已能透传到战斗，且保留了旧 `Tags -> TagRuntimes` 的兼容入口，避免旧塔或旧展示数据在战斗中完全失效。
- 状态类 Tag 现在按单 Tag 文件拆分：
- 配置：每个 Tag 一个 `TagConfig`
- 运行时状态：每个状态类 Tag 一个 `TagState`
- 效果：每个状态类 Tag 一个 `TagEffect`
- 状态类 Tag 现在按职责目录拆分：
- `Metadata/Config`：每个 Tag 一个配置类
- `Combat/States`：每个状态类 Tag 一个运行时状态类
- `Combat/StatusEffects`：每个状态类 Tag 一个效果类
- `EnemyTagStatusRuntime` 已不再硬编码 `burn/slow` 字段，而是按激活的状态类 Tag 动态调度 Tick。
- `Fire` 已改为独立 DOT 公式：当前使用独立 `BurnDamagePerSecondPerStack`，并按敌人实体每帧提供的 `deltaTime` 连续结算，不再依赖命中伤害或内部 `TickInterval`。
- `Ice` 仍是独立减速状态，移速倍率通过状态运行时聚合得到。
@@ -220,6 +220,47 @@
| [ ] | S5-03 | 实现耐久扣减后的实际生效 | `Assets/GameMain/Scripts/CustomComponent/PlayerInventory/`<br>`Assets/GameMain/Scripts/Entity/` | 耐久不再只是展示字段 |
| [ ] | S5-04 | 实现 `0` 耐久销毁或失效闭环 | `Assets/GameMain/Scripts/CustomComponent/PlayerInventory/`<br>`Assets/GameMain/Scripts/UI/` | 归零后行为符合最终口径 |
### S5 规划结论
- `S5` 当前按“最小耐久闭环”推进，不展开维修、折价、复杂恢复、耐久与 Tag 联动等后续深度系统。
- M1 保留耐久规则，但当前目标只收口到“战斗后真实扣减 + 归零后真实失效 + UI 可解释”，不要求一并实现完整维修玩法。
- 本阶段优先保证耐久从展示字段变成实际规则入口，而不是继续增加额外经济系统或复杂数值衰减。
### S5-01 范围结论
- `S5-01` 建议明确保留耐久闭环，但只做组件实例级耐久，不新开修理站、维修货币、商店修复等额外系统。
- 当前阶段只处理战斗节点的耐久消耗；事件、商店、其他特殊节点暂不引入额外耐久变更。
- `0` 耐久当前建议先按“失效但不立即销毁实例”收口，避免在本阶段同时引入背包移除、组装解绑、自动清空参战区等高耦合逻辑。
### S5-02 推荐规则口径
- 耐久数据仍挂在组件实例上，塔本身不额外维护独立耐久池。
- 一座塔只要已装配的枪口 / 轴承 / 底座中任意一个组件耐久 `<= 0`，就视为损坏塔。
- 损坏塔不能进入参战区，也不能通过战斗入口最终校验。
- 当前阶段不实现“耐久越低属性越差”的连续衰减；在 `> 0` 耐久时，组件与塔仍按当前属性正常工作。
- 当前阶段不把耐久纳入品质、Tag、掉落或商店价格公式，避免把 `S5` 扩成新的综合规则层。
### S5-03 推荐实现口径
- 每次战斗节点结算后，对本场实际参战塔所装配的三个组件各扣 `1` 点耐久。
- 扣减结果必须真实回写到库存快照 / 当前 Run 库存，而不是只改战斗内临时对象。
- 参战合法性统一复用现有校验入口扩展，不额外再造一套“耐久专用判断链”。
- 战斗入口仍需要保留最终二次校验，避免旧快照或外部改动绕过组装区 / 参战区限制。
### S5-04 推荐闭环口径
- 组件耐久归零后，当前版本按“失效不可参战”收口，不立即自动销毁实例。
- 装配了 `0` 耐久组件的塔在 UI 上需要给出明确提示，例如“组件已损坏”或“耐久为 0，无法参战”。
- 若塔已在参战区且组件在上一场战斗后归零，需要在后续刷新中把该塔视为非法参战塔，并通过统一校验入口阻止再次进入战斗。
- “自动销毁组件”与“自动拆塔”保留到后续阶段再决定，当前不作为 `S5` 通过标准。
### S5 推荐执行顺序
1. 先完成 `S5-01`，把 M1 的耐久范围冻结为“最小闭环”，文档先对齐。
2. 再完成 `S5-02`，把“归零失效、非归零不衰减、不可参战”的规则写成统一口径。
3. 然后做 `S5-03`，把战斗结算后的耐久扣减与库存回写接进主链路。
4. 最后做 `S5-04`，补齐参战拦截、UI 提示与 `0` 耐久失效闭环。
## 阶段 S6 - 回归与文档收尾
| 状态 | ID | 任务 | 交付物路径 | 验收标准 |
@@ -235,15 +276,16 @@
2. `S2` 已完成口径对齐，`NodeMapForm` 不再作为 M1 阻塞项。
3. 接下来优先做 `S3`，补齐出战合法性，解决 `P0-10`。
4. 再做 `S4`，统一品质 / Tag 的规则口径，解决 `P0-11`。其中当前优先级已经收口为：`S4-06` 已完成，下一步转入 `S4-07` 的数据表映射。
5. 最后做 `S5`，决定耐久是完整收口还是同步缩范围，解决 `P0-12`。
5. 最后做 `S5`，按“最小耐久闭环”收口真实扣减、归零失效与参战拦截，解决 `P0-12`。
6. 全部完成后做 `S6`，补测试并同步文档状态。
## 本周建议开工顺序
1. `S1` 与 `S2` 已完成口径收口，可直接进入规则侧收尾
2. `S3-01 ~ S3-04` 已完成，当前可转入 `S4`
3. 当前转入 `S4-07`，把 `TagRule` / DataTable 映射真正接进运行时
4. 然后补 `S6-01 ~ S6-04`
3. 当前先完成 `S4-07` 的三表口径收口，并把 `Tag.txt` / `TagConfig.txt` / `RarityTagBudget.txt` 的实际消费链稳定下来
4. 然后转入 `S5-01 ~ S5-04`，按“最小耐久闭环”推进耐久真实生效
5. 最后补 `S6-01 ~ S6-04`
## 备注
docs/TODO.md
+10 -10
View File
@@ -9,13 +9,13 @@
2. 每项任务必须同时满足“交付物路径”和“验收标准”才可打勾。
3. 数据驱动优先：数值、掉落、商店、事件都优先落到 `DataTables`。
## M1 当前口径（2026-03-09）
## M1 当前口径（2026-03-11）
- 当前仓库已经具备 `ProcedureMain + NodeMapForm + CombatNode + EventNode + ShopNode` 的主流程 Run 闭环，可以从主菜单进入游戏，完成固定 10 节点流程，并在 Boss 结算后进入正式结束态并回到主菜单。
- `NodeMapForm` 已满足 MVP 所需的节点流程界面；M1 现在的真实缺口是合法出战 / 品质 / Tag / 耐久规则是否真正统一收口。
- `P0-10 ~ P0-12` 在代码里都已有局部实现，因此文档里统一按“部分完成但未收口”处理；只有满足最终验收标准后才可改成完成。
- `P0-11` 在 M1 中按“规则最小闭环”收口：只要求品质计算与 Tag 来源形成单一、可复现、跨流程共用的规则入口；配件槽位、Tag 数量 / 等级随机、Tag 战斗效果暂不作为当前 M1 阻塞项。
- `P0-11` 的 Tag 规则拆分已记录到 `docs/TagSystemDesign.md`：先收口实例生成、塔级汇总与首发 Tag 集合，再决定哪些效果进入战斗链路。
- `P0-10` 的“三组件完整合法参战”主链已落地：当前参战分配、战斗入口最终校验、失败原因与拦截提示都已接入统一合法性判断入口，但文档仍保留 `[~]`，直到与 `docs/CodeX-TODO.md` 的验收口径完全同步。
- `P0-11` 已不再只是“局部展示字段”：当前品质计算、Tag 生成、塔级 Tag 汇总、首发 7 个 Tag 的战斗效果、以及 `Tag.txt + RarityTagBudget.txt + TagConfig.txt` 三表驱动链路都已存在；剩余缺口主要是 `S4-07` 的最终文档口径与少量配置收口，而不是主功能缺失。
- `P0-12` 仍是当前 M1 最明确的规则缺口：已有耐久字段、展示与部分扣减入口，但还没有形成“战斗后真实扣减 -> 归零失效 -> 参战拦截”的最小闭环。
## 里程碑 M1（P0）- 最小可玩闭环
@@ -30,9 +30,9 @@
| [x] | P0-07 | 战斗节点基础玩法：放置塔、出怪、基地扣血、胜负判定 | `Assets/GameMain/Scripts/Entity/`<br>`Assets/GameMain/Scripts/Scene/` | 可完整打一场并得到胜利/失败结果 |
| [x] | P0-08 | 胜利波次与结算规则（100/80/50/<50） | `Assets/GameMain/Scripts/Procedure/` | 结算奖励与惩罚严格匹配设计文档 |
| [x] | P0-09 | 敌人掉落与关卡奖励（组件/配件/金币） | `Assets/GameMain/Scripts/Entity/` | 战斗结束能发放掉落并写入库存 |
| [~] | P0-10 | 节点后组装：枪口/轴承/底座三组件约束 | `Assets/GameMain/Scripts/Entity/`<br>`Assets/GameMain/Scripts/UI/Templates/GameScene/` | 当前只校验“参与区至少有 1 座塔”，尚未收口为“三组件完整合法参战” |
| [~] | P0-11 | 品质 / Tag 规则统一入口（白绿蓝紫红） | `Assets/GameMain/Scripts/Definition/`<br>`Assets/GameMain/Scripts/Entity/` | 品质计算与 Tag 来源在组装、掉落、商店、展示链路形成单一、可复现、跨流程共用的规则入口；配件槽位与 Tag 深度规则暂不作为当前 M1 阻塞项 |
| [~] | P0-12 | 组件/配件耐久生效与 0 耐久销毁 | `Assets/GameMain/Scripts/Entity/` | 已有耐久字段、展示与扣减入口，但尚未影响属性 / 出战资格，也未形成 `0` 耐久移除或失效闭环 |
| [~] | P0-10 | 节点后组装：枪口/轴承/底座三组件约束 | `Assets/GameMain/Scripts/Entity/`<br>`Assets/GameMain/Scripts/UI/Templates/GameScene/` | 当前已形成“三组件完整合法参战”的统一校验链与战斗入口拦截；剩余工作主要是同步文档口径与收尾验收 |
| [~] | P0-11 | 品质 / Tag 规则统一入口（白绿蓝紫红） | `Assets/GameMain/Scripts/Definition/`<br>`Assets/GameMain/Scripts/Entity/` | 当前已完成品质统一、Tag 生成/汇总/展示与首发 7 个 Tag 的战斗生效；剩余工作主要是三表方案的最终收口与文档同步 |
| [~] | P0-12 | 组件/配件耐久生效与 0 耐久销毁 | `Assets/GameMain/Scripts/Entity/` | 当前按“最小耐久闭环”推进：目标是形成战斗后真实扣减、`0` 耐久失效与参战拦截；维修系统、自动销毁等后续深度规则暂不作为本阶段阻塞项 |
## 里程碑 M2（P1）- 核心深度
@@ -63,9 +63,9 @@
## 本周建议开工顺序
1. 先完成 `P0-10`（把“至少有参战塔”提升为“满足完整合法参战条件才能出战”）
2. 再处理 `P0-11` ~ `P0-12`（先统一 M1 范围；`P0-11` 先收口品质 / Tag 的最小规则闭环，再决定是否扩展到完整深度设计）
3. 最后补关键流程 / 规则回归测试，并同步文档状态
1. 先完成 `P0-11` 的三表口径收口，把 `Tag.txt + RarityTagBudget.txt + TagConfig.txt` 的实际消费链与文档彻底对齐
2. 再推进 `P0-12`，按“最小耐久闭环”实现战斗后真实扣减、`0` 耐久失效与参战拦截
3. 最后补关键流程 / 规则回归测试，并同步 `docs/TODO.md` 与 `docs/CodeX-TODO.md` 的真实状态
## 设计优化 Backlog（新增）
docs/TagSystemDesign.md
+1 -1
View File
@@ -448,7 +448,7 @@ Tag 触发阶段固定拆成四段：
1. 先基于本设计回写 `docs/CodeX-TODO.md` 的 `S4-03` 边界
2. 在 `S4-07` 中补齐并消费 `Tag.txt + RarityTagBudget.txt + TagConfig.txt` 三层表结构
3. 新增 `TagGenerationService`，先收口实例生成
3. 新增 `ComponentTagGenerationService`，先收口实例生成
4. 新增 `TowerTagAggregationService`，替换当前简单并集逻辑
5. 评估 `AttackPayload` 是否并入现有 `BulletData`，还是单独引入
6. 第一批只落固定 7 个基础 Tag，避免超出 `MVP-Scope`