Ludo Atlas · 引擎轨道 · GameMaker¶
引擎轨道。定位：为 2D 而生的快速开发引擎，GML 脚本加可视化积木把上手门槛压到最低，像素与 2D 小体量的原型到上线路径极短。 配套：《技术实现手册》·《游戏设计手册》·《全平台上架手册》·《独立开发生存手册》。
1. 定位与选型¶
GameMaker 是一款把 2D 写进基因的商业引擎：房间、对象、事件三件套全部围绕 2D 游戏组织，脚本语言 GML 语法简单、手册完整；完全不想写代码时，用可视化积木也能搭出可玩的完整作品，之后再随时迁移到代码。《Undertale》《迈阿密热线》这类知名独立作品都出自这条轨道。
许可模型决定使用边界：免费版可用于学习与非商业用途，功能与发布范围受限；商业发布需要购买授权，档位与覆盖的平台（含主机）以官方为准。引擎闭源、由单一公司主导，产品路线与许可政策不受社区投票左右。
适合谁¶
- 做 2D 与像素风格小体量项目的人：从原型到成品是最快一档，独立开发者与小型团队的常青选择。
- 没有编程经验的入门者：积木到 GML 的渐进路径平缓，教程生态以视频为主、密度高。
- 需要快速验证玩法的 Game Jam 与原型：编辑器反馈快，搭出可玩画面以小时计。
- 偏系统与玩法的设计者：内置精灵编辑器、房间编辑器与瓦片地图，把「做出一关」的成本压得很低。
不适合谁¶
- 3D 项目：3D 能力存在，但不是它的战场，重度 3D 不要从这条轨道出发。
- 依赖开源与源码可改的团队：引擎闭源，遇到引擎层面的问题只能等官方或绕行。
- 重度依赖商业插件与中间件的项目：生态规模比 Unity 小一档，关键能力先核对再选型。
- 不接受授权支出的项目：商业发布要买授权，这笔账应该在选型第一步就摆上桌面。
与 Godot、Unity 的取舍¶
| 维度 | GameMaker | Godot | Unity |
|---|---|---|---|
| 定位 | 2D 专注 | 2D/3D 全能 | 商业全能 |
| 语言 | GML，可配可视化积木 | GDScript / C# | C# |
| 许可 | 免费版受限，商业发布需授权 | 无附加条件 | 个人免费档存在，条款以官方为准 |
| 上手速度 | 最快一档 | 快 | 中 |
| 2D 工作流 | 精灵、房间、瓦片地图开箱可用，像素友好 | 2D 是一等公民 | 工具链成熟，工程偏重 |
| 3D | 不适合作为主线 | 中等体量可用 | 强 |
| 导出平台 | 桌面、移动、Web、主机（在授权档位内） | 桌面、移动、Web，主机需第三方移植 | 全平台，条款以官方为准 |
| 生态 | 小而集中，视频教程为主 | 中等，官方文档优秀 | 最大 |
| 源码 | 闭源 | 开源 | 闭源 |
一句话取舍：做 2D 小体量、想最快见到可玩画面，把 GameMaker 放进第一轮评估；计划长成 3D 或重度工程，回到 Godot 与 Unity 的轨道上比较。
2. 生态与工程结构¶
GameMaker 的工程更像一个资源库：一个项目文件之外，精灵、对象、房间、脚本、声音、字体、着色器各按类型归目录，由 IDE 统一管理引用。资源的重命名与移动要在 IDE 里做，在文件系统层面手工改名会直接断掉引用链。
2.1 目录与资源分类¶
| 资源类型 | 内容 | 使用要点 |
|---|---|---|
| 精灵 | 图片与动画帧 | 自带编辑器，导入即裁帧；帧序与原点设置直接影响手感 |
| 对象 | 逻辑单元 | 游戏里一切活动事物都从这里出生 |
| 房间 | 运行容器与关卡 | 游戏入口是一个房间；标题、菜单、关卡都是房间 |
| 脚本 | 复用逻辑 | 逻辑离开对象事件之后的去处，按系统分文件 |
| 声音、字体、着色器 | 表现层资源 | 按需引入，注意平台间的格式差异 |
工程文件本身是文本格式，比纯二进制工程对 Git 友好；但同一个资源的并行修改仍会冲突，协作要靠拆小资源与错峰修改（版本控制方法见《技术实现手册》§6）。
2.2 生态的边界¶
- 官方手册质量高、覆盖全，是唯一权威；教程生态以视频与社区项目为主，版本跨度大，筛选成本要预留。
- 扩展包与素材商店提供平台扩展和美术资源，规模比 Unity 商店小一档；购买前看维护状态与授权条款，商用范围逐条核对。
- 引擎闭源、单公司运营，平台支持与授权政策的走向由厂商决定；这是选型时无法靠自己对冲的风险，重要需求要留备选方案。
2.3 自检问题¶
把 3D、重度工程、必须读源码改引擎这三条中占了两条以上，先回到《引擎选型指南》重新评估；接不下 2D 小体量的快速节奏，这条轨道就选错了。
3. 核心工作流¶
3.1 从零到能跑¶
- 装 IDE、新建工程：从空白模板起步，示例工程留作参考。
- 导入素材：把图片拖进 IDE，用自带编辑器裁帧、设原点。
- 建对象、写事件：行为逻辑写进事件；先用可视化积木跑通，再逐步换成 GML。
- 建房间、摆实例：把对象摆进房间，房间就是可运行的最小单位。
- 运行与调试：IDE 内直接运行；调试器的断点、逐帧执行、变量监视先用熟。
- 接版本控制：工程与资源入库，缓存与构建产物进忽略清单。
- 配目标平台出包：桌面先出包，移动与 Web 逐个验证，主机在授权档位内申请。
3.2 事件模型：写代码的地方¶
- 对象的一切行为都挂到事件上：创建、销毁、步进（开始、常规、结束）、绘制（游戏世界、界面层）、警报、碰撞、异步回调。
- 事件类型与执行顺序是引擎的骨架：同一对象里步进先于绘制，不同对象按实例处理顺序执行。出 bug 时先确认顺序假设，再怀疑逻辑。
- 逻辑放对事件：初始化进创建事件，状态更新进步进事件，表现只进绘制事件；把玩法规则塞进绘制事件是最常见的结构事故。
- 异步事件承接平台回调（存档、网络、内购等），回调有明确的完成时机，不要假设它立即返回。
3.3 导出与多平台¶
| 目标 | 路径 | 注意点 |
|---|---|---|
| 桌面 | 直接构建可执行文件 | 最顺的路线；分发与商店接入按《全平台上架手册》执行 |
| 移动 | 需配置平台工具链 | iOS 构建依赖 macOS 环境，非 Mac 团队提前安排 |
| Web | 导出网页构建 | 浏览器环境限制多，内存与音频策略要实机验证 |
| 主机 | 授权档位内提供 | 开发机申请与认证流程走厂商渠道，排期提前算 |
构建支持脚本化调用，能接进自动化流水线做每日构建，基建清单见《技术实现手册》§6。
4. 关键系统惯用法¶
4.1 三件套的心智模型¶
- 房间是舞台，对象是演员，事件是台词：房间负责「在哪」，对象负责「是谁」，事件负责「何时做什么」。
- 一个对象只装一类职责的实例逻辑：子弹对象只管飞行与命中，拾取逻辑属于拾取物对象。
- 对象继承用来表达真正的同类关系（敌人类共享基础行为），不要拿继承凑复用；功能复用优先组合与脚本函数。
- 实例是对象在房间里的具体存在：同一对象可以摆多个实例，各自持有独立变量，别把实例状态改写成全局状态。
4.2 代码组织的纪律¶
- 事件窗口保持薄：每个事件里只留调用，逻辑沉到脚本资源里、按系统分文件。
- 变量作用域分三层：局部、实例、全局。能用局部就不用实例，能用实例就不用全局。
- 命名带资源前缀（对象、精灵、房间、脚本各一套），搜索与筛选才有效。
- 魔法数字集中管理：数值放数据文件或常量脚本，禁止散落在事件窗口里。
4.3 绘制与相机：把 2D 做对¶
- 像素风先对齐三件事：关闭纹理插值、整数缩放、相机跟随取整，否则画面会糊、会抖。
- 相机（视图）在房间里配置或在运行期控制，跟随与死区逻辑要和角色手感一起调（方法见《技术实现手册》§2.3）。
- 绘制事件分世界层与界面层：界面不随相机移动，血条、分数、菜单画在界面层。
- 动画路线按资源条件选：序列帧便宜可控，骨骼动画省资源；上大图或骨骼前先问「是否真的需要」。
4.4 数据、存档与配置¶
- 数据驱动从第一天做起：数值、关卡配置、文本内容放文本数据文件，改内容不动代码。
- 存档只存状态、不存表现：字段带版本号与迁移函数，后期改结构才不返工。
- 内置快速存档接口适合原型与小型项目；正式项目用自管格式换取可控性与跨平台一致性。
4.5 扩展与依赖¶
- 平台扩展与第三方扩展按需引入；引入前看维护状态与授权，升级引擎时逐项回归。
- 不依赖不可替换的单一扩展：支付、广告、统计这类关键能力至少留一条备选路径。
- 引擎闭源意味着「等官方修」可能等很久，绕行方案要提前想好。
5. 性能与优化要点¶
总则不变：先测量再优化，开发机的流畅不算数，以目标设备为准（方法论见《技术实现手册》§3）。GML 在自己的虚拟机上执行，性能习惯比语言选择更决定上限。
5.1 四个高频问题¶
| 习惯 | 病态写法 | 正确做法 |
|---|---|---|
| 实例管理 | 每帧创建与销毁子弹、特效 | 对象池加激活与停用，复用实例 |
| 每帧开销 | 步进事件里查对象、拼字符串 | 引用提前存好，字符串提前拼好 |
| 事件重量 | 所有对象都挂最重的步进事件 | 不需要每帧的改走警报或条件触发 |
| 绘制调用 | 素材零散导致频繁切换纹理 | 按纹理组合并素材，控制图层顺序 |
5.2 渲染与资源¶
- 纹理页由引擎按纹理组自动打包；分组策略要主动管理，单张图被打进错误的组，批次会白白增多。
- 大量同质视觉元素（粒子、雨雪、星光）优先用粒子系统，不要用成百上千个对象实例去堆。
- 大图与高分辨率素材是内存与带宽的大头，按目标平台分级准备。
5.3 平台差异¶
- 移动端盯内存与发热，低端机是下限基准。
- Web 端的内存与音频策略要在项目早期验证，不要等上线前补课。
- 测试纪律不变：目标设备实测，优化前后各留一组数据。
6. 学习路线¶
一条以「做出东西」为验收的直线：
- 官方入门：手册的入门章节与官方教程走一遍，目标是做出一个能动、能碰、能换房间的小东西。
- 语言关：把 GML 的核心内容（变量、函数、数组、结构体、方法与作用域）过完，边写边查手册。
- 第一个完整作品：小而完整、能玩到结局，覆盖移动、碰撞、界面、存档与音频。
- 工具链：调试器、版本控制、构建脚本逐个用起来；发布构建的原生编译档位实测一次。
- 进阶方向：着色器、序列动画、物理与粒子，按项目需要选学，不贪多。
- 发布：完整走一次目标平台的上架流程，把授权与资质环节提前踩平。
验收标准（全部可观察）：
- 不看教程，能从空工程搭到「有关卡、有失败条件、能重开」。
- 出 bug 时能先定位到「哪个对象、哪个事件、第几帧」，再说怎么修。
- 完成的作品在别人的干净机器上能安装、能运行。
7. 常见坑¶
- 代码堆在事件窗口：创建、步进、绘制事件里各写几百行，复用靠复制粘贴；逻辑必须沉到脚本里，事件只做调用。
- 全局变量当背包：所有状态进全局，依赖与加载顺序全部隐形；作用域从局部开始逐级放宽。
- 版本控制缺位或缓存入库：资源元数据冲突难解，仓库里一半是可再生成的缓存；忽略清单第一天上好。
- 命名随手起：没有前缀、大小写混乱，资源过千之后搜索基本失效。
- 照旧教程硬搬：引擎更名与授权模式换过代，老教程的资源与做法经常对不上；以官方手册为准，导入旧工程逐项验证兼容性。
- 忽视授权边界：拿免费版做商业发布，或混用授权不覆盖的平台；发布前核对档位与目标平台（含主机）。
- 性能习惯不设防：每帧创建销毁实例、每帧拼字符串、不管理纹理分组，到移动端集中爆发；按 §5.1 的清单从原型期自检。
- 拿它硬做 3D 或大工程：超出 2D 小体量的定位，付出的是持续的工程硬撑；先回到《引擎选型指南》。
- 依赖单一生态不自知：引擎闭源、单公司主导，扩展与平台支持的存续不在你手里；关键能力留备选方案。
- 素材授权不核对：商店素材与音效的商用范围逐条对照，别到上线才发现不能用于商业项目。