Bevy和Godot，两种游戏引擎的路线之争

摘要

Godot 用节点加场景树的组合式设计，把"做游戏"变成了搭积木一样直观的事；Bevy 则用 Rust 的 ECS（实体-组件-系统）架构，把游戏当成一个数据驱动的软件工程问题来解。两者不是同一条赛道上的竞争对手，而是两种完全不同的思考方式——选哪个，取决于你更怕"做不完"还是更怕"架构撑不住"。

背景与问题

之前写 Godot 崛起的文章发出后，评论区里最常见的追问是"那 Bevy 呢？“。这个问题背后其实是游戏开发圈这两年一直在讨论的一件事：当 Unity 的授权风波把大量独立开发者推向开源引擎时，大家真正比较的从来不只是"要不要花钱”，而是"要用什么样的方式思考游戏"。

Godot 走的是几乎所有主流引擎的老路——面向对象、场景树、可视化编辑器，上手快、能立刻看到结果。Bevy 走的是另一条路：它诞生于 Rust 社区，从第一天起就选择了 ECS 这种数据驱动架构，编辑器至今还没有正式版本，一切靠写代码搭建。这种路线分歧，决定了两个引擎几乎不会吸引同一批人。

核心思路与优势

Godot：场景树 + 节点，直觉优先。 任何游戏对象都是一个节点，节点组合成场景，场景又可以互相嵌套、复用，形成树状结构。这种设计几乎不需要额外的心智负担——它符合大多数人对"物体"和"层级关系"的自然理解，也是 Godot 区别于传统"实体-组件"式引擎的标志性特点。截至目前，Godot 最新稳定版是 4.7.2（2026 年 8 月的维护更新，59 个 bug 修复），今年 6 月发布的 4.7 正式版带来了 HDR 输出、内联着色器预览、全新 Asset Store 等一批打磨型更新；年初的 4.6 则把 Jolt 物理引擎转正为所有新建 3D 项目的默认选项，还统一了停靠面板系统（可拖拽、可悬浮）、大幅重写了屏幕空间反射，Windows 上新建项目的默认渲染后端也换成了 Direct3D 12。开箱即用的可视化编辑器、GDScript 这种接近 Python 语法的脚本语言（同时也支持 C#、C++，可通过 GDExtension 接入其他语言），让 Godot 从写下第一行代码到看到画面之间的距离非常短。引擎由非营利的 Godot 基金会维护，MIT 协议意味着零授权费、零分成，代码库和路线图完全公开。它的 GitHub 仓库目前已经积累了约 11.7 万颗星，是开源游戏引擎里星标数最高的项目之一，社区提交的插件、模板、教程也远比 Bevy 丰富，官方 Asset Library 里已经有数千个可直接安装的资源包。

Bevy：ECS，把游戏当系统架构来设计。 在 Bevy 里，实体（Entity）只是一个 ID，组件（Component）是纯数据结构体，系统（System）则是一组读写特定组件的函数——三者彻底解耦，没有"继承基类"这回事。这种数据驱动的设计天然适合需要同时处理大量对象、逻辑相互交织的场景，系统之间的依赖关系在编译期就能被引擎分析、自动并行调度，这也是 ECS 架构相比传统面向对象引擎在性能上的核心优势。Bevy 完全基于 Rust 打造，MIT/Apache-2.0 双授权，没有内置脚本语言，深度依赖 Rust 本身的类型系统和借用检查器来保证内存安全。它目前仍处于 0.x 阶段，节奏大致是半年一个大版本：去年 9 月的 0.17 带来了工作进展中的 Solari 光线追踪、Nvidia RTX 显卡的 DLSS 支持和基于 Dioxus subsecond 的 Rust 热补丁能力（改代码不用重启程序）；今年 1 月的 0.18 引入了按需编译的 cargo 功能集合（2d/3d/ui，只编译用得到的模块）；6 月的 0.19 由 261 位贡献者、1185 个 PR 合力带来了全新的、大幅改进的场景系统（BSN，Bevy Scene Notation）。代价是几乎每个版本都伴随破坏性 API 变更，跟着升级本身就是一项持续投入。即便如此，Bevy 的 GitHub 仓库也已经涨到约 4.8 万颗星，是 Rust 生态里关注度最高的游戏引擎项目，社区通过 crates.io 贡献了大量第三方插件（物理、寻路、UI 组件等），这在一定程度上弥补了官方生态还不够完整的短板。

两者最大的分野，其实是编辑器有没有。 Godot 的编辑器功能齐全，场景编辑、动画、着色器预览、Asset Store 一应俱全；Bevy 至今没有官方可视化编辑器，团队正在开发的 bevy_editor_prototypes 项目还处于早期原型阶段，目标是先做出一个能交给资深 Bevy 用户试用的实验性 alpha 版本，且明确表示不会依赖 egui 这类"非 Bevy 原生"工具栈来搭建编辑器，一切都要等自家的编辑器体系成熟。这意味着现在用 Bevy 做游戏，关卡设计、场景搭建基本都要靠写代码完成，对美术和关卡设计师非常不友好。

代表作品

Godot 阵营 早已不是"玩具引擎"，不少叫好又叫座的独立游戏都诞生于此：

• 《杀戮尖塔 2》（Slay the Spire 2）：卡牌肉鸽鼻祖的正统续作，开发团队在 Unity 上做了两年多之后，因为收费政策争议整体迁移到 Godot 重做，是这场引擎迁移潮里最有分量的案例。
• 《土豆兄弟》（Brotato）：单人肉鸽射击游戏，操控一颗武装到牙齿的土豆在一波波外星生物围攻中生存，全平台销量已突破千万份。
• Buckshot Roulette：第一人称桌面模拟恐怖游戏，玩家和诡异的庄家轮流面对装填了实弹与空包弹的道具对赌生死。
• Dome Keeper：挖矿与塔防结合的生存游戏，间歇下潜挖掘资源升级装备，再赶在怪物潮来临前回到地面守住能量穹顶。
• Cassette Beasts：把怪物收集玩法和"用磁带录制怪物并变身"机制结合的开放世界 RPG，口碑与销量双丰收。
• Cruelty Squad：用故意粗糙的 PS1 画风包装企业反乌托邦讽刺题材的沉浸式射击游戏，独立游戏圈公认的邪典神作。

Bevy 阵营 商业作品数量还很有限，但已经出现了几个有代表性的案例：

• 《Tiny Glade》：目前公认的旗舰级 Bevy 商业作品，由瑞典独立工作室 Pounce Light（仅两人）开发，2024 年 9 月上线 Steam 后长期是 Steam 愿望单排行榜前列的常客。游戏最初只是一个"程序化生成城墙"的周末小项目，最终做成了一款可以随意搭建、拆改中世纪村落的治愈系建造游戏——用的是 Bevy 的 ECS，但渲染管线是团队自己写的，并非直接套用官方渲染器。
• Molecoole：一款俯视角射击肉鸽，玩法是把捡到的各种"原子"组合成越来越强力的武器，游戏内共有 70 多种不同的原子组合。它早在 2022 年就已上线 Steam，常被认为是第一款完整使用 Bevy 引擎登陆 Steam 的商业作品。
• Toroban：一款"无限环绕"解谜游戏，由 Hebert Games LLC 开发，2025 年 12 月登陆 Steam（Windows/Linux），是 Bevy 阵营里较新的商业尝试。

Bevy 目前还没有出现能打破圈层、获得主流曝光度的作品，商业履历的厚度和 Godot 相比仍有明显差距——这也是很多人在纠结"要不要用 Bevy 做正式项目"时最直接的顾虑。

面向人群

• 想快速把游戏做出来的独立开发者：如果目标是这个月、这个季度就要有一个能玩的原型，Godot 的可视化编辑器和成熟工具链几乎是唯一合理的选择。
• 有 Rust 背景、愿意为架构买单的团队：如果游戏本身的复杂度更接近"系统工程问题"而非"场景搭建问题"——比如需要模拟大量相互作用的实体——ECS 架构带来的解耦和性能优势会在项目变复杂后逐渐显现价值。
• 不介意跟随快速演进引擎的开发者：选择 Bevy 意味着要持续跟进迁移指南、适应 API 变化，这本身也是一种投入产出的取舍。
• 需要移动端稳定发布的团队：Godot 的 Android/iOS 导出流程已经打磨多年；Bevy 官方虽然也列出了 iOS 和 Android 支持，但 iOS 相对成熟，Android 社区反馈仍不如桌面端稳定，建议优先在真机而非模拟器上测试。

怎么选

真正决定选型的，往往不是"哪个引擎更强"，而是这几个具体问题：

如果你现在就要做游戏，Godot 依然是更稳妥的答案；如果你更在意的是几年后系统会不会撑不住，Bevy 提供了另一条值得关注的路。

项目地址

• Godot 官网：godotengine.org，源码仓库：github.com/godotengine/godot
• Bevy 官网：bevy.org，源码仓库：github.com/bevyengine/bevy