Ludo Atlas · 引擎轨道 · Defold¶
引擎轨道。定位：免费、源码开放的轻量引擎，Lua 脚本加组件与消息的工作模型，2D 与移动端、HTML5 的小体量项目是主场。 配套：《技术实现手册》·《全平台上架手册》·《独立开发生存手册》·《避坑大全》。
1. 定位与选型¶
Defold 是一款免费的跨平台游戏引擎，由独立基金会维护，源码公开，可读可改；商用游戏没有授权费、没有收入分成。它从移动与网页游戏起家，体量小、启动快是刻在基因里的设计目标。
工程侧有三个基本盘：
- 脚本语言只有 Lua：语法小、上手快，没有第二种官方语言可选。
- 全内置工作台：场景、粒子、瓦片地图、GUI 与代码编辑器、调试器、分析器全在编辑器里，装好即用。
- 2D 优先：精灵、图集、瓦片地图、粒子、序列帧与 Spine 骨骼动画开箱可用；3D 能跑，但工具链不深。
适合谁¶
- 独立开发者与小团队：零成本起步，工程轻，一个工程覆盖桌面、移动与 Web。
- 2D 小体量与休闲玩法：内容量可控的项目，轻量优势会直接变成交付速度。
- HTML5 与网页平台：包体与启动是硬指标的场景，导出与平台 SDK 扩展现成可用。
- 移动端为主的轻量项目：安卓与 iOS 导出成熟，真机调试链路顺。
- 熟悉或愿意学 Lua 的人：语言门槛低，引擎 API 直白。
不适合谁¶
- 内容量大、策划美术重度协作的项目：编辑器工具面窄于主流引擎，协作靠约定兜。
- 重度 3D 与写实画面：不是它的战场。
- 重度依赖商业插件与中间件的团队：生态小，很多能力要自研或找社区库。
- 打算快速扩编团队的项目：会用 Defold 的人少，招人难（见 §7）。
- 只靠中文资料学习者：中文内容少，主线文档以英文为主。
与 Godot、Cocos 的取舍¶
| 场景 | Defold | Godot | Cocos |
|---|---|---|---|
| 轻量 2D、小体量成品 | 首选：体量小、出包快 | 可用，工程更重 | 可用，2D 成熟 |
| HTML5 与国际网页平台 | 首选：小体积导出、平台 SDK 扩展现成 | 导出偏重，需实测 | 可用，主战场在国内 |
| 微信/抖音小游戏 | 链路弱 | 较弱 | 首选 |
| 中等以上内容量的 2D | 可用，接受编辑器与生态偏窄 | 更稳 | 更稳 |
| 3D 项目 | 只限轻量风格化 | 中等体量可用 | 轻中度可用 |
| 生态、教程与招人 | 最少 | 厚 | 国内厚 |
| 许可 | 免费，源码开放 | 免费，全开源 | 编辑器免费，运行时开源 |
取舍只问三件事：目标平台里有没有 HTML5 或轻量移动端、项目是不是小体量、团队能不能接受小生态。三问皆「是」，Defold 是高效选择；有一问答「否」，回引擎轨道索引重新评估。
2. 生态与工程结构¶
生态现状先摆正：官方文档质量不错、更新勤，论坛有官方团队常驻；第三方规模小，插件、素材、成品方案与教程的量级都远小于 Godot 与 Unity，中文内容尤其少。依赖没有中心包仓库，以压缩包 URL 挂在工程配置里；编辑器扩展用 Lua 写，接平台 SDK 与做性能手术走 C/C++ 原生扩展。
工程主干很小，没有复杂骨架：
| 位置 | 放什么 |
|---|---|
game.project |
工程配置：显示、物理、输入绑定、资源打包、依赖列表；纯文本，进版本库 |
集合（.collection） |
场景单位与启动入口；一个工程至少一个主集合（见 §4.3） |
游戏对象（.go）与脚本（.script） |
角色、组件与逻辑，按功能分目录就近放 |
| 图集、字体、材质、粒子、GUI 等资源 | 内容本体；2D 精灵通常先归拢进图集再使用 |
.internal/ 与 build/ |
编辑器缓存与构建产物，都不进版本库 |
资源管线有三条习惯：
- 构建只收「从主集合引用可达」的资源，没被引用的文件不会进包；动态加载的资源也必须在引用链上（见 §7）。
- 资源改名与移动尽量在编辑器里做，引用自动同步；手工搬文件会断链。
- 依赖升级与平台 SDK 更新都要配回归清单，手动替换、手动验证。
版本控制：Defold 与 Git 配合良好，工程文件是文本格式、可 diff；编辑器里有文件改动面板看状态与 diff，提交推送仍走外部 Git 客户端。集合与游戏对象这类结构化文件的编辑冲突基本没有手工合并的余地，靠「一文件同一时间一人改」的约定绕开（见 §7）。
3. 核心工作流¶
3.1 从零到能跑¶
- 装编辑器（Windows、macOS、Linux 都有），新建工程；编辑器自带代码编辑与调试，先跑通自带示例。
- 立主集合：把入口场景做成主集合，按「背景、玩家、相机」搭出最小可运行内容。
- 挂脚本、加输入：脚本作为组件挂上游戏对象；输入先在输入绑定里声明动作，再让脚本按动作响应（见 §4.5）。
- 跑起来：编辑器内直接运行，脚本改动热重载；报错看控制台，真机问题连真机调试。
- 进版本控制：忽略编辑器缓存与构建产物，首次提交后确认工程能在干净环境重建。
- 出第一份包：桌面、安卓与 HTML5 各打一份，再走一遍发布清单（细节见《全平台上架手册》）。
3.2 构建、打包与热更¶
- 桌面（Windows、macOS、Linux）：流程最顺，签名与分发按渠道要求走。
- 移动（Android、iOS）：安卓要签名密钥与包名；iOS 打包签名依赖 macOS 工具链，非 Mac 团队提前安排。
- HTML5：产出一份可直接托管的静态站点；网页游戏平台（Poki、CrazyGames 这类）有现成 SDK 扩展可接。
- 主机（Switch、PlayStation）：走平台批准的开发者通道，没有公开自助流程。
- 资源热更（Live Update）：把非首屏资源排除出包、运行时下载挂载；编辑器内运行不支持，必须打包验证。
- 自动化：命令行构建工具（bob，需要 Java 环境）可无界面执行构建，适合接 CI 做每日构建（基建清单见《技术实现手册》§6）。
4. 关键系统惯用法¶
先接受这套工作模型，再动手：对象靠组件拼装，组件靠消息通信。
4.1 游戏对象与组件：拼装优先¶
- 引擎的最小单位是游戏对象（game object）：位置、旋转、缩放，本身不写行为。
- 行为全部来自组件：精灵、标签、碰撞对象、声音、粒子、瓦片地图、模型、相机、脚本；挂什么组件，就有什么能力。
- 游戏对象不能再嵌套游戏对象；层级与复用靠集合（见 §4.3）。给对象加能力就挂组件，避免养出一个万能脚本。
- 数值参数放组件属性：脚本声明属性后在编辑器里暴露，改参数不用动代码。
4.2 消息传递：组件之间用消息说话¶
- 组件不互相直接调用，通信走消息传递（message passing）：发送方指定接收地址（「哪个对象的哪个组件」），附上消息名与数据，接收方在回调里响应。
- 生命周期回调点名：初始化、每帧更新、固定步长更新（物理）、收到消息、收到输入、热重载、销毁清理。
- 消息是异步的：适合事件通知（受击、拾取、状态变化），不适合每帧高频的数据追问；每帧耦合用属性直接读写。
- 地址字符串集中成常量：拼错只有运行时才暴露，热路径上临时拼接还吃性能。
4.3 集合、工厂与加载¶
- 集合（collection）是复用与组织单位：关卡、玩法模块、整套 UI 都可以拆成子集合，主集合只是入口。
- 工厂（factory）在运行时生成游戏对象，集合工厂生成整段集合的实例；引擎不给对象池，高频生成物（子弹、特效、飘字）要自己池化（见《技术实现手册》§2.5）。
- 子集合用集合代理（collection proxy）动态加载与卸载，这是关卡切换与流式加载的标准手段；主集合保持瘦。
- 纪律：进游戏一次性全量加载是卡顿与内存的经典来源；按场景拆分、按需加载。
4.4 脚本与 Lua 纪律¶
- Lua 是唯一官方脚本语言；脚本按「一个组件一份」组织，全部回调驱动。
- 全局变量在所有脚本间共享，不写 local 会互相污染，还埋下隐形依赖；默认 local，公共逻辑放模块。
- 热重载覆盖脚本；集合、图集、属性这类结构改动要等一次构建。
- Lua 的临时表与字符串拼接都会落到 GC 账上，热路径按「无分配」写（见 §5）。
4.5 GUI 与输入¶
- UI 走独立的 GUI 系统（gui 资源加脚本），与世界的游戏对象体系分开；界面与场景分开做，别在场景里拼 UI。
- 输入先在输入绑定里声明动作（键盘、触摸、手柄各绑一遍），脚本按动作名响应，不轮询按键。
- 动画：序列帧开箱可用，骨骼动画走 Spine 导入；补间这类表现件不在核心，靠社区库或自研。
5. 性能与优化要点¶
先摸清成本结构：轻量意味着引擎兜底少，优化集中在渲染合批、Lua 内存与平台差异三处。
| 方向 | 要点 |
|---|---|
| 渲染 | 2D 的瓶颈在纹理切换与绘制调用：同图集才可能合批，图集按用途切分；GUI 走独立通道，分开优化；控制半透明叠加与粒子数量，过绘制是移动端发热主因 |
| 脚本与内存 | 减少每帧分配：临时表、字符串拼接、闭包都记在 GC 账上；地址与引用预缓存；高频对象池化 |
| 物理 | 物理只发生在挂了碰撞对象的对象上；碰撞形状用简化几何；不靠物理的玩法就别开物理 |
| 加载与包体 | 只有被引用的资源会进包（见 §2）；非首屏资源用 Live Update 移出首包；HTML5 盯首包大小与运行时内存 |
| 目标平台 | 结论只认真机与目标浏览器：HTML5 的音频、输入、内存差异大；低端安卓机是中低预算的基准 |
方法只有一句：先测量再优化（方法论见《技术实现手册》§3），编辑器内流畅不作数。
6. 学习路线¶
一条直线，每步都以做出东西为验收：
- 官方入门教程：编辑器操作、集合、游戏对象、组件、消息过一遍，跟做官方从零开始的教程项目；中文内容少，直接读英文官方文档，术语对照 API 参考。
- Lua 补课：没有基础先补语言本身（表、闭包、local 与全局的作用域），够读写脚本即可，不必等学全再动手。
- 第一个作品：小体量 2D 成品，覆盖输入、碰撞、GUI、音频与存档；桌面跑通后打 HTML5 与安卓各一份。
- 工具链：分析器、真机调试、命令行构建与依赖管理逐个用起来，把「每天有一份能跑的构建」当最低标准。
- 社区：官方论坛与聊天社区是提问主阵地（英文）；第三方库与扩展在 GitHub 上找，引入前看维护状态。
- 进阶：读引擎源码（路线见《引擎源码阅读路线》）；要接平台 SDK 或做性能手术时再碰原生扩展。
7. 常见坑¶
- 编辑器依赖：集合、组件、属性这些内容基本只能通过编辑器维护，手工改工程文件不现实；外部脚本化改造能做的事有限，团队要接受「内容改动走编辑器」。
- 场景文件冲突硬合并：两人同改一个集合或游戏对象，冲突基本无法手工合并；一文件一人，谁改谁收口。
- 没被引用的资源进不了包：构建只收集从主集合可达的资源，漏挂引用要到运行时才暴露；新资源接入先确认它在引用链上。
- 社区资源少：教程、示例、插件与素材比主流引擎少一个量级；预期摆正，很多能力自研或读源码解决，旧的视频教程注意时效。
- 招人难：会用 Defold 的开发者少，扩编、外包、接班都难找人；团队底子最好是 Lua 熟手。
- 拿它硬做重度 3D：3D 组件齐全但工具链不深，写实项目不要押注；轻量风格化 3D 先做技术切片。
- 消息寻址字符串散落：地址拼错只有运行时才炸；集中成常量，跨模块消息层级超过两层就拆模块。
- 每帧分配拖垮移动端：Lua 的 GC 抖动在低端设备上表现为周期性卡顿；热路径过一遍「无分配」检查。
- 依赖与平台 SDK 无人维护：依赖以 URL 引入、升级靠手动替换加回归；平台 SDK 更新频繁，排期要给维护留位置。
- 编辑器性能当真机结论：编辑器内流畅不等于发布流畅；HTML5 与移动端差异最大，结论只认目标设备。