Ludo Atlas · 引擎轨道 · Bevy（Rust）¶
引擎轨道。定位：用 Rust 写的数据驱动 ECS 引擎，学现代架构的最佳样本之一，生产可用性正在成长中。 配套：《技术实现手册》（架构选型与性能方法论）·《制作管理手册》（范围与排期）·《独立开发生存手册》（长期技术投资）·《AI 工作流手册》（生成代码的评审边界）。 原则：本文不贴代码、不写版本号；接口与配置细节变化快，以官方文档、迁移说明与你的 Profiler 为准。
1. 定位与选型¶
一句话定位：Bevy 是基于 ECS（Entity-Component-System）的开源 Rust 游戏引擎，以数据驱动为第一原则，Rust 的类型系统与所有权模型是它的地基。
选它的三个理由：
- 学习价值：ECS、数据局部性、调度器并行、插件化架构，这些现代引擎的通用课题在 Bevy 里是主路径而不是选修课。吃透一轮，再回头看别的引擎，架构问题会变得透明。
- 工具向交付：Rust 的可靠性（无 GC、内存与并发安全）适合模拟、可视化、编辑器工具、长期运行的仿真与服务程序。
- 长期技术投资：语言与引擎共享一套资本（类型系统、包管理、测试），学会的 Rust 在引擎之外照样兑现。
代价同样明确：
| 维度 | 现状 | 对你的含义 |
|---|---|---|
| 工程成熟度 | 快速迭代期，接口仍在演进 | 每轮升级都可能带迁移工作，预算里先留一份 |
| 工具链体验 | 没有成熟的一体化官方编辑器 | 场景搭建与调参主要靠代码与第三方工具 |
| 生态厚度 | 核心官方维护，其余靠社区 | 冷门需求要自己做或等，评估周期不能省 |
| 平台支持 | 桌面较顺，移动与 Web 成熟度有差距 | 上特定平台前先做小实验，不要发布前才发现 |
适合：想学现代引擎架构的人；小体量、规则清晰、模拟向或工具向项目；愿意把「跟版本」当日常功课的团队。不适合：赶硬档期的大团队；重度依赖可视化编辑与商业中间件的项目；对主机认证有时间红线且没有试错预算的项目。
自检：你的项目最重的部分是「实体很多、规则很密」还是「内容很多、美术很重」？前者是舒适区，后者要看生态能不能接住。硬门槛一条：团队里要有人读得懂编译器报错，并且在英文资料里搜得到答案。
2. 生态与工程结构¶
2.1 工具链：cargo 就是工作台¶
Bevy 是 Rust 生态里的一个库（crate），工作台就是 Rust 工具链本身，编辑器一侧靠 rust-analyzer 提供补全与错误提示：
| 工具 | 负责什么 | 用在开发循环的哪里 |
|---|---|---|
| cargo | 建工程、拉依赖、构建、测试、运行 | 所有操作的入口 |
| cargo check | 只做类型检查，不产出可执行文件 | 写代码途中的快循环 |
| cargo clippy、cargo fmt | 静态检查与格式化 | 提交前跑，严格度进 CI |
工程结构建议（单 crate 起步，体量上来再拆 workspace）：
game/
├── Cargo.toml / Cargo.lock # 依赖配置；锁文件提交进仓库
├── assets/ # 运行时资产：贴图、音频、场景数据
└── src/ # main.rs 入口，其余按领域拆成插件
一条容易被忽视的配置纪律：开发构建里给依赖开优化、给自身代码保留调试信息。否则 ECS 代码在 debug 构建下会慢到误导判断，让你在错误的性能直觉上做设计。
2.2 插件（Plugin）体系¶
插件是这个引擎的组织单位：
- 一个功能一个插件。渲染、输入、音频、窗口等由官方插件提供，默认插件组把它们装配成开箱可用的应用；你写给游戏、存档、UI 的插件与它们并列。
- 插件是登记点：系统、资源、事件、状态、资产加载器都挂在插件构建阶段。工程组织因此变成「哪些插件、谁依赖谁」的问题，与《技术实现手册》§1 的模块边界心法同源。
2.3 crate 生态地图¶
| 需求 | 代表方案 | 备注 |
|---|---|---|
| 物理 | Rapier 系集成、Avian 系 | 2D 与 3D 分家，接入前先验证 |
| 即时模式 UI 与调试 | egui 系集成、检视器类 crate | 开发期调参利器，生产 UI 另议 |
| 网络 | 若干社区联机 crate | 成熟度参差，先做最小延迟实验 |
| 瓦片地图与关卡数据 | 社区 crate 加自研解析 | 与你的编辑器产物格式对齐 |
生态的真实形状：核心（渲染、输入、资产、UI、音频）由官方维护、质量稳定；长尾需求（特定平台 SDK、商业中间件、可视化编辑器）靠社区或自研。挑 crate 看三件事：是否跟上最新版引擎、Issue 响应速度、许可证；选型时把「长尾能力谁来接」写成一句话，写不出来就别承诺。
2.4 版本跟进节奏¶
升级前先看变更说明（迁移指南），再动依赖清单；升级是一笔独立、可回滚的提交；锁文件进仓库，保证每台机器、每次 CI 构建出同一套依赖：
- 第三方 crate 与引擎版本强耦合：升级前确认关键 crate 是否跟进；没跟进就等，或者接受自维护成本。
- 升级流程建议：单独分支 → 升依赖 → 逐个修编译错误 → 跑测试与冒烟 → 观察运行期行为差异（渲染与调度变化不一定编译报错）。
3. 核心工作流¶
3.1 一个功能的诞生¶
定义数据 → 写系统 → 注册插件 → 运行观察 → 调参与回归
- 定义数据：这个功能需要哪些组件？把「是什么」写成数据。
- 写系统：哪些逻辑读哪些组件、写哪些组件？把「怎么变」写成函数。
- 注册插件：系统、资源、事件在插件里登记，先后顺序交给调度器表达。
- 运行与调参：跑起来看诊断数字与画面，别猜；参数集中管理，改完跑测试与冒烟清单。
3.2 开发循环中的命令¶
| 命令 | 场景 | 说明 |
|---|---|---|
| cargo check | 写代码途中 | 快速反馈，代替完整编译 |
| cargo run | 验证行为 | 跑在优化过的开发配置上 |
| cargo test | 逻辑回归 | 逻辑可以跑无头（headless）测试 |
3.3 从原型到发布¶
- 原型期：单 crate、默认插件组、资产直接进
assets/，先验证核心循环。 - 成长期：按领域拆插件与模块；共享类型抽独立 crate；workspace 管理多 crate。
- 发布期：release 构建、平台打包、CI 每日构建（fmt、clippy、test 三件套加产物），流程见《技术实现手册》§6 与发布相关手册。
- 存档与设置：序列化格式第一天就定（文本还是二进制），版本迁移函数从第一版就写。
- 测试与调试：用无窗口应用当夹具跑逻辑回归；诊断面板与检视器看运行时状态；日志加崩溃上报从原型期就接。
4. 关键系统惯用法¶
4.1 ECS 心智模型¶
| 概念 | 一句话 | 要记住什么 |
|---|---|---|
| Entity | 一个 ID | 轻量可复制，本身不带数据 |
| Component | 挂在实体上的数据 | 越小越好，组合产生行为 |
| System | 处理数据的函数 | 普通函数，参数声明要读写什么 |
| Resource | 全局单例数据 | 设置、句柄、全局管理器放这里 |
| Query | 遍历实体的方式 | 用过滤条件缩小集合 |
| Schedule | 系统执行顺序 | 阶段与依赖关系决定先后和并行 |
调度心智三条：
- 系统间并行的前提是不冲突：都只读就并行，写与读、写与写要排队。性能设计的一半在这里。
- 顺序与条件都不靠玄学：输入收集 → 逻辑更新 → 表现刷新摆成阶段，用显式依赖表达先后；「什么时候跑」用运行条件表达，好过在系统里写 if。
4.2 数据驱动三条纪律¶
- 组件是名词、不含逻辑；行为全部在系统里。
- 组合代替继承：要「会燃烧的」加一个组件，别造继承树。
- 状态用状态机（官方状态设施或自有枚举），别用散落的布尔标志拼。
4.3 系统按频率分层¶
| 层 | 频率 | 典型内容 |
|---|---|---|
| 输入层 | 每帧 | 收集输入、翻译成意图 |
| 逻辑层 | 固定步长 | 物理、战斗结算、模拟；定时才好复现 |
| 表现层 | 每帧 | 动画驱动、UI 刷新、音频触发 |
| 低频层 | 定时器 | 自动存档、统计、寻路重算 |
固定步长跑逻辑、可变帧率做表现，是复现性的地基：测试、回放、未来的联机都吃这一条。
4.4 事件、资产与数据流¶
- 事件用来广播「发生了一件事」：伤害结算完成后，音效、特效、日志各自响应，互不直接调用；限制转发层级，事件只描述事实、不携带行为。
- 资产按场景与用途分域命名，不按扩展名分；热重载是强项（改贴图即时可见），代码热重载需要额外方案，别默认它存在。
- 加载流程状态机化：进入场景 = 触发加载 → 进度提示 → 完成切换；不要在首帧同步加载所有内容。
5. 性能与优化要点¶
5.1 性能优势的适用面¶
ECS 红利来自数据局部性与并行调度，红利大小取决于场景形状：
| 场景形状 | 红利 | 原因 |
|---|---|---|
| 实体多、每帧全量遍历（弹幕、粒子、模拟） | 大 | 同类数据连续存放，缓存命中率高，系统可并行 |
| 实体少、逻辑复杂（棋类、叙事工具） | 小 | 规模不够，调度与布局收益看不见 |
| 大量异质实体、组件频繁增删 | 中 | 组件布局迁移有成本，设计要对齐访问模式 |
| 工具与仿真程序 | 中大 | 长时间稳定运行与数据吞吐是强项 |
结论：为规模而来，收益诚实；规模不在你这边，就用架构价值与语言能力做决策依据，不要用性能。
5.2 优化检查单¶
- 开发构建配置：依赖开优化，否则数据全是噪音
- 数据与查询：加过滤缩小集合；变更检测只处理变化过的实体；热数据放热组件，避免每帧增删组件
- 绘制：图集化、批合并、减少状态切换（与《技术实现手册》§3.3 通用清单一致）
- 并行度：看诊断数据，定位系统之间的写冲突与阻塞
- 内存与加载：大资产异步与流式；子弹、特效走复用
- 测量优先：帧预算表加 Profiler 记录，改前改后留档
5.3 平台现实¶
桌面是叙事最完整的战场，优先保障；移动与 Web 有通行路径，但成熟度与桌面有差距，早做小实验、把结论写进选型文档；支持状态以官方说明为准，旧博客与三手教程在这里极不可靠。
6. 学习路线¶
6.1 先修：Rust 本身¶
三处陡坡：所有权与借用、生命周期标注、泛型与 trait 体系。
- 所有权规则会逼你改设计：数据归 ECS 管，系统短期借用。这与 ECS 分工天然同构，熬过前两周就顺。
- 泛型与 trait 是引擎的地基、不是日常游戏逻辑的必需品：先读得懂，不必先写得溜；序列化、错误处理、迭代器这些常用件先过一遍，再动引擎。
- 时间直觉：有其他语言经验的人，两到四周能写日常游戏逻辑；编译器在你第一次尝试「对象互相引用」时会给你最多教育。
6.2 四周上车计划¶
| 周 | 内容 | 产出 |
|---|---|---|
| 1 | Rust 基础加官方示例逐个跑 | 能改示例、看懂报错 |
| 2 | 通读官方手册加小玩具 | 移动方块加状态显示 |
| 3 | ECS 重构练习 | 玩具按插件拆成输入、逻辑、UI 三块 |
| 4 | 微项目垂直切片 | 一个完整循环：操作 → 规则 → 胜负 → 重开 |
6.3 进阶¶
- 用无渲染测试为逻辑写回归用例；读引擎源码时对照《引擎源码阅读路线》的 Bevy 路线。
- 做一个工具向项目（查看器、模拟器、格式转换），体会 Rust 的交付质量。
- 走到发布：桌面打包、CI、商店流程，入口见《技术实现手册》§6 与发布相关手册。
7. 常见坑¶
- 和借用检查器正面硬刚：把游戏按「对象互相引用」写，编译器会天天拦你。打不过就加入数据导向：组件不互相持有，系统靠查询与事件通信。
- 拿 debug 构建当真相：慢一个量级是常态，用它判断性能方向全盘皆错（§5.2）。
- 文档与教程滞后：接口演进快，旧写法一顿编译不过。以官方示例与迁移说明为准；社区文章先看发布时间。
- 低估生态缺口：想要的编辑器、中间件、平台集成可能没有现成方案。「等一个 crate」的时间要计进排期。
- 盲目上生产、攒版本大步跳：接口会变、工具链在补、平台支持不均；跨版本大升级让迁移说明叠着读。把「跟版本」当长期成本签进预算，小步升级、每次可回滚。
- 把 ECS 用到题外：UI 状态、静态配置也硬塞进 ECS 只会绕远。边界要清：让 ECS 管实体海，别管整个程序。
- 测试缺席：「游戏没法测试」是借口，无渲染测试恰恰是 ECS 的强项，晚做一步多一坑。
- 魔法数字散落：参数藏在系统里，调参要改代码重编译。集中参数表加运行时检查器，先做这两件。
- 把示例当架构蓝图：示例为演示极简而写，生产要拆插件、分领域、管资产。教程是起点，不是图纸。