basil
/
geometry-tower-defense
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
geometry-tower-defense/design/gdd/gdd-cross-review-2026-04-29.md

8.5 KiB
Raw Blame History

Cross-GDD Review Report

Date: 2026/04/29 GDDs Reviewed: 2 Systems Covered: Node System, Tower Assembly

一致性问题 (Consistency Issues)

警告级 (Warnings)

⚠️ TryDisassembleTower 未实现但 UI 可调用

  • GDD: tower-assembly.md Open Question #1
  • 问题: node-system.md R3 规定"组装后可以免费拆解"，Assembly Phase UI 也提供 Disassemble 选项。但 tower-assembly.md 明确标注 TryDisassembleTower 方法不存在。玩家看到可点击的 Disassemble 按钮但无法使用，属于误导性 UI。
  • 建议: tower-assembly.md 应将 Open Question #1 从 "OPEN" 改为标注为 "Blocking — GDD 自洽性受损"，直至方法实现

游戏设计问题 (Game Design Issues)

阻塞级 (Blocking)

🔴 Boss 难度曲线可能无法追赶 — 威胁两大系统核心幻想

位置: node-system.md Boss Difficulty Scaling 公式；tower-assembly.md Stat Scaling

问题描述:

  • Boss HP 增长: BossEffectiveHp = DRLevel.BaseHp × 2^(completedLoopCount) — 指数增长
  • 玩家战力增长: Tower Assembly 提供线性成长（每场战斗最多 8 次升级事件，每次 baseValue + perLevel * i）
  • 在某个 loop 阈值后，玩家数学上无法击败 Boss

设计后果:

  • node-system.md Player Fantasy: "whether I survive depends on how I prepare" — 若准备永远不够，此幻想崩塌
  • tower-assembly.md Player Fantasy: "arrange pieces to solve it" — 若 puzzle 解不开，此幻想崩塌
  • 两大系统的核心幻想共享同一个前提：玩家准备应当是充分的

未知依赖: DRMuzzleComp、DRBearingComp、DRBaseComp 数据表值未知，无法验证实际成长率

设计建议:

  1. 在 Boss 战中引入 catch-up 机制（每 loop 玩家获得临时增益）
  2. 让 Tower Assembly 存在超线性成长路径（tag synergy、combo 机制）
  3. 降低 Boss 的指数系数（从 ×2 改为 ×1.3~1.5）
  4. 在 node-system.md 中明确说明"Boss 的设计意图是部分玩家无法一次通关"以调整预期

🔴 无 Gold 消耗强制机制 — 经济回路开放无界

位置: node-system.md 经济表格（1100 gold 上限）；tower-assembly.md 无 gold sink 定义

问题描述:

  • 6 场 Combat 节点共 600 gold，Boss 胜利额外 500 gold，最大总量 1100 gold/run
  • Shop Node 4 和 8 奖励 0 gold，不强制消费
  • 无任何机制（修理费、强制升级、门票等）要求消耗 gold
  • Shop System GDD（待编写）必须定义强制消耗场景，否则 Shop 节点沦为 UI 空操作

风险: Shop 节点存在但内容空洞，玩家跳过购买不打 Boss —— 浪费了 2 个节点的设计价值

警告级 (Warnings)

⚠️ 塔组装存在显然的最优策略

位置: tower-assembly.md R7（无组件兼容性约束）

问题: 任意 Muzzle+Bearing+Base 组合均可。Rarity Resolution 取算术均值：

  • Red(5)+Red(5)+Red(5) → 均值 5.0 → Red Tower
  • Red(5)+Green(2)+White(1) → 均值 2.67 → 向下取整 → Green Tower（比单 Red 差）

结论: 贪婪地堆最高稀有度组件永远是最优策略，无任何权衡代价。塔组装的最优解是排序后取 top 3，无需战术思考。

建议: 引入稀有度以外的优化维度：

  • Tag synergy 机制（Fire+Ice 组合产生额外效果）
  • Endurance 配平（3 高稀有度 = 3 高损耗率，混合可延长功能性）
  • Roster slot 约束下的边际收益（分散稀有度可在 4 槽位限制下覆盖更多敌人类型）

⚠️ 节点选择若两条路径难度不同，最优路径显而易见

位置: node-system.md 节点选择流程

问题: 每 junction 显示 2 个目的节点类型。若两条路径在难度/奖励上存在差异（比如两 Combat 但一个是 L1 一个是 L3），"战术决策"退化为"比较两个数字"。

建议: 确保两条分支在难度和奖励上等价，或引入隐藏变量（敌人波次、特殊条件）使玩家无法在选择前判断哪个更有利。

⚠️ 玩家注意力预算已达上限，无扩展空间

当前 Assembly Phase + Node Choice 时活跃系统: 4 个

  1. Tower Assembly 决策（选 3 组件组合）
  2. Roster 管理（4 槽位分配）
  3. 下个节点威胁评估（已知类型 + 难度）
  4. 节点二选一（强制决策）

设计阈值: 技能定义 >4 时触发警告，当前 = 4（刚好达标）

风险: Event System（待设计）若在 Assembly Phase 窗口引入额外主动决策（如事件影响当前备战），预算立即超标。

⚠️ Pillar 轻微漂移

GDD Pillar 声明 实际行为 漂移程度
node-system.md "players drive their own path" 节点类型序列固定（Plain 主题下所有玩家路径相同）；Junction 处只选顺序不选类型 轻微 — "path" 实为"choice order"
tower-assembly.md "adaptation to known threats" Shop/Event 节点无需塔组装决策；"adaptation" 对 30% 节点不适用 轻微 — pillar 覆盖部分场景

跨系统场景问题 (Cross-System Scenario Issues)

场景走过: 3 个

🔴 场景1: 战斗结束 → 组件掉落 → 塔组装（数据流歧义）

涉及系统: Combat → Inventory → Tower Assembly

问题描述: Combat 节点完成后，组件掉落通过 InventoryComponent.AddItem 进入 inventory。接口未定义：

  • 掉落的是全新组件实例（InstanceId 新生成）？
  • 还是对现有组件的修改（如 IsAssembledIntoTower 标记改变）？

隐患: 若为后者，而玩家在 Assembly Phase 前一步已组装了某些塔，战损标记可能与已组装组件的状态产生歧义。

需确认: InventoryComponent.AddItem 的精确语义，建议在 node-system.md Dependencies 或接口协议中明确定义。

⚠️ 场景2: Boss 前夕的 Assembly Phase（难度曲线验证）

涉及系统: Node System + Tower Assembly + Combat

问题描述: 玩家在 Node 9 完成后进入 Assembly Phase，此时 BossEffectiveHp 是可计算的（因 completedLoopCount 已知）。玩家可以提前计算胜率。

风险:

  • 若计算结果为正 → Boss 战是仪式感结局，fantasy 得到验证
  • 若计算结果为负 → 玩家感受到"数值碾压"而非"战术压力"，两大系统的核心幻想同时受损

需验证:

  • BossEffectiveHp 是否对玩家 UI 可见（建议：仅在 Boss 血条上显示，不显示计算公式）
  • 实际 tower DPT（每秒伤害）是否能与指数增长的 Boss HP 达到动态平衡

ℹ️ 场景3: Degraded 塔在战斗开始时的处理

涉及系统: Tower Assembly + Combat

问题描述: tower-assembly.md 明确："mid-combat 降级不会自动从 roster 移除"。但 CombatNodeComponent 的 roster 验证逻辑未定义。

两种处理方式的后果:

  • 若验证在战斗开始时：degraded 塔被筛除，玩家以 <4 塔对抗预期敌人规模
  • 若验证在战斗进行中：塔在战斗中失效，战斗难度非线性上升

建议: 在 tower-assembly.md Acceptance Criteria 中补充：CombatNodeComponent 必须在战斗开始前调用 CombatParticipantTowerValidationService.ValidateParticipantTowers，拒绝 degraded 塔入战。

GDD 标记需修订

GDD 原因 类型 优先级
tower-assembly.md TryDisassembleTower 未实现但 UI 可调用；Open Question #1 应更新状态为 Blocking 设计完整性 Warning
node-system.md Boss catchability 需在 GDD 中明确设计意图；建议补充"战斗开始前 roster 验证逻辑"的跨系统约定 难度曲线 Warning
systems-index.md Combat System 标注"Designed"但 GDD 在 docs/CombatNodeArchitecture.md 而非 design/gdd/，文档位置不统一 文档管理 Warning

Verdict: CONCERNS

存在 2 个阻塞级问题（Boss catchability + 无 gold sink）和多个警告级问题。阻塞问题不会阻止架构设计，但应在 /create-architecture 前明确设计意图。

Next Steps

  • /design-system shop — 编写 Shop System GDD（阻塞项：gold sink 定义）
  • /design-system event — 编写 Event System GDD（阻塞项：EventContext 合约）
  • /design-system progression — 编写 Progression GDD（阻塞项：RunEnd 数据持久化）
  • /design-review tower-assembly — 修订 Open Question #1 并更新 TryDisassembleTower 状态
  • /create-architecture — 在所有 MVP GDD 完成后开始架构设计（Verdict 为 CONCERNS 但非 FAIL）