Bevy 的第四个生日

发表于 2024 年 8 月 10 日由 Carter Anderson ( @cart @cart_cart cartdev )

嗨！我是 @cart（Bevy 的创建者和项目负责人）。又一年 Bevy 开发终于过去了，这意味着 Bevy 现在正式 四岁了！

按照惯例，我会借此机会回顾过去一年，并概述我们对未来的希望和梦想。如果你好奇，可以查看 Bevy 的第一个生日、第二个生日和第三个生日帖子。

我还强烈鼓励 Bevy 开发人员和社区成员撰写自己的“Bevy 生日”反思帖子。只需将您的帖子发布在某个地方（如果需要，还可以发布在社交媒体上），然后在这里链接到您的帖子。一个月后，我们将发布一个“回顾 Bevy 的第四年”的汇总帖子，将这些帖子汇总在一个地方。这是我们作为一个社区庆祝胜利、识别改进领域和校准我们未来一年的道路的机会。

对于那些不了解的人来说，Bevy 是一款用 Rust 构建的，令人耳目一新地简单的数据驱动的游戏引擎。Bevy 永远免费开源！您可以在 GitHub 上获取完整的源代码。我们有一个快速入门指南。您还可以查看 Bevy 资源，获取由社区开发的插件、箱子、游戏和学习资源的库。

一年里程碑 #

11 月 4 日: Bevy 0.12
- 我们添加了延迟渲染、Bevy Asset V2、PCF 阴影过滤、StandardMaterial 光线透射、材质扩展、Rusty 着色器导入、Android 上的挂起和恢复、自动批处理和绘制命令实例化、渲染器优化、一次性系统、UI 材质等等！
12 月 2 日: Bevy Jam #4：那可是很多实体！
- 第四届官方 Bevy 游戏开发大赛！368 人加入，87 人提交游戏，人们留下了 1639 个评分。那可是很多 beeeeees 获胜了！
1 月 31 日：Bevy 在 crates.io 上的下载量突破 1,000,000 次！
2 月 10 日：Bevy 在 GitHub 上的星标数突破 30,000 颗！
2 月 17 日: Bevy 0.13
- 我们添加了光照贴图、辐射体积/体素全局光照、近似间接镜面遮蔽、反射探针、基本形状、系统步进、动态查询、自动推断的命令刷新点、切片/平铺/九宫格 2D 图像、相机驱动的 UI、相机曝光、动画插值模式等等！
3 月 11 日: Bevy 基金会
- 我们宣布了 Bevy 基金会，这是我们构建世界级免费开源游戏引擎旅程的下一步。Bevy 基金会是一个非营利组织，致力于开发 Bevy 并教人们如何使用它！
5 月 1 日: Alice 在 Bevy 基金会开始全职付费工作
- 感谢 Bevy 基金会慷慨的捐赠者，Alice 能够在 Bevy 基金会开始全职工作，担任软件工程师。
7 月 4 日: Bevy 0.14
- 我们添加了虚拟几何体、锐利屏幕空间反射、景深、逐对象运动模糊、体积雾/光照、胶片颜色分级、PBR 各向异性、自动曝光、点光源的 PCF、动画混合、ECS 钩子和观察者、更好的颜色、计算状态和子状态、圆角 UI 等等！
7 月 20 日: Bevy Jam #5：循环
- 第五届官方 Bevy 游戏开发大赛！224 人加入，79 人提交游戏，人们留下了 1677 个评分（截至目前）。投票期尚未结束，所以去玩玩并给一些游戏评分吧！
8 月 10 日：Bevy 现在四岁了！

数字看一年 #

1027 个在 GitHub 上的独特 Bevy 贡献者（从 741 人增加）
34,537 个 GitHub 星标（从 25,222 个增加）
3,379 个 GitHub 分支（从 2,541 个增加）
9,221 个拉取请求（6,788 个已合并）在 GitHub 上（从 5,732 个 pr 和 3,993 个已合并增加）
5,624 个问题（3,816 个已关闭）在 GitHub 上（从 3,497 个和 2,290 个已关闭增加）
7,770 次提交在 GitHub 上（从 5,214 次增加）
1,327 个 GitHub 讨论（从 874 个增加）
382 个 Bevy 资源（插件、箱子、游戏、应用程序和学习资料）（从 281 个增加）
1,495,435 次在 crates.io 上的下载（从 661,020 次增加）
19,087 个 Bevy Discord 成员（从 14,244 人增加）
4,447 个社区 #showcase 在 Bevy Discord 中的条目（从 3,202 个增加）
2,083,652 条消息在 Bevy Discord 中（从 1,424,903 条增加）

请注意，为了保持一致性和清晰度，所有这些数字均以“绝对总数”给出，因为它们通常是以这种方式报告的。例如，我们现在有 34,537 个总 GitHub 星标……您将在我们的代码库中看到的数字。我还列出了去年报告的总数，可以用来计算自去年以来这些数字的变化。

我感到自豪的事情 #

我会尽量避免重复，但是请注意，我仍然对我在 Bevy 的第一个生日、第二个生日和第三个生日帖子中概述的内容感到非常自豪。

Bevy 基金会 #

今年，启动 Bevy 基金会占据了我大量的时间。我不得不学习建立公司的复杂流程，研究和选择最佳的法律结构，获得州级非营利组织资格，获得联邦级 501c3 非营利组织资格（这里最难的部分是准备申请，至今五个月后仍处于待处理状态），在美国公司雇用加拿大员工，设立公司银行账户，定义章程，利益冲突政策，公司章程，州和联邦税收合规性，通过公布结构性文件和会议记录来最大限度地提高透明度，我构建了一个自定义的众筹平台来减少开销……等等等等。这是一项令人筋疲力尽的工作，但它绝对是一项值得的投资。

有了 Bevy 基金会，Bevy 就可以独立于任何个人，过上稳定而长久的生活。它的存在是为了成为一个中心化的、值得信赖的地方，为 Bevy 项目提供资金和领导。它将使命（尤其是社区的需要）置于一切之上。它由董事会领导。按照惯例，董事会成员与 Bevy 维护者之间存在 1:1 的对应关系……我们希望那些真正身处前线的人来负责基金会。董事会结构也意味着我不再对 Bevy 拥有绝对的权力。我目前是基金会的主席（按照惯例，这也是 Bevy 的项目负责人）。这两个角色的组合给了我过去拥有的许多相同权力。但现在，我的工作是执行董事会的意愿。如果他们不再认为我应该担任该职位，他们可以罢免我。

这也解决了我们最大的未解决资金问题：“人气竞赛”式的临时个人众筹。通过将所有资金直接投入到 Bevy 基金会，资金不再直接流向拥有最大粉丝群体或与项目最直接联系的人。相反，Bevy 基金会可以选择资金的使用方式，以满足项目的需要。

Alice 继续推动前进 #

今年，感谢我们慷慨的捐赠者，Bevy 基金会能够聘请 Alice 担任全职软件工程师。

多年来，Alice 一直作为维护者，投入了无数时间，除了个人的技术贡献、文档工作等等之外，还承担了很大一部分（主要！）Bevy 项目管理职责。她在 Bevy 基金会的新全职职位上将这些职责提升到了一个新的水平，其好处是显而易见的（也是可以量化的）。拉取请求停滞的频率要低得多。我们的问题积压得到了紧密地整理。Bevy 整个生命周期中已合并的总拉取请求的 41% 发生在过去一年。我们独特的贡献者总数在过去一年中增长了 39%！Bevy 的开发速度在今年迅速提高，而 Alice 是拓宽瓶颈使之成为现实的人。Bevy 社区、维护者和我都感受到了多年来这种瓶颈的限制。虽然“扩展 Bevy 开发”将是一个始终存在、不断变化的问题，但我想代表我们大多数人说“谢谢你，Alice，让这一切变得比以前好太多”。

这也让我能够从这些职责中退出一大步。我仍然在履行这些职责，但频率要低得多。这反过来又让我能够将时间投入到诸如启动 Bevy 基金会和设计和构建 Bevy 的新场景/UI 系统（对 Bevy 开发者体验的一项重大改进，也是即将推出的 Bevy 编辑器的基石）等事情上。

尽管项目管理一直是重点，但我还是想强调 Alice 的角色是多方面的。她对技术工作、基金会项目、文档等等都有很大的计划。但我还是让 Alice 自己来谈谈这些吧！

渲染器成熟度 #

今年，我再次对 Bevy 的渲染器成熟速度感到惊讶。我以为去年是渲染器的一个里程碑（可能是异常）年份，但 Bevy 的第四年可能更重要。这仅仅是“重大”亮点功能的列表

今年，Bevy 渲染器开发社区真的热起来了。除了往年的一些“常客”（@superdump、@JMS55、@robtfm、@DGriffin91、@aevyrie、@icesentry、@coreh 等），你可能会注意到，许多这些功能都是由@pcwalton构建的，他是今年才加入 Bevy 项目的（但他肯定不是 Rust 生态系统的新人）。今年他非常高产，Bevy 社区很幸运能有他加入。

总体而言，Bevy 现在拥有许多人们对现代游戏引擎的渲染器功能的期望，此外还包括一些令人兴奋的尖端功能，例如虚拟几何（由@JMS55构建），这是除了虚幻引擎之外几乎没有人提供的功能（你可能听说过 Nanite！）。

今年，我们通过许多针对性的优化、将更多工作转移到 GPU 以及重构渲染器数据流，在渲染器性能方面取得了巨大进步。我们正在向 GPU 驱动渲染过渡，这将更进一步。我们在这个领域还有很多工作要做，但我们现在已经有很多项目在进行，而且有很多积极且才华横溢的渲染器开发人员。

将此与目前最模块化的游戏引擎渲染器之一结合起来，我认为 Bevy 非常适合在未来一年吸引渲染器狂热者以及那些对利用顶级图形技术感兴趣的人的关注。

如果您有兴趣深入了解，请查看我们充满活力的 #render-dev Discord 频道.

UI 生态系统开发 #

Bevy UI 是目前 Bevy 引擎开发中最令人兴奋的领域之一。我们在这个领域有很多项目

我的下一代 Bevy 场景/UI 工作：这是下一代场景/UI 工作组的启动文档，概述了我目前的工作，以及我们前进道路的总体愿景。
Alice 对 UI 的愿景：这在一定程度上是对我的文档的回应。它旨在以问答的形式更广泛地定义该领域。它还对每个答案都赋予了置信度，这使得它成为人们查看哪些是可靠的以及哪些还需要讨论的绝佳场所。这份文档编码了 Alice 的想法，但我也完全同意这些想法。
Quill：@viridia 为 Bevy 创建的粗粒度（React 风格）响应式 UI 框架。他们用它构建了一些非常令人印象深刻的演示。Quill V2 刚刚发布，比以往任何时候都更好。
Bevy Reactor / Obsidian：Bevy Reactor 是@viridia 为 Bevy 创建的细粒度（Solid.js 风格）响应式框架，而 Obsidian 是一个基于它的 UI 框架。@viridia 一直在“响应式”领域投入大量时间进行实验。我认为他们现在是值得信赖的专家，他们的工作一定会帮助为上游 Bevy UI 指明方向。
Woodpecker UI：Woodpecker UI 是@StarArawn 之前项目 kayak_ui 的一个激动人心的继任者。它是一个响应式 UI 框架，具有 vello 渲染、ECS 优先设计以及一些内置的小部件以供使用。
Sickle UI：一个基于 Bevy UI 构建的令人印象深刻的完整小部件库。
Bevy egui：经过验证和可靠的即时模式 UI，多年来一直在填补 Bevy UI 生态系统的空白。仍然是顶级选择，尤其是如果您正在寻找即时模式。
Bevy Cobweb UI：一个基于 sickle_ui 的层，它使用 bevy_cobweb 响应式框架。
haalka：一个基于 futures-signals 的 Bevy 功能响应式编程 UI 库。
Bevy Lunex：一个用于 Bevy 的保留 UI 框架，具有新的布局引擎和对世界空间 UI 的支持。
belly：一个基于 Bevy UI 的层，它提供了一种新的宏语法、样式表和数据绑定功能。
cuicui：一个用于 Bevy 的响应式 UI 框架，具有简单/直观的布局算法，由一系列令人印象深刻的模块化组件组成。
bevy_dioxus：基于 Rust 的 Dioxus UI 框架的 Bevy 集成。

你可能已经猜到了，Bevy 社区已经非常广泛，并且覆盖了大量领域。Bevy 用户现在拥有大量用于第三方 Bevy UI 框架的可靠选择，每个选择都采用了不同的意见一致的路径。

但是，现在是时候开始收敛了。Bevy 需要一个高质量的官方 UI 框架，社区可以团结起来支持它。

Bevy 的即将推出的统一场景/UI 系统 #

新成立的下一代场景/UI 工作组将提炼上述经验教训，并理想情况下让尽可能多的 Bevy UI 开发人员社区成员加入下一代官方 Bevy UI（以及场景... 重要的是要注意，我们在这里构建一个组合的场景/UI 框架... 一个统一的 Bevy 数据模型）。

正如我的设计文档中所述，我所做的大量工作都是分层构建的。我的目标是在每一层建立共识，并尽快开始合并它们。当我们向上移动“堆栈”时，每一层都会变得更有争议。最终，我们将在堆栈中达到一个点（例如：响应式和样式），这将需要在许多开发人员之间进行大量讨论和协作。也就是说，我认为现在几乎没有未知数。我们已经探索了这个领域，并且编写了大量的代码。现在我们只需要操控方向盘了。

新的场景/UI 系统将是对 Bevy 功能的一次巨大升级。开发 Bevy 应用程序（游戏、UI 应用程序、工具、编辑器等）将比以往任何时候都更容易、更有趣。我为我的宏伟目标和戴着营销帽子的行为道歉，但我真的认为这将使 Bevy 成为顶级通用应用程序开发框架以及下一代游戏开发框架（当然，也是游戏引擎）。

响应式场景将非常重要，我们是首批实现它们的人之一！由于bsn! 宏，我们还有可能成为第一个允许你在代码以及资产文件中（最终在 Bevy 编辑器中以视觉方式）使用相同资产格式定义场景的流行引擎。这将赋予开发人员使用最适合他们的范式以及在适合他们时混合范式的能力。

我非常期待这一切对 Bevy 开发人员体验意味着什么，无论是作为 Bevy 的项目负责人还是作为 Bevy 的用户。

Bevy ECS 成熟度 #

与之前几年不同的是，之前几年，Bevy ECS API 会发生重大而广泛的改变（Schedule v3、Schedule-First API、Bevy ECS V2 等），而今年，我们的核心 ECS API 大体上保持稳定。我们能够在上面构建大型新功能，例如钩子与观察者、动态查询以及一次性系统，而无需人们重新编写代码。

我预计这种趋势将在未来继续下去。我们已经多年迭代核心 Bevy ECS API，我认为我们终于找到了可以经受住时间考验的东西。Bevy ECS 人体工程学很好，使用起来很愉快，而且速度很快！

这也是我预计在引擎的其他领域看到的模式：最初的快速和积极的迭代以找到理想的设计，然后是稳定和对坚实基础的迭代改进。

总有改进的空间 #

仍然没有编辑器 #

是的，又一年过去了，Bevy 编辑器还没有出现。我们在这方面确实取得了重大进展。

如上所述，我们即将推出下一代场景/UI系统的最小可行产品 (MVP)。这是 Bevy 编辑器的基石，因为我们不仅会用它来构建编辑器的 UI，还会用它来构建 Bevy 编辑器的场景编辑器。
我们正在实施 Bevy 远程协议，它将使 Bevy 编辑器能够在运行时（甚至在不同机器/平台上）与 Bevy 应用进行通信和交互。
我们推出了 Bevy Asset V2，它将使 Bevy 编辑器能够驱动资产配置和预处理。
我们启动了 Bevy 编辑器原型工作，这是一个管理开销低/设计约束低的平台，Bevy 贡献者可以在此合作进行编辑器实验。这将使感兴趣的开发者能够在完成基础部分的同时构建编辑器体验。最近那里比较安静，但在这个框架之外，已经出现了许多 Bevy 编辑器原型：bevy-web-editor、space_editor、@viridia 正在基于其 UI 工作构建编辑器功能，还有优秀的 BLENVY，它将 Blender 变成一个 Bevy 场景编辑器！

所以，是的，Bevy 编辑器正在进行中。我们都在尽最大努力朝着这个目标前进。我本来希望我们在第四个生日之前能有一款可用的产品，但不幸的是我们没有做到。

幸运的是，与前几年不同的是，我们终于走上了正轨，许多难题已经得到解决。还有很多工作要做，但我开始看到隧道尽头的光明了。

我们本可以（而且事后看来，可能应该）采取更多捷径来更快地实现目标。在开发者工具领域，拥有一些东西，即使不完美，也比什么都没有好。但无论好坏，我们正在接近这条更长、更谨慎、更有意图的道路的终点。这意味着我们将拥有更坚实的基础，从一开始就能更好地进行构建。

Bevy UI 停滞不前太久了 #

我们终于开始达成共识，并在 Bevy UI 的下一步发展方面取得了重大进展（见上文更积极的 UI 生态系统发展部分）。话虽如此，但由于拖延了这么长时间，我也造成了很多分散的努力。我认为缺乏一个强大的重心，让大家觉得，如果他们想看到进展，就必须自己去构建一些东西。事实证明，这确实取得了一些成果，正如第三方 Bevy UI 框架的激增所证明的那样。但我认为，这些努力中的很大一部分本可以也应该投入到一个单一的上游项目中。这是我明显缺乏领导力的表现。我知道存在这种真空，但我选择专注于我个人对场景/UI 的实验、Bevy 基金会、Bevy Asset V2 等。我在年初提出的第一个场景/UI 提案引发了许多良好的讨论，但随后每个人（包括我）都各自去做自己的事。好吧，我们已经这样做了……太久了，现在是时候 *真正收敛*了。通过下一代场景/UI 工作组的启动，我现在有时间和精力确保不再犯同样的错误。我将尽快推动达成共识，并取得 *上游* 的实际进展。

我们有未填补的 SME 角色 #

Bevy 使用主题专家 (SME) 系统，赋能那些在特定开发领域证明过自己的开发者，让他们帮助塑造 Bevy 在其领域的未来。总的来说，事实证明这是一个扩展开发能力的好方法。我们已经看到它在 ECS、渲染方面取得了成效，在一定程度上也适用于动画和输入。

如果你查看 Bevy 人员页面，你会注意到没有列出音频、UI 或资产方面的 SME。而这些都是 Bevy（或任何游戏引擎）的重要支柱。这意味着维护者和项目负责人（我）又回到了瓶颈的位置。这样做效率低下，也表明这些领域的知识过于集中在少数人身上。

以下都是事实

社区中有能够胜任这些角色的人。
不填补这些角色会阻碍这些领域的进展。
我们已经 *有意* 尚未填补这些角色。

这是为什么呢？

所有这些领域都有一个共同点：它们目前都处于“变动中”。在这种情况，“变动中”的另一种解释是“存在投资、领导力或愿景真空”。这使得很难确定 SME，因为 SME 必须在被任命 *之前* 证明其投资、领导力和愿景。

音频：Bevy 的音频实现历来都是最低限度/勉强满足常见场景。它近年来有所改进，但仍然很简陋。我们优先考虑了其他事情，直到最近才有人试图长期负责它。 bevy_kira_audio 很好地填补了空白，进一步减轻了上游改进的压力。幸运的是，现在有了音频改进工作组，所以我希望在我们提出并实施设计后，能够找到一些 SME 候选人。
UI：有很多人都证明了他们在第三方 Bevy UI 仓库中投入了心血和展现了愿景。但是由于这些努力都没有得到认可，因此从定义上讲，它们都没有与上游 Bevy “保持一致的愿景”。因此，这里存在 SME 真空是我的 *责任*，因为我选择为了先通过实验和研究来发展我自己的愿景，而没有选择完全认可他人的愿景。
资产：过去几年里，我主要负责这个领域。我没有做足够的工作来吸引其他人并帮助他们成为 Bevy Asset V2 的专家。我之后又转向了场景/UI/编辑器工作，在资产领域留下了一个巨大的空缺。

主要的模式是 Bevy 的领导者（通常是我）没有花足够的时间来解除某个领域的阻碍。这通常是故意的：我们优先考虑了其他许多职责，而没有做到这一点（或者在 UI 方面，我们花了 *大量* 时间试图解除该领域的阻碍）。

话虽如此，我确信我们本可以也应该更早地解除这些领域的阻碍。幸运的是，我认为我们将在不久的将来有能力在这些领域任命 SME。

我们从去年的教训中吸取了教训吗？ #

对于组织（和领导者）来说，从错误中吸取教训很重要。以下是去年生日帖子中我列出的“改进领域”，以及我认为我们今年是如何处理它们的。

我想要编写更多（我自己）代码：尽管 Bevy 基金会占据了我很多时间，但我确实写了不少代码。其中大部分属于我的下一代场景/UI 工作或 Bevy Asset V2 及其相关的后续工作。我还花了 *大量* 时间采用/迭代/调整其他人的工作，这是我的倾向。我对今年取得的平衡比较满意，但我仍然认为我需要花更多时间编写代码。希望，现在 Bevy 基金会已经准备就绪，Alice 也全职工作了，明年在这方面将更加高效。
仍然没有编辑器：如上所述，Bevy 编辑器 *仍然* 还没有出现。我们已经取得了重大进展，但这仍然是 Bevy 开发者故事中最大的漏洞，也是我和整个组织持续存在的最大失败（作为项目负责人，我无疑应该承担大部分责任）。
资助 Bevy 很混乱：这个问题已完全解决！Bevy 基金会现在是资助 Bevy 开发的简单、统一、明确的方式。如果你喜欢我们正在做的事情，请捐赠给 Bevy 基金会！

@cart 能预测未来吗？ #

在去年的生日帖子中，我对未来一年做了一些预测。看看我做对了多少！

可视化场景编辑器：随着资产系统工作的完成，我想将我的精力集中在开发可视化场景编辑工作流程（以及完善 Bevy UI 的相关领域）方面。

我再次夸下海口，却未能兑现承诺。请查看上面的部分，了解我的全部想法。

嵌套的 Bevy 场景：开发者需要场景文件具有可组合性才能开发游戏。他们不应该需要降级到代码才能组合多个场景。我们应该在场景中添加嵌套功能（并参考现有的第三方 Bevy 插件，例如 bevy_proto 以获得灵感）。

我们并没有完全实现嵌套的 Bevy 场景，但它 *几乎* 已经准备就绪/已经设计并实现（以 MVP 形式）作为我下一代场景/UI 工作的一部分。我们应该很快就能将它提供给 Bevy 开发者。

推出 Bevy Asset V2：Bevy Asset V2 已经进入最终审查阶段。我们当然希望尽快推出它，因为它将用于场景驱动的流程和其他可视化资产编辑场景。

我们已经推出了 Bevy Asset V2！

合法的 Bevy 实体：如上所述，我们已经到了需要一个合法的 Bevy 实体（例如 Bevy 基金会）来保证项目健康发展的时候。

我们确实成立了 Bevy 基金会！

Bevy 的未来一年 #

Bevy 社区和我对开发 Bevy 采取了相对有机和反应式的态度。在实践中，当开发并非真正按计划进行时，制定一个很长的“计划”清单毫无意义。

话虽如此，以下是我个人对 Bevy 未来一年的希望、梦想和个人优先事项。

下一代场景/UI：我已经对此进行了详细讨论。请参阅此讨论，了解更多信息。
Bevy 编辑器：基于下一代场景/UI 工作构建的可视化场景编辑器（以及其他功能）。希望这是我最后一次在这些帖子中提到这个话题！
关系：优化 ECS 实体之间的“链接”（例如，“父级”关系）。这将填补 Bevy ECS 功能集中的一个最大/最明显的剩余空白。

我们有许多其他工作正在进行中，但我再次选择今年将重点放在这方面，以传达我的个人优先事项。

最后提醒 Bevy 社区成员，他们应该写自己的 Bevy 生日博客文章。请在此提交！

如果这些内容让你感到兴奋，我们非常欢迎你的帮助！查看我们在 GitHub 上的代码，并开始参与 Bevy 社区。

另外，请考虑捐赠给 Bevy 基金会，以确保我们能够继续构建和领导这个雄心勃勃的项目。我们拥有的资金越多，我们就越能扩大 Bevy 的开发规模！

祝 Bevy 越来越好！

- @cart