Ludo Atlas · 引擎轨道 · Cocos¶
引擎轨道。定位：中文生态的跨平台引擎路线，TypeScript 脚本与一体化编辑器工作流，主战场在手游、微信/抖音小游戏与 Web；2D 是强项，3D 在持续补齐。 配套：《技术实现手册》·《小游戏开发手册》·《美术与音频手册》·《全平台上架手册》。
1. 定位与选型¶
Cocos 是国产跨平台引擎，现役主力是 Cocos Creator：一套工程同时导出 Android、iOS、Web、微信/抖音小游戏与各硬件渠道的快游戏。脚本语言以 TypeScript 为主（官方推荐，也兼容 JavaScript），工作流围绕一体化编辑器展开：场景、资源、脚本、构建都在编辑器里完成。编辑器免费使用，引擎运行时开源，遇到引擎层面的问题可以读源码、打补丁。
2D 与 3D 的现状要分开看。2D 是主场：渲染、图集、UI、骨骼动画、瓦片地图都成熟，小游戏适配层的积累也在这条线上。3D 可用并持续补齐，风格化、轻中度与 2D/3D 混合的项目已经跑得动，但工具链深度、教程密度与高端案例跟 Unity 相比有明显差距，重度写实类项目不要押注。更早的 C++ 引擎线（Cocos2d-x）仍有存量项目维护，新项目从 Creator 起步即可。
它最顺手的三块地盘：
| 地盘 | 为什么合适 |
|---|---|
| 微信/抖音小游戏 | 小游戏生态里份额最大：构建面板原生支持各平台导出，分包、远程资源与平台调试链路成熟 |
| 2D 手游与 H5 | 长期积累换来的 2D 生产力：渲染、图集、UI、Spine 与 DragonBones 动画、瓦片地图开箱可用 |
| Web 与营销互动 | 网页基因深，包体小、启动快，活动页、互动展示与轻量游戏是常见落点 |
选型对照（把「要什么」写清楚就够）：
| 场景 | Cocos | Godot | Unity |
|---|---|---|---|
| 微信/抖音小游戏 | 首选：原生导出链路，案例最多 | 支持较弱，社区方案少 | 需官方转换方案，包体与插件兼容逐项评估 |
| 2D 手游与国内渠道 | 首选：中文文档与社区完整 | 可用：轻量、开源 | 生态最厚，工程也更重 |
| 轻度 3D（风格化、策略、卡牌） | 可用：2D/3D 一体，中小体量够用 | 可用：3D 在补课 | 成熟：工具链与素材最多 |
| 重度 3D、写实大世界、主机 | 不推荐 | 不推荐 | 首选（或 Unreal） |
| 开源可定制 | 运行时开源，编辑器闭源 | 全栈开源 | 闭源 |
| 团队是 C# 背景 | 需要转 TypeScript | 可用 C# | 无迁移成本 |
一句话取舍：发布目标里只要有小游戏，先把 Cocos 放进第一轮评估；目标是重度 3D 或主机，直接看别的轨道。
2. 生态与工程结构¶
生态由四块拼成：官方文档（中文优先、更新及时）、官方示例与模板、插件与资源商店（Cocos Store）、社区论坛。预期要摆正：商店规模与素材丰富度比 Unity 生态小一截，很多能力要按「商店先找、社区开源项目再看、实在没有自研」的顺序解决；引入第三方插件前查最近更新与 issue 状态。
标准工程的主干：
| 路径 | 内容 | 约定 |
|---|---|---|
assets/ |
场景、预制体、纹理、音频、脚本 | 内容主体，编辑器按资源库统一管理 |
extensions/ |
编辑器扩展（插件） | 团队自研工具放这里 |
| 本地产物目录 | 资源导入缓存与构建产物 | 不进版本库，官方模板默认忽略 |
工程组织的惯用法：
- 按领域分目录（玩法、系统、界面各成块），脚本与它用的资源就近放，不按文件类型大锅炖。
- 资源 Bundle 按目录划分，粒度由加载频次与依赖关系决定；
resources目录内可动态按路径加载，其余资源尽量用序列化引用。 - 场景与预制体是文本序列化资源，diff 与合并都痛苦；多人协作要拆小预制体，避免同一文件并行改动。
- 资源改名走编辑器（引用自动同步），不要在文件系统里手工重命名或移动，否则引用链断裂。
3. 核心工作流¶
3.1 编辑器工作流¶
日常动线：资源管理器导入素材，层级管理器搭节点树，属性检查器调参数，脚本以 TypeScript 组件的形式挂到节点上，可复用的部分沉淀成预制体。组件通过属性把参数暴露给检查器，策划可以直接调；逻辑与表现分家，界面与玩法各自成模块。
- 编辑器内预览解决「对不对」，真机预览解决「卡不卡、点不点得动」，两者都要跑。
- 改动即预览是效率来源；把热重载友好的写法（小模块、少全局状态）当纪律。
- 发布前真机过一遍：触摸、刘海屏安全区、低端机内存，这三项编辑器都测不出来。
3.2 构建与发布链路（微信/抖音小游戏）¶
从工程到小游戏，链路是标准化的：
- 构建发布面板选择平台（微信小游戏、抖音小游戏、各硬件渠道快游戏等），设置分包与远程资源地址。
- 构建产出平台工程目录（含平台配置文件与开放数据域工程模板），编辑器可唤起对应开发者工具，或手动用工具打开构建产物。
- 在开发者工具里预览与真机调试，落实性能与内存；通过后上传代码。
- 平台侧提审与发布（资质、审核口径见《小游戏开发手册》）。
构建选项里值得先弄懂的几项：
| 选项 | 作用 |
|---|---|
| 主包与分包 | 控制首包体积的主要手段，主包只留启动必需 |
| 远程资源服务器 | 低优先级资源放 CDN，引擎负责下载与缓存版本管理 |
| 引擎原生代码分包、引擎插件 | 引擎自身代码后置或改用平台共享插件，进一步压首包 |
| 开放数据域工程模板 | 关系链类玩法（好友榜、互动）的隔离运行环境，按需生成 |
平台能力不是一个模子，投放前按目标平台核对：
| 能力 | 微信小游戏 | 抖音小游戏 | 硬件渠道快游戏 |
|---|---|---|---|
| 登录 | 平台账号静默登录 | 平台账号登录 | 各渠道账号体系 |
| 关系链 | 开放数据域（好友榜等） | 开放数据域 | 不适用 |
| 传播 | 好友与群分享 | 短视频、直播挂载 | 渠道内推荐位 |
| 变现 | 广告组件与虚拟支付 | 广告组件与虚拟支付 | 广告与渠道支付 |
另有两处环境差异要记住：微信小游戏的运行环境不等同浏览器，不支持 WebView，其余能力以平台开放接口为准；内存是小游戏最硬的约束，低端机上超限直接闪退，真机内存曲线比帧率更需要盯。
4. 关键系统惯用法¶
4.1 节点、组件与预制体¶
- 一切皆节点，能力靠组件拼装；组合优先，别把继承链拉成族谱。
- 预制体是复用单位：界面模块、敌人、子弹都要预制体化，改一处全项目生效。
- 编辑器里能配的尽量在编辑器里配，脚本只写变化逻辑；数值参数集中管理，避免魔法数字散落。
4.2 脚本、事件与生命周期¶
- 组件生命周期回调负责初始化、每帧更新与销毁清理；重逻辑放事件驱动，不要全塞进每帧更新。
- 节点事件处理交互（触摸、点击），全局事件总线处理跨模块通知（成就、音效、界面刷新）；事件层级要限深，超过两层就该拆模块。
- 状态机、对象池、数据表这些架构件自己做：引擎给零件，不给成品框架（架构做法见《技术实现手册》）。
4.3 资源与加载¶
- 动态加载走
resources目录或 Asset Bundle；路径字符串集中成常量表，不散落各处。 - 引擎按引用计数管理资源生命周期：谁持有谁负责；长驻资源与场景级资源分开管，切场景前后看一眼内存是否回落。
- 预加载分级：首屏关键资源优先加载，次要资源分帧拉到后台。
4.4 UI、动画与物理¶
- UI 用 2D 节点树加组件；设计分辨率与适配策略在项目设置里一次定好，多机型按安全区验收。
- 2D 动画两条主力路线：序列帧（便宜、可控）与骨骼动画（省资源、表现力强，Spine、DragonBones 都能导）；补间动画管界面动效。
- 2D 物理内置、开箱可用；3D 物理更重（走 WebAssembly 模块），先问「玩法是否真的需要物理」，再决定开不开。
5. 性能与优化要点¶
小游戏与低端机是性能的基准场景，预算优先级固定：内存第一、渲染第二、包体第三。
| 方向 | 要点 |
|---|---|
| 内存 | 盯真机曲线；纹理尺寸与压缩格式分平台处理；切场景验证回落；对象池兜住峰值 |
| 渲染 | 同图集、同材质才能合批；控制穿插打断；减少透明叠加与满屏粒子；图集按用量切分 |
| 脚本 | 节点引用预先缓存，禁止每帧查找；减少每帧分配与字符串拼接，降低 GC 抖动；事件监听成对移除 |
| 启动 | 首场景瘦身；功能裁剪（项目设置里剔掉用不到的系统模块）；分包与远程资源把首包压进限制之内 |
| 物理 | 按需开启；碰撞分组过滤；简化碰撞形状；必要时降低物理频率换流畅 |
方法论只有一句：先测量再动手，编辑器数据只当参考，结论以真机与目标机型分档实测为准（工具清单见《技术实现手册》）。优化前后各记录一组数据，没有数据支撑的优化一律不做。
6. 学习路线¶
三个阶段，每段有验收物：
| 阶段 | 做什么 | 验收物 |
|---|---|---|
| 入门 | 官方文档与官方示例工程；做 2D 小游戏，覆盖移动、碰撞、UI、存档 | 能独立在编辑器里搭出一个完整可玩的小游戏 |
| 发布 | 走一遍小游戏全链路：分包、真机调试、提审、上线 | 一个真实上线的微信或抖音小游戏 |
| 进阶 | 3D 入门、编辑器扩展、性能方法论；读引擎源码 | 一份性能优化复盘；能写小工具解决团队重复劳动 |
从 Unity 或 Godot 转过来的人：概念几乎一一对应（节点对 GameObject、预制体对 Prefab、组件对 MonoBehaviour），对象池、状态机、事件这些架构能力全额迁移；要新学的是 TypeScript 的类型系统、编辑器工作流的细节，以及小游戏环境的约束集。
资源入口：官方文档与示例工程优先；视频教程注意时效，按旧代 API 讲解的很多。社区与商店入口见《资源大全》。
7. 常见坑¶
- 把大版本换代当普通升级：Creator 的大版本换代是重构级的，编辑器组织与脚本 API 都要改，三方插件的跟进经常滞后；升级前冻结依赖、列回归清单，逐项过官方迁移指引。
- 照抄过时教程：网上大量教程按旧代 API 写成，能编译不代表行为正确；版本冲突时只认官方文档。
- 把插件商店当成熟生态用：规模小、质量参差，关键能力要有自研预案，引入前先看维护状态。
- 在小游戏里找原生能力：小游戏运行在平台的 JS 环境里，带原生代码的 SDK 与插件都用不了；先查目标平台的开放接口清单，再定方案。
- 只在编辑器与模拟器里测：内存闪退是低端机专属问题，上线前必须真机跑目标机型。
- 多人并行改同一个预制体或场景：文本序列化资源的冲突基本解不开；拆预制体、锁目录、错峰改。
- 首包失控：主包限制是硬约束，资源不做分包与远置，上线前必然返工（口径见《小游戏开发手册》）。
- 加载不管释放：引用计数不清零，切场景内存不回落；长驻资源显式标记，临时资源按作用域释放。
- 拿它硬做重度 3D：3D 在补齐，重度写实大世界不是它的战场；3D 项目先做切片验证再押注。
- iOS 支付照老教程绕：虚拟支付通道已打通，历史绕行方案属于违规，不要再采用。