Ludo Atlas · 引擎轨道 · 轻量框架（代码优先路线）¶
引擎轨道。定位：没有编辑器兜底的开发路线，主循环、资产与工具全部自己组织，换来完整的控制权与能读透的技术栈。 配套：《技术实现手册》·《制作管理手册》·《独立开发生存手册》。
1. 定位与选型¶
「代码优先」是一条具体的技术路线：没有场景编辑器或只有极简编辑器，程序员直接面对主循环，输入、更新、绘制的每一帧都由自己组织；资产、关卡与工具链也按代码与数据文件组织。没有「拖进场景就能跑」的兜底，引擎替你做的每一件事，都以「自己来做」的形式回到你手上。
什么时候选它：
- 学原理：想知道引擎黑箱里每一帧发生了什么，亲手实现一遍是最短的路径；与《引擎源码阅读路线》互补，一条读别人的，一条写自己的。
- 小体量成品：机制聚焦的 2D 小游戏，几小时到十几小时的体验，框架的体量优势直接转化为交付速度。
- 原型与实验：启动快、无编辑器负担，适合验证玩法假设与做 Game Jam。
- 工具与非游戏程序：调参面板、地图查看器、图形演示、教学示例，这类「不像游戏」的程序用框架反而轻快。
以下场合不适合这条路线：内容量大的项目、美术与策划需要直接进场的团队、依赖可视化关卡流水线的作品、3D 重场景项目。占了两条以上，先回到《引擎选型指南》重新评估，不要用框架硬撑。
两条路线的取舍对照：
| 维度 | 引擎路线 | 轻量框架路线 |
|---|---|---|
| 编辑器 | 场景与预制体编辑器 | 无或极简，代码即工程 |
| 系统供给 | 内置于引擎 | 自己组装，按需引入库 |
| 迭代方式 | 编辑器内试玩 | 运行即试玩，热重载需自建 |
| 学习内容 | 学引擎的用法 | 学原理，加学语言 |
| 定制上限 | 受引擎扩展模型限制 | 没有上限，工程量就是成本 |
| 协作方式 | 策划美术可直接编辑内容 | 内容进数据文件，工具要自己写 |
| 成本结构 | 前期快，后期与引擎博弈 | 前期慢，后期完全自主 |
五个框架的一句话定位：
| 框架 | 语言 | 一句话定位 | 常见选择场景 |
|---|---|---|---|
| raylib | C（多语言绑定） | C 系轻快路线：极简 API、核心无外部依赖，上手极快 | 想边用边读源码的学习者、C 系小项目与工具 |
| LÖVE | Lua | Lua 2D 框架：目录即工程，反馈循环短 | 偏爱脚本语言的快速迭代、2D 小体量与 Game Jam |
| Pygame | Python | Python 2D 入门经典：教程与示例生态庞大 | Python 学习者、教学演示、逻辑不重的 2D |
| SDL | C | 底层多媒体抽象：窗口、输入、音频、渲染的最小集合 | 要拿全部控制权、愿意从底层搭起 |
| SFML | C++ | C++ 面向对象中层库：模块清晰，以 2D 为主 | 想用 C++ 但不想直接碰系统 API |
选型只看三个变量：你愿意长期写哪种语言，这比性能差异更关键；你享受把系统建起来的程度，SDL、SFML 最底层，raylib、LÖVE、Pygame 出结果更快；目标体量，一旦超出小体量区间，任何框架都会变成负重跑。三个变量里，让语言和体量说话。
自检问题：把编辑器拿掉之后，项目里还有谁的工作流会断？断得越多，这条路线与你的适配度越低。
2. 生态与工程结构¶
框架不是缩小的引擎，工程形态与引擎项目差别很大：没有编辑器生成的项目骨架，结构由你定义，构建方式随语言而定。
| 框架 | 工程形态 | 构建与依赖 |
|---|---|---|
| raylib | 作为库链接进项目，代码结构自由 | 构建系统自选；核心无外部依赖 |
| LÖVE | 约定优于配置：入口文件加配置文件，目录即工程 | 目录直接交给运行时；模块放进项目目录 |
| Pygame | Python 包加虚拟环境 | 依赖清单管理；入口脚本即程序 |
| SDL | 系统级库，头文件加链接库 | 构建系统管理；按平台处理链接方式 |
| SFML | 同 SDL，模块化链接 | 同 SDL；静态或动态链接二选一 |
没有编辑器，目录结构就是工程结构。起步就固定约定并写进项目文档：
src/：全部游戏代码，按系统分文件（主循环、输入、渲染、世界、界面），避免单文件膨胀。assets/：美术与音频，区分源文件与运行时格式，命名规范从第一天执行。tools/：自建编辑器与转换脚本（§3.2），工具产物也要进版本管理。scripts/：构建、打包、发布脚本，让「一键跑起来」成为协作底线。
依赖管理的语言差异要提前想清楚：C 与 C++ 要么一切自带，要么选定构建系统与依赖管理方式后就别再折腾；Lua 的模块直接放进项目目录最省事；Python 必须有虚拟环境与依赖清单，否则环境不可复现是迟早的事。
生态规模的经验判断：SDL 位于最底层，往上几乎每一层都有现成方案；raylib 官方示例与模板社区丰富，读源码的路线成熟；LÖVE 的模块生态靠社区自发组织，质量参差要自己筛；Pygame 教程最多，但主项目迭代偏慢，社区派生版更活跃（入口见《资源大全》）。
一条纪律：框架路线没有编辑器替你记录工程知识，任何约定（命名、目录、构建命令、资源格式）不写进文档就等于不存在。
3. 核心工作流¶
3.1 主循环自管¶
这类框架的共同点：它们把「一帧」交给你。典型结构是一行职责链：
收集事件与输入 → 更新逻辑（固定或可变步长） → 绘制 → 帧率控制与下一帧等待
这段话在引擎里是隐藏的，在这里它就是你的日常，两条纪律：
- 逻辑更新用固定步长，渲染从固定步长解耦，否则手感与物理会随机器性能漂移（理由见《技术实现手册》§2.9）。
- 从第一天就做三件调试设施：帧计时显示、状态叠加面板、关键参数的运行时输出。调参不能靠改代码重启。
迭代循环是这条路线最大的资产：改代码、运行、观察、再改。把这个循环压缩到秒级，效率超过大多数引擎项目；启动与运行时间要当作第一优先级的工程指标来压。
3.2 自建工具：隐藏工作量的大头¶
引擎项目里免费的编辑器，在框架路线里都是待建项目。估算工作量时把它们单独列出来：
| 工具 | 不做的后果 | 常见做法 |
|---|---|---|
| 关卡编辑器 | 关卡全写在代码里，改一堵墙也要改代码 | 运行时调试模式直接摆物体并导出数据；或做独立小工具读写同一格式 |
| 调参面板 | 每个数值都靠改代码重启 | 运行时叠加面板，读写在配置文件 |
| 数据表与转换脚本 | 数值散落在代码各处 | 表格或文本格式加转换脚本，构建时生成 |
| 资产打包工具 | 手工整理目录，包体失控 | 脚本化图集打包、音频转换与命名检查 |
经验法则：工具的成本用小时计，手工维护内容的成本用小时乘迭代次数计。关卡编辑与调参面板越早做越省；关卡数超过十张、数值超过几十个之后，没有工具的内容迭代会直接拖垮进度。
3.3 资产管线¶
没有资源导入器，代码就是导入器。管线通常是：DCC 导出（约定格式与尺寸）→ 命名与目录规范 → 转换脚本（图集、压缩、音频格式）→ 游戏内加载代码。两条纪律：源文件与运行时文件分开目录存放；任何手工步骤都要脚本化，否则「换台机器就出不来」会反复发生。
3.4 打包与分发¶
分发是这条路线最容易被低估的一段，各语言难点不同：
| 路线 | 主要难点 | 应对 |
|---|---|---|
| C 与 C++（raylib、SDL、SFML） | 每个平台各自构建；动态库带来运行时依赖 | 用构建矩阵产出各平台版本；优先静态链接减少依赖 |
| Lua（LÖVE） | 玩家机器需要运行时，除非把工程与运行时融合 | 融合打包为单一可执行文件；各平台分别产出 |
| Python（Pygame） | 打包产物体积偏大；可能遇到杀软误报 | 打包工具生成可执行；正式发布处理签名与误报申诉 |
| 通用 | 商店要求、更新机制、崩溃收集都要自己接 | 从发布倒排日程，给它留出与引擎项目同量级的预算 |
4. 关键系统惯用法¶
框架不替你定义架构，但引擎里的「标配系统」在这里都有对应物，只是全部由你实现：
| 引擎里的概念 | 框架路线的对应做法 |
|---|---|
| 场景与场景切换 | 自己写状态栈：进入、退出、暂停各自清理资源 |
| 预制体与实体 | 数据表加构造函数，实体字段由数据文件驱动 |
| 可视化编辑器 | 运行时调试模式加自建小工具（§3.2） |
| 资源导入器 | 约定目录加加载器代码，加载入口保持唯一 |
| 事件与信号 | 回调注册表或消息队列，限制传递层级防止链式混乱 |
| 存档系统 | 自定格式加版本号与迁移函数，只存状态不存对象引用 |
| 相机 | 自己实现跟随、死区、前瞻与震屏（要点见《技术实现手册》§2.3） |
| 对象池 | 高频生成销毁的对象一律池化，语言越托管越要早做 |
几条惯用法：把游戏状态集中在一个顶层对象里，按系统拆文件，禁止散落全局变量；输入走动作映射层，区分按下、按住、松开三种状态并做输入缓冲；资源加载只留一个入口，为热重载留余地；界面没有内置方案，游戏内界面与调试界面分开搭，或引入成熟的第三方界面库；音频直接调用框架接口，但通道管理、并发上限与流式播放要自己安排。
每个系统写完，留一个开关：运行时能单独显示它的可视化状态。它既是调试工具，也是将来编辑器界面与自建工具的地基。
5. 性能与优化要点¶
性能边界由语言决定，先看清自己的跑道：
| 路线 | 性能量级 | 体量直觉 |
|---|---|---|
| C 与 C++（raylib、SDL、SFML） | 原生速度，余地最大 | 数千同屏对象与复杂 2D 不吃力 |
| Lua（LÖVE） | 脚本层较慢，热点可下沉到原生 | 常规 2D，数百活跃对象舒适 |
| Python（Pygame） | 明显慢一档，逐对象更新要克制 | 小体量 2D、工具与教学演示，实体数量要小 |
量级只用于判断「这条路线撑不撑得起我的想法」，具体数字在你的游戏与目标机器上测出来才算数。
常见优化点：
- 绘制：减少绘制调用与纹理切换，用图集与批处理；文字渲染开销不小，缓存渲染结果，不要每帧重新排版。
- 更新：托管语言避免每帧分配；高频对象池化并预热；把逐实体循环里的查找提前到加载期。
- 结构：逻辑与渲染解耦；逻辑积压时限制单帧追赶次数，避免越卡越堆。
- 下沉：热点确认后，再考虑原生代码、第三方库或并行化替代；先测，再换。
测量纪律照《技术实现手册》§3：没有测量不做优化；先确认热点在哪一层（渲染、更新或资源加载）；以真机数据为准，优化前后都留记录。
6. 学习路线¶
按顺序走，每个阶段都有可观察的产出：
- 语言关（数周）：先把目标语言写顺，文件读写、数据结构、错误处理、调试器。框架救不了语言不熟的人。
- 跑通全部官方示例（几天）：框架都自带示例集合，按清单跑一遍，每个示例改一两个参数看反应，建立「什么归框架管、什么归你管」的边界感。
- 复刻小游戏三件套（数周）：Pong、打砖块、一个带滚屏的平台跳跃。每个比上一个多一项系统：输入缓冲、碰撞与状态机、相机与关卡数据文件。
- 手写一套最小系统（数周）：主循环固定步长、状态栈、存档、运行时调参面板，全部自己实现一遍。这一步过后，读任何引擎的架构图都不再神秘。
- 完成并发布一个小作品（一至三个月）：含自建工具、打包脚本与一次真实分发。发布流程的坑只有走完一次才会消失。
验收标准（全部可观察）：
- 不看教程，能从空项目搭到「有画面、有输入、有状态切换」。
- 能说清每一帧里代码的执行顺序，卡顿时能定位瓶颈在哪一层。
- 复刻阶段的作品有至少一个自己加的机制，并能解释它的实现选择。
- 打包产物在别人的干净机器上能运行，安装与启动不需要你现场指导。
7. 常见坑¶
- 范围失控：选了框架做「大一点的作品」，内容量一涨，编辑器与工具的缺口全部暴露；框架路线适合小体量，体量上去要正视换路线。
- 工具欠账：到量产期才想起要关卡编辑器与调参面板，内容迭代被拖垮（§3.2）。
- 重复造轮子：界面、音频、物理都从零手搓，进度耗在与玩法无关的工程上；另一个极端是什么都外包，核心循环都没搞明白。
- 手工资源管理失控：只加载不释放、释放了还在用、资源路径散落成魔法字符串；用统一加载入口加引用管理解决。
- 低估分发：打包、签名、商店材料、更新机制全是实打实的工程量，发布前两周才动手注定延期。
- 性能误判：用错语言做错体量（Python 硬撑实体海）；或相反，给一个小项目提前上复杂优化。
- 迭代速度没兑现：没有热重载与运行时调参，还是改代码重启调数值，这条路线的最大优势白白浪费。
- 环境不可复现：C++ 的构建矩阵、Python 的依赖差异，导致「我机器上能跑」；把环境与构建写进脚本，能容器化就容器化。
- 适配后置：手柄、分辨率、系统字体、存档路径等，到测试末期才处理，返工面积很大。
- 只抄不懂：教程与示例代码里的每个数字都要能解释；框架路线的好处正是每一行都能搞懂，别把它用成黑箱。