今日目标

今天的阶段任务原本围绕这几个关键词展开：

• 起始房 / 战斗房 / Boss 房白盒
• 房间切换
• StageFlow
• 简易结算

今日完成内容

1. 明确房间建模方式

先确定了当前阶段的关卡结构不采用“一个房间一个场景”的做法，而是先按以下思路推进：

• 整个副本流程先在同一开发场景中验证
• 各房间作为独立的房间对象 / 预制体单元
• 当前阶段先走固定流程，不做随机房间生成

这一步的意义在于先把玩法闭环跑通，而不是提前陷入关卡系统设计。

2. 搭建了大厅、战斗房、Boss 房白盒

已完成：

• 一个玩家大厅白盒
• 至少一个普通战斗房
• 一个 Boss 房

在大厅中也尝试了若干交互点的功能分区设计，包括：

• 出生区
• 副本入口
• 商店 / 任务 / 储物箱等区域预留

当前阶段功能未全部实现，但空间语义已经开始建立。

3. 明确了玩家和怪物应该尽快做成测试预制体

本轮对话中完成了几个关键判断：

• 玩家和怪物这种会重复使用、反复测试的对象，应该尽快 prefab 化
• 大厅内功能点不急着马上做全，优先保证战斗测试链路成立
• 当前阶段更重要的是副本战斗最小闭环，而不是大厅深度玩法

这让开发优先级重新聚焦到主循环上。

4. 跑通了玩家运行时生成与相机绑定思路

由于玩家改成了运行时实例化的 prefab，Cinemachine 虚拟相机就不能再依赖编辑器里预绑目标。

因此确认了新的处理方式：

• 玩家运行时生成
• 由相机绑定逻辑在运行时把 Follow / LookAt 指向玩家
• 后续如果需要，可以给玩家加 CameraTarget 挂点

这块为后面的传送、切关、重生等流程打了基础。

5. 梳理了 CharacterController 与碰撞 / 检测的若干坑

今天在房间白盒和战斗调试过程中，集中踩到了一批 Unity 典型坑，已基本厘清：

角色阻挡问题

确认了“看起来没加 Collider 但能挡路”的问题，本质还是碰撞体、模型结构、整体 FBX 以及 CharacterController 胶囊体共同作用的结果。

整体 FBX 房间碰撞问题

发现房间作为整体 FBX 时，所谓“只给地面加碰撞”并不总是真的只作用于地面，因此后续更适合采用：

• 显示模型与碰撞分离
• 用多个简单 BoxCollider 组合逼近墙体与拐角

拐角碰撞方案

明确了当前阶段不要追求精确 MeshCollider，而是：

• 用 3 到 5 个旋转过的 BoxCollider 分段拼接
• 优先保证可走和不穿墙
• 次要才是完美贴轮廓

6. 明确了怪物刷怪逻辑应归属于房间，而不是全局刷怪器

因为本项目的副本是房间制，不是吸血鬼幸存者式的大地图持续刷怪，所以怪物生成逻辑从一开始就不应照搬全局刷怪管理器思路。

最终确认的方向：

• 每个战斗房自己管理本房刷怪
• 房间控制器决定“什么时候刷、刷什么”
• 通用刷怪逻辑负责真正实例化怪物
• 清怪判定由房间维护

同时也明确了刷怪位置不应该优先用裸 Vector3[]，而是先使用房间内手摆的 Transform 生成点。

7. 梳理了怪物 AI、攻击、死亡通知的职责边界

今天围绕怪物系统有几次重要收敛：

攻击逻辑职责

确认了 AI 不该自己用 while 循环硬触发攻击，而应该：

• AI 决定“要不要攻击”
• Attack 组件决定“能不能攻击 / CD 是否结束 / 怎么打”

也就是从“AI 自己打”改成“AI 依赖攻击组件，持续尝试攻击”。

死亡通知职责

确认了仅靠 IDamageable 不够表达“死亡通知能力”，因此在抽象层面明确了：

• IDamageable 表达“可受伤”
• 另一个接口表达“可通知死亡”

这为后续房间清怪判定和刷怪器监听死亡打下了设计边界。

房间清怪判定

明确了房间内敌人死亡判断应该维护：

• 当前房间存活怪物实例列表
• 或至少有一个死亡计数 / 回调链路

而不是每帧暴力轮询。

8. 跑通了统一交互入口思路

这是今天最关键的一块之一。

交互系统设计收敛

最终确认：

• 玩家侧统一监听交互输入
• 玩家维护当前交互对象 currentInteractable
• 所有可交互对象实现统一交互接口
• 按键时由玩家脚本统一调用当前对象的 Interact()

这意味着：

• 门、箱子、NPC 不再各自监听输入
• 触发器只负责注册 / 清理当前交互对象
• 输入系统和交互对象实现了解耦

输入系统排查结果

中途一度出现“E 键偶发触发”的错觉，最后定位到根因：

• Interact Action 被配置了 Hold
• 必须长按超过约 0.5 秒才会触发 performed

去掉后，普通交互输入恢复正常。

这次排查顺手也加深了对 Input System 中 started / performed / canceled 与 Interaction 配置的理解。

9. 房间传送流程打通

今天已经把最小房间流转跑通。

初版门逻辑

最开始尝试了门触发器 + 靠近交互 + 玩家传送的方案。

过程中踩了这些坑：

• 触发器状态不稳定
• currentInteractable 残留
• 传送后相机缓慢跟随，手感不好
• 门在正交相机下视觉表现差

流程方案收束

最终把思路从“门自己负责一切”调整成：

• 门 / UI 都只是流程推进入口
• StageFlow 负责真正的阶段切换和传送

目前已跑通固定流程：

• 大厅
• 战斗房
• Boss 房
• 回大厅

这是今天最大的阶段成果。

10. 确定 UI 化推进比 3D 门更适合当前素材条件

由于当前美术资源有限，且正交相机下 3D 发光门板表现不理想，最终决定：

• 不再强行把“下一关”依赖 3D 门表现
• 改为每关结束时弹出过关 / 结算 Panel
• 下一关由按钮推进

这比继续硬做 3D 门：

• 更稳定
• 更省时间
• 更容易统一风格
• 更适合当前原型阶段

11. StageFlow 收口方向明确

当前决定把 StageFlow 做成单例，用最简单、最高效的方式先接住流程：

• 维护关卡列表
• 管理当前阶段
• 控制关卡对象显隐
• 执行玩家传送
• 最终接结算 UI

同时也明确：

• 当前阶段允许硬编码固定流程
• GameObject / 房间对象直接拖拽到列表即可
• 不急着上复杂配置表和随机流程图

这是对当前工期压力的一个非常务实的取舍。

今天踩到的关键坑

1. Input System 的 Hold 配置误判成了“交互逻辑随机失效”

表面看像代码有问题，实际是 Input Action 的 Interaction 配置在作怪。

2. CharacterController 与位置修改 / 碰撞 / 传送行为

直接改位置虽然能瞬移角色，但会引出：

• 相机阻尼拖尾
• 触发器状态异常
• 碰撞修正问题

后续还需要进一步收口。

3. Sprite / 9-slice / UI 贴图在素材分辨率不足时很容易糊

也暴露出当前阶段美术资源质量会直接影响 UI 观感。

4. 原计划中“房间白盒 + 副本流”明显低估了耗时

实际开发花了两天，这说明后续开发节奏必须继续收紧，减少无效手搓。

当前项目状态判断

虽然这一阶段的耗时超出了原始排期，但从成果来看，项目已经跨过了一个很关键的坎：

从局部功能开发，进入到了“完整副本流雏形可运行”的阶段。

这意味着后续很多东西终于有了真正能挂载的主干，包括：

• 结算 UI
• 奖励数据
• 背包同步
• Boss 原型
• 角色表现
• 数据驱动配置

下一步开发重点

第一优先级：结算 UI

下一步要先完成一个最小 ResultPanel，至少包含：

• 标题（成功 / 失败）
• 击杀数
• 奖励占位
• 返回大厅 / 下一步按钮

第二优先级：把关卡推进收进 StageFlow

当前门逻辑已经完成验证，接下来应当：

• 保留门作为入口或装饰
• 把真正的流程推进统一收口到 StageFlow

第三优先级：角色和 Boss 内容补齐

虽然副本流程已通，但当前战斗内容明显偏弱：

• 玩家攻击只有出拳
• Boss 还没有真正制作

这一块后面必须补，但不应该在今天继续扩坑。