Bevy vs Godot：两条路线的游戏引擎

2026 年 6 月，游戏开发社区迎来了一个微妙的时刻。

6 月 17 日，Godot 4.7 发布。标题叫”Lights, Camera, Action!”——灯光、摄影、开拍。新功能清单读起来像是一份可视化工作流的 wishlist：实时的矩形面光源 AreaLight3D，编辑器内文本着色器的实时预览，HDR 输出支持，还有全新的 Asset Store。每一个特性都在说同一件事：打开编辑器，你就能看见效果。

两天后，Bevy 0.19 发布。这份清单画风完全不同：BSN（Bevy Scene Notation）脚本语言、261 位贡献者贡献的 1185 个 PR、Solari 路径追踪渲染器的迭代、Feathers 编辑器组件库的扩展。从头到尾没有一句”打开编辑器就能……”，因为它连编辑器都还在社区项目阶段。

这两个引擎前后脚放出大版本，在时间上的”巧合”本身就在问一个问题：做游戏引擎，应该先做编辑器，还是先做好代码层面的架构？

两份 feature list 的对照

在深入之前，先把两张发布的”菜单”并排看看：

特性维度	Bevy 0.19	Godot 4.7
核心架构哲学	数据驱动 ECS，Rust 代码定义一切	节点-场景树，可视化编辑器优先
脚本/场景系统	BSN（Bevy Scene Notation）——类 Rust 语法的场景描述语言，通过 bsn! 宏在代码中定义	GDScript / C# / 可视化脚本，编辑器内直接编辑
光照渲染升级	接触阴影（Contact Shadows）、矩形面光源、SSR 物理化改进、Solari 路径追踪迭代	AreaLight3D 实时矩形面光源、HDR 输出支持
编辑器进展	Feathers 编辑器组件库（BSN 化）、社区项目 Jackdaw 推进中、官方编辑器原型仓库	新 Asset Store、编辑器内 shader 实时预览、3D 顶点吸附、Path3D 吸附到碰撞体
UI/文本系统	EditableText 组件（终于支持文本输入）、FontFamily/可变字体	Control 节点偏移变换、Font-size aware RichTextLabel
性能优化	GPU 化渲染管线、1.6M 立方体场景从 21 FPS → 53 FPS	后台线程化 Asset Store、nearest-neighbor 缩放选项
社区规模	261 贡献者，1185 PR（0.18 → 0.19）	发展基金支撑，多平台原生支持（含 Android 编辑器）

这张表本身是中立的，但它暴露了一个根本分歧：Bevy 在做的事，Godot 几年前就已经做好了（编辑器、场景系统、光照），而 Godot 正在追赶的（性能极限、ECS 架构、高级渲染调度），Bevy 从第一天起就在做。

BSN：Bevy 对”场景”的重新定义

Bevy 0.19 最重的特性是 BSN——Bevy Scene Notation。它看起来像这样：

bsn! {
    Player {
        score: 0
    }
    Team::Blue
}

乍一看，这不就是 Rust 宏包装的组件列表吗？和 Bevy 之前的 Bundle 有什么区别？

区别在于 BSN 有三个超能力：可组合、可打补丁、依赖感知。用官方的话说：“不再需要手动拉入生成一个实体所需的所有 ECS 和资源依赖。”

这意味着你现在可以在 Bevy 的 Rust 代码里写出类似”声明式 UI”的描述——Feathers 组件库已经全面迁移到 BSN 语法。一个带观察者的复选框在 BSN 下是这样写的：

bsn! {
    @FeathersCheckbox {
        @caption: bsn! { Text("Enable shadows") ThemedText }
    }
    MyCheckbox
    on(|change: On<ValueChange<bool>>, mut config: ResMut<ShadowConfig>| {
        config.enabled = change.value;
    })
}

注意一个细节：Bevy 团队在发布博文中特别强调——“Bevy 0.19 在技术上支持场景资产文件，但我们还没有发布第一方的 .bsn 资产加载器。这次发布聚焦于代码驱动的工作流。”

这话翻译过来就是：“编辑器还没好，先用代码写。“Bevy 的做法是先把语言层定义清楚，编辑器的事后面再说。

Godot 4.7：给编辑器插上更多眼睛

Godot 4.7 的选择恰好反过来。

它的实时光照 AreaLight3D 是一个按钮就能用的节点：拖一个 Rectangular Area Light 进场景，调整尺寸和强度，阴影自动变软，反射自动变真实。不需要写一行 shader，不需要理解 LTC（Linearly Transformed Cosines）的原理。

它的编辑器内 shader 预览更直白：你在文本编辑器中敲 vec2 v4 = UV;，右侧画面实时更新渲染结果。过去你需要编译 → 切到场景视图 → 查看效果，现在打字的同时就能看见。

这些改进反映了一个成熟编辑器团队的优先级：降低反馈循环的延迟。Godot 4.7 的每一个新特性几乎都在缩短”我想 → 我改 → 我看”之间的等待时间。

新的 Asset Store 同样遵循这个逻辑——加了产品评分、缩略图缩放、后台线程化加载。创作者找插件时不会卡住编辑器 UI。

两套思路的差别不妨用一句话概括：Godot 在打磨”你能看见什么”，Bevy 在定义”你能表达什么”。

Rust ECS 的承诺与代价

Bevy 的底层哲学是 ECS——Entity Component System。这本身不是新概念，Unity 的 DOTS、Flecs、EnTT 都走这条路。但 Bevy 是唯一一个把 ECS 当作唯一世界观的主流游戏引擎。

在 Bevy 里，没有”GameObject”或”Node”。一切是 Entity，一切是 Component，一切逻辑是 System。你写 fn move_player(query: Query<&mut Transform, With<Player>>)，系统自动并行遍历所有符合条件的实体。没有继承，没有虚函数表，没有 GC 暂停。

这让 Bevy 在处理大量实体时展现出惊人的性能数据：Bevy 0.19 把 160 万个 PBR 立方体从 21 FPS 拉到 53 FPS；同样是 5.5 万个实体的城市场景，渲染时间从 19.3ms 降到 11.8ms。这些数字来自「把更多工作从 CPU 搬到了 GPU，做了更多批量渲染和并行化」。

代价呢？学习曲线陡峭。不理解 ECS 范式的开发者进入 Bevy 会感到束手束脚——你不能随意在 Entity 上挂一个脚本让它跑逻辑，你必须写 System、设计 Component、管理 Schedule。Bevy 的官方快速入门文档从 ECS 概念开始讲，而不是”如何拖一个立方体到场景中”。

此外，Rust 语言本身的编译时间和所有权模型在游戏开发的迭代式工作流中是一个真实成本。快速实验——改一行代码 → 看效果 → 再改一行——在 Bevy 里意味着完整编译（虽然增量编译和 cargo-watch 能改善，但远不到 C#/GDScript 的热重载体验）。

编辑器的”蛋鸡悖论”

Bevy 的编辑器问题，其实是个经典的鸡生蛋问题。

要写一个好用的可视化编辑器，需要一套成熟的场景系统、组件系统、UI 框架。Bevy 选择先造这些”编辑器的基础设施”——BSN 场景语言、Feathers Widget 库、交互式 Transform Gizmo、无限网格。0.19 甚至新增了 Diagnostics Overlay（调试覆盖层）和 Interactive Transform Gizmo（交互式变换工具），这些本质上都是编辑器所需的原子能力。

社区方面，Jackdaw（一个为 Bevy 打造的 3D 编辑器）正在活跃开发中。Bevy 官方在 GitHub 上也有 bevy_editor_prototypes 仓库，其中明确说：“对于活跃的低摩擦实验和工作原型，请关注并贡献社区驱动的 Jackdaw 项目。”

这句话传递的信息很诚实：官方还没有编辑器，但他们知道社区在做什么，也在为未来的编辑器铺路。

相比之下，Godot 的编辑器已经成熟到可以在上面开发商业游戏——从 4.0 到 4.7 的三年里，它的重心从”稳定可用”逐渐过渡到”打磨体验”。4.7 的 3D 顶点吸附、Path3D 吸附到碰撞体、CSG 自动平滑、Ruler 工具的矢量测量——这些都是一个有重度编辑器用户的团队才会花精力做的细节。

但 Godot 也有自己的”语法债”：它的 ECS 是通过 Godex 等社区插件实现的体系，并非原生架构。当你的游戏逻辑开始变得复杂——大量实体需要高效的、并行的规则组合时——Godot 的场景树模型可能会变成一个瓶颈。

性能不是全部

Bevy 0.19 的渲染数字很漂亮，但笔者想说一句：性能是选择引擎的一个维度，不是全部。

游戏开发是一个系统工程。渲染效率只影响帧率，但开发效率影响的是你能不能按时交货。如果你的游戏逻辑简单、资产靠手工摆放、团队里有非程序员的策划和美术，Godot 的编辑器工作流可能让整个团队的产出翻倍。反过来，如果游戏的核心机制是一个由数千个实体构成的复杂系统——模拟类游戏、RTS、大量 AI 角色的 RPG——Bevy 的 ECS 表达力可能让你避免在”对象树”里维护复杂状态机。

选择的关键在于找到「更适合」场景的引擎，不存在一个引擎在所有维度上优于另一个。

社区信号的对比

从 Lobsters 上的热度来看，Godot 4.7 获得了 △87/5 条评论，Bevy 0.19 是 △73/9 条评论。Godot 的”赞”数更高，但 Bevy 的讨论密度更大——5 条评论 vs 9 条评论说明 Bevy 的发布更引发了社区内部的讨论。

在 Bevy 的 Lobsters 讨论中，有一条评论大意是：“当 Bevy 也推出完整编辑器时，Godot 就真的要被追着打了。“这种期待感代表了 Rust 社区对 Bevy 的信心——他们认为 Bevy 目前只是”有件事还没做”，而非”做不到”。

而 Godot 的 Lobsters 讨论中，有人将 Godot 类比为”游戏开发界的 Blender”——在 Unity 的定价策略反复震荡下，越来越多的开发者开始认真审视开源方案。

值得留意的是，Godot 4.7 发布博文中还提到一个不太显眼的特性：Landmark Navigation for Enhanced Accessibility（地标导航辅助功能增强）。这个 PR 来自 Nolan Darilek，为视障开发者提供了屏幕阅读器的”地标”感知能力。在一个游戏引擎的发布中看到无障碍改进，说明这个项目的成熟度已经到了”开始关注边缘用户”的阶段。

融合还是分岔？

如果把视角拉远，Bevy 和 Godot 的路线差异其实在缩小——方向相反，但目标接近。

Bevy 从代码出发，正在造编辑器。BSN 不仅在 Rust 代码中可用，未来也将是 .bsn 资产文件的格式。Bevy 团队的计划很清晰：先在语言层面把场景定义做扎实，等 BSN 成熟之后再推广到文件层面，最终由编辑器生成和消费这些文件。

Godot 从编辑器出发，也在吸收 ECS 的思路。4.x 版本的渲染器已经重写为更数据驱动的管线，GDScript 的性能持续优化，社区的 Godex 项目试图在 Godot 内提供完整的 ECS 架构。

本质上，两边都知道对方做得对的地方：一个引擎不能没有架构表达力，也不能没有可视化编辑器。只是在”先做哪个”上，两者做出了不同的选择。

维度	Bevy 0.19	Godot 4.7
场景定义	代码 BSN → 未来 .bsn 文件	编辑器可视化 → GDScript 代码
渲染管线	GPU 优先，ECI 组织渲染系统	可视化节点 + 实时光照
编辑器策略	社区先行（Jackdaw），官方铺基础设施	官方维护完整编辑器，持续打磨细节
适合场景	系统复杂、实体量大、Rust 技术栈团队	团队多元、迭代快速、需要可视化编排

结尾：这是一道选择题

回到开头的问题：做游戏引擎，应该先做编辑器，还是先做架构？

Bevy 和 Godot 给出了各自的答案。Bevy 的回答是”先让代码的表达力足够强”，Godot 的回答是”先让可视化工作流够顺滑”。两个答案都没有错，但影响着各自社区的工作方式和所能承载的游戏类型。

对于正在选择引擎的开发者，笔者的建议是：不要只看特性清单，想清楚你的游戏最擅长用哪种方式被创造出来。如果你的游戏核心是一套复杂的规则系统——城市模拟器、自动化工厂、体素世界——Bevy 的 ECS 可能让逻辑的复杂度可控。如果你的游戏核心是场景、光照、动画的编排——平台跳跃、解谜、叙事向作品——Godot 的编辑器能让你在可视化环境中快速迭代。

以上判断来自对两个引擎的长期观察和这次发布的详细对比。笔者的理解一定有限，Bevy 和 Godot 都在快速进化中，本文的观察不代表任何一方的终局形态。如果你在实际使用中遇到了和本文描述不符的情况，欢迎指正和讨论。