用 Codex 完成 Cocos Creator 战斗闭环多波次、场景拆分与一次栈溢出复盘从单波演示切片到完整多波战斗状态机的真实开发记录今天继续使用 Codex 推进一个基于 Cocos Creator 3.8.8 和oops-plugin-framework的战斗模块。目标不是继续堆功能而是把原本只能演示一波的战斗切片推进为真正可循环的战斗闭环读取多波配置、在准备与战斗阶段切换商店、正确进入下一波、保留跨波状态并把 BattleStage 从 UI 层迁回场景层。过程中还遇到了一次场景序列化引用错误导致 Cocos 打开battle.scene时出现Maximum call stack size exceeded。本文记录问题、根因、修复思路和验证结果。推荐标签CodexCocos CreatorTypeScriptECS游戏开发AI 编程自动化测试今天的目标把“一波演示”做成战斗闭环此前的战斗模块已经具备一条最小可运行链路进入战斗 → 购买并放置武器 → 开始刷怪 → 武器攻击怪物 → 怪物攻击基地 → 胜利或失败看起来已经“能打”但它更接近一个首波演示切片还不是完整的关卡流程。实际运行后暴露出几个很明显的问题配置表里虽然有多波数据运行时却只读取第一波。点击开始战斗后商店仍然停留在界面上。清完怪物后直接结束没有进入下一波准备阶段。怪物会按移动方向旋转但美术资源只适合左右翻面。BattleStage 虽然使用场景 Layer节点本身却仍挂在 Canvas 下面。这几个问题分别涉及配置读取、ECS 状态机、HUD 映射、表现层和场景结构不能靠在按钮回调里补几个判断解决。问题一为什么配置里有多波游戏却永远只有一波排查后发现第一版实现从命名到数据结构都带着“首波切片”的假设配置仓库只组装第一波快照运行时的waveLimit也相当于固定为 1。因此怪物清空后系统看到的不是“本波完成”而是“整个关卡完成”。修复的关键不是简单地把waveLimit改成一个更大的数字而是让数据层真正返回完整的波次数组以及每一波对应的商店配置ChapterSnapshot ├─ waves[0] ├─ waves[1] ├─ waves[2] └─ shopPropIdsByWave ├─ 第 1 波商店 ├─ 第 2 波商店 └─ 第 3 波商店运行时再根据当前波次读取对应配置而不是反复使用第一波数据。战斗状态机也要一起调整多波战斗的正确流程应该是Prepare显示商店 │ 点击“开始本波” ▼ Combat隐藏商店并刷怪 │ ├─ 基地生命归零 ─────────────→ Defeat │ └─ 本波怪物全部清空 │ ├─ 还有下一波 ─────────→ Prepare │ 加载下一波商店 │ └─ 已是最后一波 ───────→ Victory图 2Prepare、Combat、下一波准备以及最终胜负的完整状态流转。这里特别需要区分“本波状态”和“整场战斗状态”。进入下一波时只重置刷怪游标、刷怪计时和当前波配置以下内容应继续保留当前金币已经放置或合成的武器基地剩余生命已经产生的战斗进度。图 3换波不是重新开局。整场战斗状态继续保留本波临时状态重新初始化。如果把整个 ECS 实体重新初始化第二波虽然能开始但玩家上一波的所有积累也会被清空。这种修复表面上解决了跳波问题实际上破坏了玩法连续性。问题二商店“不可点击”不等于商店“已经隐藏”第一版 HUD 只在进入 Combat 后关闭了按钮交互却没有改变商店区域的可见性。对程序来说按钮确实不能再点但对玩家来说商店仍然占据屏幕空间看起来就像战斗没有真正开始。所以这次把两个概念拆开处理controlsInteractable控件当前能否操作 shopVisible商店区域当前是否显示准备阶段显示商店和“开始本波”按钮进入战斗阶段后隐藏整块商店清完非末波怪物后再显示下一波的商店内容。这也让我再次意识到UI 状态不能只围绕“按钮能不能点”设计。交互、可见性和数据内容是三件不同的事情应该分别由明确的状态控制。问题三怪物不应该沿路径任意旋转怪物移动表现原本会根据运动方向修改旋转角度。逻辑上没错但当前怪物素材带有固定的原始角度任意旋转后会出现倾斜、倒置等视觉问题。最终规则改成保持怪物 Prefab 中的原始旋转向右移动时使用原始横向缩放向左移动时仅翻转scale.x纯竖直移动或静止时保持上一次朝向。核心判断可以概括为if (currentX lastX) { // 向左水平翻面 scaleX -baseScaleX; } else if (currentX lastX) { // 向右恢复原始方向 scaleX baseScaleX; }这里没有再调用旋转接口。这样既满足移动反馈也尊重美术资源的原始构图。对应回归测试检查了三件事怪物保持原始角度、横向移动只改变 X 轴缩放、竖直移动不会改变朝向。问题四使用 DEFAULT Layer不代表它已经脱离 UI今天最重要的一次结构调整是把 BattleStage 从 Canvas 所有权下移回战斗场景。之前的结构大致是battle.scene └─ Canvas ├─ WorldRoot │ └─ BattleStage └─ CameraBattleStage 虽然设置为DEFAULTLayer并由战斗相机渲染但它依然是 Canvas 的子节点。这意味着它仍会受到 UI 画布尺寸、屏幕适配和坐标基准的影响。Layer 解决的是“哪个相机能看到它”并不决定“这个节点属于场景还是 UI”。调整后的职责边界是battle.scene └─ BattleWorld场景渲染根 ├─ WorldCamera └─ WorldRoot └─ BattleStage 常驻 GUI Canvas └─ BattleUIHUD图 4调整前 BattleStage 仍属于 Canvas调整后战斗世界与常驻 GUI 分别拥有自己的职责边界。新的边界更清晰BattleStage、格子、角色、怪物、武器和特效属于战斗场景BattleUI 属于常驻 GUI 系统战斗相机只渲染场景层GUI 相机只负责 HUD战斗入口通过明确的worldRoot和worldCamera绑定启动场景不再依赖查找 Canvas。这个调整短期看只是移动节点长期却会直接影响相机缩放、地图扩展、震屏、不同分辨率适配以及资源释放是否可靠。最棘手的问题打开 battle.scene 直接栈溢出场景结构调整完成后双击打开battle.sceneCocos 控制台出现Maximum call stack size exceeded这类错误容易让人先怀疑业务脚本递归但当时场景甚至还没有正常完成反序列化问题更可能出在.scene文件的对象引用上。进一步检查场景序列化数据后发现重排对象编号时SceneGlobals.ambient错误地指向了SceneGlobals自身。等价关系类似这样SceneGlobals └─ ambient ──────→ SceneGlobals图 5ambient错误指向SceneGlobals自身反序列化时形成循环修复后各字段指向声明类型正确的独立对象。Cocos 在反序列化这个引用时不断回到同一个对象最终触发调用栈溢出。这次没有只改一个数字为了避免“修完 ambient下次又错在 skybox”我补了一项场景边界测试验证SceneGlobals中每一个引用都指向声明类型正确的对象并禁止出现自引用或循环引用。排查过程可以概括为根据报错判断发生在场景反序列化阶段 → 解析 battle.scene 的对象数组 → 建立 __id__ 引用关系 → 检查 SceneGlobals 的目标类型 → 发现 ambient 自引用 → 修正全部 SceneGlobals 引用 → 用回归测试锁定边界相比“把场景改到能打开”这种测试更重要的价值是防止以后再次重排序列化对象时引入同类问题。我是怎样让 Codex 参与这次开发的今天比较有效的协作方式不是一句“帮我修好战斗”而是把每次反馈限定为可以验证的行为现象当前只有一波 期望清完非末波后进入下一波准备阶段 保留金币、武器和基地生命 现象战斗开始后商店仍显示 期望Combat 阶段隐藏Prepare 阶段显示 现象怪物沿路径旋转 期望保留原始角度只允许左右翻面 现象BattleStage 在 Canvas 下 期望场景拥有 BattleStageGUI 只拥有 HUD在这种输入下Codex 更容易先找到真正的所有权和状态边界再补测试、修改代码并验证而不是只对表面现象打补丁。我认为 AI 编程中很重要的一点是人负责说清楚什么行为才算正确AI 负责扩大检索范围、追踪调用链并执行大量机械验证。两边职责越清楚修改越稳定。验证结果本次修改完成后重新执行了验证Cocos Creator TypeScript 检查通过多波配置、跨波状态、商店切换、怪物左右翻面和场景引用等聚焦测试通过全量 Node 测试为134/141 通过剩余 7 项包括 2 项序列化资源断言和 5 项既有 Loading 资源/测试辅助问题需要在后续继续清理git diff --check通过今日代码已提交为首版战斗闭环。需要说明的是自动化测试通过不等于编辑器内体验已经完美。下一步仍要在 Cocos Editor 中完整跑一遍进入战斗、购买放置、开始第一波、切换第二波、完成结算再返回主界面。今天的几个结论1. 多波战斗不是循环次数加一它要求数据、状态机、HUD 和结算判定同时理解“当前波”和“整场战斗”的区别。2. Layer 不是节点所有权渲染层正确不代表场景结构正确。Canvas 下的节点依然属于 UI 坐标体系。3. 表现规则要服从素材特性数学上正确的任意方向旋转不一定适合实际美术资源。只做左右翻面反而更稳定。4. 序列化文件也需要边界测试场景和 Prefab 不只是“编辑器生成的资源”它们同样包含对象关系和结构约束也可能因为引用错误而完全无法打开。5. 使用 Codex 时验收条件比提示词长度更重要“修好战斗”很模糊“非末波清怪后回到 Prepare并保留金币、武器和基地生命”才是可实现、可测试的要求。结语今天没有增加特别炫目的新玩法却完成了战斗模块从“可以演示”到“形成闭环”的关键一步。多波次、商店阶段切换、场景与 UI 分层、怪物表现修正看起来是几个独立问题最终都指向同一件事把状态和所有权边界做清楚。而那次Maximum call stack size exceeded也提醒我AI 可以快速重构大量代码和资源但速度越快越需要测试替我们守住那些肉眼不容易发现的结构约束。下一步会继续处理剩余资源测试并在 Cocos Editor 中完成整场战斗的人工回归。