新闻
捐赠 爱心图标 GitHub 仓库

Bevy 的第一个生日

发布日期：2021 年 8 月 10 日，作者：Carter Anderson ( 一个戴着猫耳朵挥舞着触手的卡通人物，GitHub 的吉祥物和标志 @cart 一只灰色鸟飞翔的矢量图；X（前身为 Twitter）的旧标志 @cart_cart 一个指向右边的三角形，在一个圆角矩形中；YouTube 的标志 cartdev )

An image representing the article

@cart 在这里（Bevy 的创建者、首席开发人员和项目经理）带来一些令人兴奋的消息

今天是 Bevy 的第一个生日！这一年真是太棒了！现在似乎是回顾我们取得的进展、反思一下并开始思考 Bevy 开发的下一年会是什么样子的好时机。

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

一年的里程碑 #

milestones

  • 8 月 10 日：Bevy 0.1
    • Bevy 的第一个公开发布！经过数月的隐秘工作，我将 Bevy 发布到了全世界。它绝不是完整的，但它已经拥有了大部分支柱，可以向世界展示 Bevy 是什么（以及可以是什么）：一个基于模块化渲染图的现代且灵活的渲染器，一个具有无与伦比的人体工程学和竞争性性能的自定义 ECS，2D 和 3D 渲染功能，资产处理，一个 模块化应用程序模型，模糊了引擎开发人员和应用程序开发人员之间的界限，一个与引擎深度集成的自定义 UI 系统，场景，热重载以及令人愉快的生产性迭代编译时间。
  • 8 月 19 日：绝对狂野的公众接待
    • 仅仅一周后的发布，我们就成为了有史以来第三大最受欢迎的 /r/rust 帖子，在 Hacker News 上排名第二，获得了 2200 颗 GitHub 星星，合并了来自 26 位新贡献者的拉取请求，获得了 644 名 Discord 成员，并收到了 赞助，使我们离第一个资金目标近了 37%。
  • 8 月 20 日：达到第一个资金目标（每月 1500 美元）
  • 8 月 20 日：Amethyst 论坛帖子：“Bevy 引擎 - 解决房间里的大象”
    • 这有助于确立每个项目的优势并确定各种协作领域，标志着这两个社区之间富有成效的关系的开始。
  • 8 月 28 日：达到第二个资金目标（每月 2080 美元）
    • 截至此时，我从事 Bevy 工作的收入是“华盛顿州最低工资”。这标志着我开始考虑将构建和管理 Bevy 作为“我的工作”。
  • 9 月 19 日：Bevy 0.2
    • 在初始发布后一个月，我们发布了另一个大版本！这包括一个新的异步任务系统，性能显着提高，初步的 Web 平台支持，并行查询，一个新的变换系统，操纵杆输入以及一些美味的 Bevy ECS 性能改进。
  • 11 月 3 日：Bevy 0.3
    • 在 Bevy 0.2 发布后又一个月，我们有了另一个大版本！这个版本添加了初始的 Android 和 iOS 支持，WASM 资产加载，触摸输入，资产引用计数，依赖项和子资产，GLTF 场景加载，Bevy ECS 查询人体工程学，100% 无锁并行 ECS 以及其他性能改进，灵活的网格属性，另一个变换系统重写，游戏手柄设置，插件组和动态窗口设置。
  • 12 月 19 日：Bevy 0.4
    • 我们不知何故仍然设法保持“大约每月一次”的发布节奏。我们添加了 WebGL2 渲染后端，跨平台主函数，实时着色器重新加载，灵活的 ECS 参数顺序，简化的查询过滤器，系统输入、输出和链接，功能更强大且更灵活的 ECS 调度实现，“固定时间步长”，状态，gltf 改进，将场景作为子级生成，动态链接，以实现极快的迭代编译时间，一个新的文本布局实现，渲染器优化，一个新的 rust 反射板条箱（填补了 rust 生态系统中的一个主要空白），3D 纹理资产，记录和分析，hidpi 渲染，计时器改进，任务系统改进以及苹果硅支持。
  • 4 月 6 日：Bevy 0.5
    • 几乎每月一次的发布周期终于结束了。但这并不是因为我们放慢了步伐！这个版本是一个大版本。它添加了基于物理的渲染 (PBR)，GLTF 资产改进，Bevy ECS V2：从头开始的完整重写，具有新颖的原型/稀疏集混合存储模型，“原型图”，以更快地改变原型，查询缓存，超快的 for-each 迭代器，一个带有系统标签的新系统执行器，显式系统排序/依赖项，系统集和增加的并行性，“可靠”变更检测以及状态系统的完整重写）。我们还添加了一个富文本 API，hidpi 和 2d 世界空间文本，世界到屏幕坐标转换，一个 3D 正交相机和新的缩放模式，着色器中的灵活相机绑定，渲染层，精灵翻转，色彩空间，线框渲染等等，更小的调整，我没有空间在这里列出。
  • 4 月 14 日：Bevy RFC 流程公开发布
    • 受 Rust RFC 流程的启发，我们添加了一种方法，可以在实现 Bevy API 之前协作设计和审查它们。这通常不是必需的，但是对于更大的更改，它可以确保我们深入思考我们正在构建的内容，减轻风险并将设计和意图编码给未来的 Bevy 开发人员。
  • 6 月 1 日：Bevy 资源的第一个公开发布
    • Bevy 资源 是一个社区开发的 Bevy 插件、板条箱、资产、游戏和学习材料的公共库。该网站由 bevy-assets 仓库 中的结构化 toml 文件提供。它的根源在于 awesome-bevy 仓库，我们以前没有结构的 markdown 文档，其中包含一个社区项目的列表。它现在还是新发布的，但我们对它有很大的计划！
  • 6 月 24 日：达到第三个资金目标（每月 4000 美元）
    • 达到这个目标标志着我开始将 Bevy 视为一种职业。我的技能没有达到“市场水平”，而且我的收入仍然不到我在微软担任高级软件工程师时的 1/4，但我不再是“仅仅收支平衡”了，而且我开始攒钱了。
  • 8 月 2 日：Bevy 在 GitHub 上获得 10,000 颗星星
    • 老实说，我不敢相信我们这么快就做到了。
  • 8 月 10 日：Bevy 现在一岁了！

一年的数字 #

numbers

我感到自豪的事情 #

proud

我们的引擎 #

我非常高兴 Bevy 很快从“我的引擎”变成了“我们的引擎”。看到这么多人找到 Bevy 中的热情项目真是太美妙了。看看发布博客文章中的功能作者列表（在 Bevy 0.1 之后）。这个社区庞大、极度高效，并且非常协作！

我们的社区也非常友好：我们在 Discord 上有一个活跃的 GitHub 问答平台 和 #help 频道（超过 82,000 条消息）。如果您还没有加入，请加入我们的 Discord 并打个招呼！

开发速度 #

看看上面所有的发布以及它们的功能集的大小！即将发布的 Bevy 0.6 将成为另一个大版本，我怀疑我们很快就会减速。结果不言自明，所以我现在就不说了。

实验和迭代 #

我们没有仅仅构建一次就认为那是我们能做的最好的。当我们开始时，我指出我们需要有实验和迭代的自由。我在任何可能的地方都贴上了一个很大的“稳定性警告”，以帮助管理预期。而且我们确实进行了迭代！我们重写了变换系统... 两次。我们 从头开始完全重写了 Bevy ECS，放弃了 hecs ECS 的根基（但没有忘记）。我们有一个全新的渲染器正在开发中。我记不清人们已经设计了多少个“下一代 Bevy UI”原型和设计。

我知道稳定性的缺乏对某些人来说很困难，但我认为这是以协作方式构建 The Best Game Engine™ 的唯一途径。事情很快就会开始稳定下来... 我保证等待是值得的。

Bevy 应用模型 #

今年，我们投入了大量资金来开发我所说的 Bevy 应用模型。Bevy App 易于理解，编写起来人体工程学良好，并且可以通过 Plugin 模块化。我的目标是模糊引擎开发人员和应用程序开发人员之间的界限。我认为我们绝对做到了。

  1. 没有将“引擎逻辑”与“应用程序逻辑”分开的“脚本接口”。我们使用单一语言（Rust）构建整个技术栈。Rust 感觉很现代，它拥有“高级”特性，同时保持了低级性能和控制能力。在我看来，得益于最先进的 Bevy ECS，Bevy 应用程序通常比 Unity 或 Godot 等高级的等效方案更简单，更具表现力。而且，在幕后，Bevy 应用程序 *确实* 更简单，因为在像 C++ 和 C# 这样的语言之间没有内部翻译层。

    use bevy::prelude::*;

// This is a complete, self-contained, cross platform Bevy App
fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_startup_system(setup)
        .add_system(greet_players)
        .run();
}

struct Player {
    name: String,
}

fn setup(mut commands: Commands) {
    commands.spawn().insert(Player {
        name: "Cart".to_string()
    });
}

fn greet_players(query: Query<&Player>) {
    for player in query.iter() {
        info!("hello {}!", player.name);
    }
}

  2. Bevy 引擎的“内部机制”完全使用“应用程序开发者”使用的相同应用程序模型实现。“应用程序开发者” *就是* “引擎开发者”。“引擎开发者” *就是* “应用程序开发者”。

由于 (1)、(2) 以及 Bevy 是免费的开源软件，我们营造了一种其他主要参与者无法提供的“技术栈所有权”感。好奇的应用程序开发者可以深入 Bevy 的内部机制，并立即感到宾至如归。数千个 拉取请求 就是明证。我们见证了从 逼真的物理引擎 到 专门的瓦片地图渲染器 的各种第三方插件的爆发式增长。Bevy 的模块化特性使应用程序开发者能够混合和匹配他们喜欢的部分并“构建自己的引擎”。Bevy 的核心插件，如 AssetPlugin 和 RenderPlugin，提供了一个共同的基础来确保插件之间的互操作性。这与“模块化渲染图”很好地融合在一起，从而形成了一个非常可插拔的引擎。

Bevy ECS #

内容警示：这里我会吹嘘很多，并提出一些难以验证的说法，可能会触犯一些人的敏感神经 :)

Bevy ECS 是我们用来构建引擎特性和应用程序的接口，因此去年我们将重点放在它上面是自然的。老实说，我认为说 Bevy ECS 推动了 ECS 的界限并不为过。Bevy ECS 是“秘诀”（好吧……**咳咳**……“开放式秘诀”），我相信它让我们在引擎市场中独树一帜。这是精心实验、基准测试、与该领域其他专家的合作以及将更广泛的 ECS 生态系统中许多好主意统一起来的结果。

  • 现存的最符合人体工程学的 ECS。这听起来可能像夸张，但我还没有发现任何其他语言的任何产品可以像我们一样简洁地做到我们所做的。我们 一直 在 不断 推动 这 个领域 的 发展。
  • 无宏人体工程学。在 Bevy 中，我们不喜欢宏，因为它们是 DSL（领域特定语言）。我们想编写 *Rust* 代码，而不是“我们发明的恰好存在于 Rust 中的自定义语言”。大多数达到我们人体工程学水平的 ECS 都是通过宏实现的。通过直接在 Rust 类型系统上构建 Bevy ECS，我们确保 Bevy 代码是“纯 Rust”代码，实现更容易调试，用户只需实现相关的特性即可扩展它。这是我们最大的创新之一，我预计随着时间的推移，会有更多项目学习并采用这种模型。
  • 第一个混合原型/稀疏集 ECS：我们是第一个支持原型和稀疏集存储并存的 ECS。在此之前，选择 ECS 的人要么需要选择稀疏集 ECS 以实现更快的组件添加/删除但更慢的查询迭代，要么选择原型 ECS 以实现更慢的添加/删除但更快的查询迭代。使用 Bevy ECS，开发者可以为每个组件选择要使用的存储方式。通过一些巧妙的算法，我们为给定的一组组件选择最佳迭代策略。感谢 @SanderMertens（flecs 的作者）提出了这个最初的想法和设计。之后，Sander 和我花了大量时间合作研究实现细节。Bevy 是“第一个上市”的，但 flecs 计划采用类似的模型（并计划在我们所做的事情基础上进行创新）。这种互利互惠的跨项目合作让我的内心感到温暖。为什么要“藏着掖着”和“竞争”，而不能一起协作构建事物呢？海平面上升，所有船都会受益。
  • 无锁并行 ECS：我们不会在 Bevy ECS 中锁定存储。当一个系统运行时，它可以完全、不受限制地安全地访问它拉取的数据。默认情况下，一切都并行执行。一切正常工作™。您可以轻松地使用系统标签定义系统之间的显式前后顺序，当这很重要时。
  • 自动/并行/全局变更检测：所有变更都可以在 Bevy 中廉价且自动地跟踪。*而且* 它们可以符合人体工程学地查询。这使得一整类其他 ECS 实现无法实现的优化成为可能。据我所知，我们是第一个做到这一点的。我知道的所有替代方案要么在捕捉变更方面不完美，要么需要手动选择加入样板，或者（通常）两者兼而有之。将 Unity DOTs 变更检测 与 Bevy ECS 变更检测 进行比较，以了解我们在此跨越的巨大鸿沟。

对于那些认为 ECS 被过度炒作的人……我完全理解。ECS *不是* 构建优秀引擎的唯一方法。任何告诉你并非如此的人要么别有用心，要么还没有充分考虑这个问题。但是，ECS 是在模块化环境中标准化数据表示和流的最佳方式之一。这是一个 *每个* 引擎都需要解决的问题，结果几乎总是看起来 *像* ECS，即使它们没有使用这个标签。ECS 也是一个非常广泛的类别，以至于几乎毫无意义。如果你认为将 Bevy ECS 视为“Bevy 数据层”会让你更快乐，那么这是一种完全有效的思维方式！我们的 API 扩展到传统的 ECS 定义之外（而且我们 有进一步扩展的计划）。如果你想使用基于 ECS 的引擎，因为你已经相信了炒作，我保证 Bevy ECS 可以实现你的愿望 :)

GitHub 流行度 #

凭借超过 10,000 颗星，我们现在是 GitHub 上最受欢迎的 Rust 游戏引擎，并且领先优势很大。我们是 GitHub 上第 8 大最受欢迎的游戏引擎。而且 Godot（目前以 40,900 颗星排名第一）开始让我们触手可及，尤其是考虑到他们比我们早六年。如果我们明年取得同样的进展，我们将位居第二！我首先要说的是，流行度并非一切。它不是项目成熟度或功能集的衡量标准，但 *是* 我们触及并引起共鸣的人数的衡量标准。赢得人心和思想是扩展开源项目的重要组成部分。我对这一进展感到自豪，我希望社区的其他成员也一样。

Bevy Jobs #

我们开始看到有偿的 Bevy 工作岗位出现，其中一些导致对 Bevy 的开源贡献。这是 Bevy 成熟的下一阶段的开始：专业人士的采用。“稳定性警告”仍然有效，工作室应该将这一点考虑在内，但这些进展让我感到兴奋。

总有改进的空间 #

improve

委派工作和责任 #

在今年的大部分时间里，我一直非常努力地维持对项目各个方面的绝对控制。这只是我做事的方式：我知道我想让 Bevy 成为什么样，并且我对如何实现这一点有非常强烈的意见。我审查了每个拉取请求和设计，阅读了（几乎）每个问题和 Discord 消息，撰写了每篇博文，迷恋着每条推特消息。今年是一个漫长而痛苦的过程，我从中学到了我的极限在哪里，看着项目的需要超过了我的极限，然后固执地拒绝放手，转而选择倦怠、让事情滑坡，或者两者兼而有之。

这部分是我在某种程度上变成了一个控制狂。这部分是由一种更理性的愿望驱动的，即在能够信任其他 Bevy 贡献者的道德和技术实力之前，推迟委托。回想起来，我等得太久了。

幸运的是，在以艰难的方式吸取了教训后，我终于开始进行一些委托了。我创建了一个 Triage 团队，并向感兴趣的 Bevy 贡献者开放。我赋予了 @mockersf 合并小型且相对“无争议”的拉取请求的能力。 @alice-i-cecile 一直出色地处理问题，收集和整合信息。他们也领导着新的 Bevy 图书项目。 @Ratysz 构建并通常“拥有”新的 Bevy ECS 调度程序。现在有很多人承担着责任……但我得在某个地方停止列举。

我仍在学习如何正确地进行委托，而且我委托的还远远不够。Bevy 正在快速发展，我保证我会尽我所能确保我不成为前进的瓶颈。

我并不打算很快放弃我的“仁慈独裁者”身份。请放心，我仍然打算审查（几乎）所有拉取请求，并严格控制引擎的发展方向。但当您看到更多人开始推动越来越大的项目时，不要感到惊讶。扩展是让 Bevy 以其所需的速度增长的唯一途径。

项目规划和传达项目方向 #

在 Bevy 首次发布后，我 表示我们需要集中精力。我概述了我们三个 关注领域

  • 场景：更好的场景格式、内联资产、启用/禁用系统
  • PBR/集群正向渲染：PBR 着色器、HDR、光晕、阴影，所有这些都使用集群正向渲染
  • 编辑器就绪 UI：迭代当前的 Bevy UI，添加画布样式绘图 API，实现核心小部件，主题化

如果你一直关注我们过去一年所构建的东西，我们显然 *并没有* 专注于这些方面，在某些情况下，我们选择完全不同的方向。以下是我们 *实际上* 集中精力的地方（在今年的不同时间点）

  • Bevy ECS 和 Bevy 应用程序模型：核心重写、更智能且功能更强大的并行调度程序、状态、人体工程学、变更检测、性能改进
  • PBR 和 GLTF：成功！我们得到了其中一个……但只有当你假装“集群”不在关注领域标题中，并且忽略 HDR、光晕和阴影时！
  • 渲染器：旧渲染器优化和功能、新渲染器（将在即将发布的 Bevy 0.6 中发布）
  • 平台支持（iOS、Android、Web，以及桌面操作系统的改进）

我们确实对场景进行了小规模的迭代改进，但我们几乎没有触及关注领域问题中提到的主题的表面。我不再认为在场景中启用/禁用系统是一个好主意。 有涵盖其他主题的实验，但我们显然没有“集中精力”。编辑器就绪 UI 已经完全改变了方向。我们计划构建一个全新的 API，而不是基于我们当前拥有的 API。这方面已经进行了很多设计工作，人们一直在不断地进行实验，但同样……这不是我们的重点。

报告的优先级和实际优先级之间存在明显的差异，尤其是在我如何分配时间方面。许多人可能还记得“我们专注于重写ECS的时期”、“我们专注于PBR的时期”或“我们专注于新渲染器的时期”（也就是现在）。你不会记得“我们专注于编辑器就绪UI的时期”，因为它还没有发生。这给那些尝试在这方面有所突破的人带来了问题。他们可以自由地进行自己的实验，但由于我没有花时间构建或“认可”设计（因为我坚持对这些事情有最终决定权），感兴趣和积极的开发者最终变得“无方向”。

我相信我们专注于正确的事情。我们有比我预料的更多的“基础性”工作要做。随着时间的推移，我们都意识到真正的重点领域应该是什么，但我们从来没有“报告出来”。

展望未来，我计划以以下方式改变我对重点领域的态度

  • 我们将有一到也许两个重点领域，具体取决于未知数的数量和我们的“带宽”。
  • 我将承认，只要我选择担任“仁慈的独裁者”的角色，重点领域需要我个人的直接投资。如果我没有积极努力地帮助人们克服障碍，使其能够继续前进，那么它就不能成为重点领域（根据定义）。
  • 如果由于任何原因，当我们发现新信息时，我们的重点需要改变，我将通过“重点领域变更”立即将其报告出来。

旧渲染器的中间级别 API #

旧的渲染器（Bevy 0.6 之前）做了一些正确的事情

  • 用户友好的ECS驱动的自定义着色器高级 API，非常少量的样板代码。例如，查看这个 "自定义着色器材质"应用程序
  • 一个模块化的“低级”渲染图，使开发人员能够轻松地将新功能插入渲染管道，而无需集中式顶层编排，或者创建全新的渲染管道。

但是，渲染图和高级 API 之间的中间级别 API 非常复杂，充满了抽象和术语，在某些情况下，效率低下。结果，这使得系统难以理解，新的开发人员难以理解它。我认为这主要归因于专注于使高级和低级 API 具有“良好的 UX”，并将中间级别 API 视为“粘合剂”。

我认为旧的中间级别 API 设计是一个相当昂贵的“错误”。新的渲染器将解决这些问题，主要是通过扁平化抽象和澄清数据流。我对此真的很兴奋。我想我们应该从错误中吸取教训。事情很少能在一开始就完美无缺。

问题和拉取请求响应时间 #

我尤其不满意合并 PR 所花费的时间，尤其是那些进行“重大”更改的 PR。这其中一部分是故意将 PR 放置在尚未准备好投入时间和脑力进行研究的主题区域，但很大一部分只是带宽/注意力问题。我一直与其他核心贡献者合作构建系统来简化此过程

  • 将合并权限授予一小部分值得信赖且能力强的用户。目前，这仅仅是 @mockersf，其范围仅限于“无争议”的 PR。
  • 一个“社区审查系统”，当社区有足够的批准时，会将 PR 强制进入我的“高优先级审查队列”。

我认为我们还没有看到这些系统发挥其全部能力，因为其中一些是新的，我们目前正在优先准备 Bevy 0.6 版本。每年合并数千个 PR 确实是值得自豪的事情，但拉取请求的数量只会随着时间的推移而增加。我们需要能够适应这种情况。

填补细分市场 #

在开发的这个阶段，Bevy 能够构建大多数类型的应用程序（2D、3D、以 UI 为中心等）。但是，我们还没有在这些细分市场中任何一个“具有竞争力”。例如，对于 2D 工作流程，我们的贴图集非常有限，我们缺少像精灵批处理这样的重要优化，而且我们没有用于构建关卡的视觉编辑器。这些东西可以作为第三方插件构建（事实上，它们已经被构建出来了），但 Bevy 需要提供开箱即用的第一类支持。在过去的一年里，我们“走向了广泛”，构建了基础设施来支持每个细分市场的开发，但展望未来，我希望看到我们专注于在特定细分市场中脱颖而出。这在很大程度上只是一个时间问题，因为我们正在构建功能。但我们需要始终意识到这一点：如果我们不能成为至少填补一个细分市场的最佳选择，那么这一切都没有意义。

我没有画足够的鸟 #

从未想过我会说这些话，但事实就是这样。我有很多“自定义 Bevy 鸟头像”赞助奖励要为人们制作。有些人已经等了很久了。说实话，我后悔将其添加为奖励等级，因为它从我真正构建 Bevy 的时间中抽走了时间（我显然已经优先考虑构建 Bevy，而不是制作这些头像）。我可能在不久的将来会取消这个奖励等级，但我保证我会完成已经在这个等级赞助我的所有人的积压任务。对于延迟，我深感抱歉。

Bevy 的下一年 #

next year

以下是我的明年计划

  • Bevy 0.6：在不久的将来，我们将发布 Bevy 0.6，其中将包括一个全新的渲染器，它更加高效、更强大、更容易理解，并且更具可扩展性。它借鉴了 Bungie / Destiny 和 rafx 架构。这将包括所有现有渲染器功能的移植，以及阴影、视口、材质批处理和改进的自定义着色器等功能的初始实现。
  • 资产管道的成熟：资产管道将获得资产预处理、导入配置和更好的依赖关系管理。这将有助于渲染器和场景的改进。
  • 下一代 Bevy UI：我们将构建一个新的 UI 框架，它将利用 Bevy ECS 功能，在必要时添加新功能（例如“响应性”），并使 UI 开发工作流程更加令人愉快。
  • Bevy 编辑器：我们将开始构建 Bevy 编辑器，它将是一个基于“下一代 Bevy UI”的 Bevy 应用程序。我们将从场景编辑功能开始，然后从那里开始构建。
  • 场景改进：场景将支持嵌套场景、更好的场景文件格式和属性重载
  • 新的 Bevy 书籍：当前的 Bevy 书籍自首次发布以来变化不大，涵盖的内容超出了基本的 Bevy ECS 用法。新书籍已经在制作中，它将成为 Bevy 所有方面的更全面的指南。
  • 新的 Bevy ECS 功能：我们可能会获得某种形式的“响应式 ECS”，实体关系索引，以及更细粒度且功能更强大的并行系统调度
  • 动画：我们将构建一个统一的动画系统，使 2D 和 3D 动画更加容易，并与 Bevy 编辑器自然集成
  • 2D 功能：精灵批处理、更多贴图集功能、图层、Bevy 编辑器中的视觉/交互式工具
  • 3D 功能：骨骼动画（与动画系统集成）、可配置/灵活/美观的阴影、至少一种形式的全局照明、更多 PBR 属性，以及 Bevy 编辑器中的视觉/交互式工具
  • Bevy 游戏黑客马拉松：我们将举办至少一次官方的 Bevy 游戏黑客马拉松，以推广 Bevy，对 API 进行测试，并为用户提供更多可以借鉴的示例。

我比较有信心，我们可以实现这些目标。我们已经拥有许多上述功能的工作原型，并且在许多领域已经开始达成共识。

以下是对 Bevy 在接下来一年的发展轨迹的一些预测

  • 我预计 Bevy 0.6 版本的发布将立即带来内置和第三方渲染器高级功能的增加（由于新的渲染器）。
  • 在相对较短的时间内，我预计会看到更多人选择 Bevy 作为其首选的 2D 应用程序选择，这得益于改进的工具和性能。
  • 到今年年底，我预计人们将开始认真对待我们用于 3D 应用程序，这得益于一套强大的内置“高级渲染功能”和我们极具竞争力的渲染器模块化。
  • 我预计获得报酬开发 Bevy Engine、构建 Bevy 应用程序和制作 Bevy 内容的人数会大幅增加。
  • 如果“下一代 Bevy UI”的努力取得成功，那些想要构建“Rust GUI 应用程序”的人将开始选择 Bevy。
  • 我们将走出“Rust 游戏开发爱好者”的圈子。到今年年底，Bevy 将在更广泛的游戏开发社区中被更频繁地提及，与 Unity、Unreal 和 Godot 的讨论并驾齐驱。目前还不是直接的竞争对手，但对于那些（1）想要新事物/创新/与众不同，以及（2）愿意在较小的功能集和略微不稳定的 API 附近工作的人来说，它是一个可行的替代方案。

如果这些内容激发了你的兴趣，我们非常欢迎你的帮助！查看我们的代码，在 GitHub 上开始参与 Bevy 社区，并考虑 赞助我的工作，以确保我能继续构建和领导这个雄心勃勃的项目。

我期待着与你们所有人共度接下来的一年！

- @cart