你好，我是 RRR

这个月我在做一个小游戏：俯视视角的卡通幸存者。你只负责走位，角色自动朝最近的敌人开火；怪一波波从屏幕外涌来，干掉它们掉经验，攒够了升一级。 它不是我最复杂的项目，但它是第一个从空文件夹开始、由我自己定规矩的项目——目录怎么分、数据放哪、怎么证明"它真的能用"，全部自己拍。记一下过程里最值钱的部分。 一、先决定"不做什么" 开工前我先把三件事钉死： 只做走位，不做瞄准。手机上触摸屏没有鼠标，强行做瞄准等于自找麻烦。攻击交给系统自动索敌——这不是偷懒，是让玩法在目标平台上成立的前提。 先跑通玩法，再换美术。所有角色当前都是几何图元（圆、多边形）。很多人卡在"没有美术就没法开始"，结果半年过去还在等素材。形状先跑起来，手感对了再换皮，换皮不动逻辑。 不抄自己已有的项目。我手上还有一个战斗向的幸存者项目，组件挺全。这次刻意不用——想让这套骨架是干净的，也想知道从零开始我到底会踩哪些坑。 二、架构：先定规矩，再写代码 第一版代码还没写，我先写了目录分层和五条规矩。core/ 放与玩法无关的东西，entities/ 放实体，systems/ 放玩法系统，data/ 放数值表。 框架层我做了五个"件"，每个都对应一个具体的痛： 件 解决的痛 事件总线 实体、系统、界面互相直接调用，改一处炸一片 局内状态 波次/击杀/等级散落各处，界面到处抓节点 对象池 战斗中频繁生成销毁，掉帧、内存碎片 分帧调度 同屏几十只怪各自每帧做寻路，单帧开销爆掉 音频管理 多处各自建播放器，同帧爆音 规矩里最关键的一条是数据与代码分离：所有数值（血量、速度、每波数量、间隔）都放在资源表里，改数值不动代码。听起来很基础，但它决定了后面调手感时你是在"调参"还是在"改代码"。 三、踩的五个坑（这部分最值钱） 1. 打包出来的场景，子节点全没了。 我用代码临时拼了一个"敌人"节点，加了受击体，然后打包成可复用的场景。运行起来发现敌人没有受击判定——一查，打包时只有归属为根节点的子节点会被保存，我临时加的子节点归属是空的，等于没被打包进去。表现是"子弹打不中敌人"，根因在打包那一步。这个坑很阴：代码本身没错，错在构建方式。 2. 对象池取敌人，取出来一个特效。 对象池按"场景的资源路径"分桶。我用代码新建的场景资源没有路径，结果四种场景全部落进同一个桶——取敌人可能拿到特效。修复是给每个运行时场景设置唯一路径。教训：凡是按 key 分桶的容器，都要保证 key 真的唯一，空 key 是最危险的 key。 3. 子弹在飞，打不中任何东西。 对象池把实例回收时会关掉碰撞检测（防止池里躺着的实例还参与判定），但取出复用时必须还原。我漏了还原，于是刚取出的子弹检测开关是关的，报错信息也很明确：“检测已关闭时无法查询重叠”。教训：池化的"休眠/唤醒"要成对维护状态，别只写一半。 4. 测试里刚加载完场景就取节点，拿到全是空。 场景初始化要等一帧才完成。测试代码里"加载 → 立刻断言"，拿到的全是未初始化的值——而且断言失败后我花了很久才意识到是时序问题而不是逻辑问题。后来所有用例统一先等一帧。 5. 我用了一个不存在的 API。 写测试运行器时我想判断"某个方法是不是协程"，凭印象写了一个运行时判断函数，跑起来直接报"不存在"。最后改成命名约定（需要等帧的用例统一加一个前缀）来区分。教训很朴素：先查文档再写，别凭印象用 API——尤其当这个 API 听起来"应该有"的时候。 四、验证这件事，比想象中重要 游戏开发里最危险的不是"有 bug"，是你以为它能用。 编译通过 ≠ 功能可用；功能看起来能跑 ≠ 画面是对的。我给自己定了三道闸门： 代码关：导入无报错、代码级测试全绿、端到端冒烟里"刷怪 / 开火 / 击杀"三件事真的发生了。 画面关：带窗口模式也要跑一遍自检，并用引擎自己渲染的截图做内容校验（玩家是否在画面中心、敌人可见吗、界面画出来了吗、地面正常吗）。 验收关：每个产出附路径与大小、小步提交可回滚、没验证的显式写"未验证"。 中间还遇到一次很典型的"假绿"：脚本语言里，函数体中途发生运行时错误会直接中断并返回默认值，不抛异常。如果测试写成"跑完打印一行汇总"，那么某段断言静默消失时，结果仍然是"全部通过"。所以我给测试套件加了断言总数守卫：每个用例有最小断言条数、全部用例有总条数下限，低于阈值一律判失败——宁可误报，不要假绿。 ...

这是我的第一篇文章。感谢你来到我的小站。 为什么要做这个站 作为 Godot 游戏开发者，我想有一个地方： 展示我的游戏作品 记录开发日志 分享踩坑与心得 如果你也对 Godot 感兴趣，欢迎交流。