190 lines
8.5 KiB
Markdown
190 lines
8.5 KiB
Markdown
# 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）
|