新闻
捐赠 爱心图标 GitHub 代码库

Bevy 的扩展

发布于 2020 年 8 月 19 日 作者 Carter Anderson ( 一个戴着猫耳朵挥舞着触手的卡通人物的剪影，也就是 GitHub 的吉祥物和标志 @cart 一只灰色飞鸟的矢量图；X（以前是 Twitter）的旧标志 @cart_cart 一个在圆角矩形中指向右边的三角形；Youtube 的标志 cartdev )

首先，我想花点时间强调一下过去一周的疯狂景象。 Bevy 仅仅发布了一周，我们已经取得了一些重大的里程碑

/r/rust 历史上最受欢迎的第 3 个帖子

Hacker News 上排名第二

2200 个 GitHub 星标

26 位贡献者

644 个 Discord 用户

Bevy 如何才能在如此规模下运作？ #

我做梦也没想到会有一个社区如此迅速且强大地出现。显然，Bevy 项目引起了人们的共鸣！这很棒，但也带来了一些有趣的挑战，我原本以为我有更多时间来解决这些挑战

  • 我是瓶颈：现在，只有我有权合并代码。在人们熟悉代码库并建立信任之前，这一点无法改变。
  • 每个人都是新手：每个人都是代码库的新手，因此更改需要仔细审查，开发人员需要很多指导。
  • 没有结构：我们没有组织结构或明确的开发流程。

在我们试图解决这些问题之前，我认为我们需要问问自己

是什么让 Bevy "好" 的？ #

我认为这实际上是一个相对简单的答案。我认为它归结为

  1. 向最好的学习：我彻底回顾了所有现有的选项，从中学到了所有我能学到的东西，并根据这些知识构建了一些新东西，或者进行了迭代改进
  2. 实验自由：我不受稳定性保证、每次都要做出“正确”选择的压力或截止日期的限制
  3. 专注：我能够全职工作在 Bevy 上，没有任何干扰，持续了大约 5 个月

我们如何在 Bevy 社区的全新规模下复制这个过程？我个人如何才能在职位从“单人隐形登月项目架构师”变为“首席架构师”/“项目经理”/“社区经理”的项目中，拥有数千名开发者社区，复制这个过程？

计划 #

我认为现在不是沉迷于复杂组织结构或 RFC 过程的时候。最终，我们将需要这些工具，但我认为我们还没有到那个阶段。相反，我会尝试重新创造我在过去 5 个月里一直运用的环境

BDFALAICMI #

我计划成为一个Benevolent Dictator For As Long As I Can Manage It（仁慈的独裁者，只要我能管理）。我将亲自审查每个被合并的 PR 和每个做出的设计决策。最终（如果我们做对了），这将变得不可能，但我们还没有到那个阶段。随着我对贡献者的信任建立起来，以及项目的扩展，我最终会开始授权。但我会始终倾向于“小而专注”。我的一般技能和偏好是全职软件开发人员/架构师，但我已经接受了，我需要在软件开发和项目和社区管理之间取得平衡。我的短期目标是减少我们大量的 Issue 和 PR 积压问题 :)

专注 专注 专注 #

我们还有很长的路要走。构建一个引擎就像在游戏中升级技能树。某些功能在构建其前身之前无法（或不应该）构建。Bevy 编辑器就是一个例子。在我们开始构建编辑器之前，我们需要确保 Bevy UI 和 Bevy 场景处于良好状态。我只是一个人。我的带宽有限，只能用于构建设计和审查提案，所以我不能浪费精力去构建编辑器。

在任何给定时间，Bevy 将有 3 个关注领域。这些领域将优先获得我的时间，我将尽最大努力将贡献者引导到这些领域。这并不意味着其他人不能自由探索他们感兴趣的其他领域。只是不要指望能很快合并它们。理想情况下，你正在构建一个独立的插件，该插件不需要直接合并到 Bevy 代码库中。

快速且灵活 #

我不想陷入“设计地狱”。我们可以争论多年来构建 PBR 渲染器的最佳方法。但如果没有实现和硬数据，很难确定在实践中什么是最好的。我想要看到代码。生产就绪不是一个功能。一个好主意很好，但如果没有实现，对我来说就不真实。我们需要有能力的人来实现好想法。我们尝试不同方法的速度越快越好。目前，一般流程将是

  1. 确定一个关注领域，并传达 Bevy 在该领域应该采取的总体方向
  2. 鼓励贡献者创建自己的“原型”板条箱。在某些情况下，我将创建自己的板条箱。Bevy 项目将提供这些板条箱的集中列表，这将有助于发现它们，并帮助集中工作。如果你创建了一个板条箱，请使用bevy_prototype_XXX格式作为板条箱名称，以尊重bevy_XXX命名空间。这种方法将允许我们“扩展”而不必过多地进行流程或集中化。
  3. 一旦我们有了可工作的原型，我们就可以开始尝试达成共识。我们可以在此阶段慢慢来。原型功能已经存在于需要它们的人那里。过早合并某个东西的成本很高。合并某个东西意味着我们已经选择了一条路径，并且致力于它。在那时，实验对于 Bevy 板条箱使用者来说变得昂贵且痛苦。目前，我将对合并的内容以及合并的时间拥有最终决定权。社区将说服我走上一条特定路径，但请相信我，我很讲道理！在有必要的情况下，我会听取主题专家的意见。

协作 #

Bevy 吸引了许多流行的 Rust 项目的关注。 我们目前正在讨论与 Amethyst Engine 协作的最佳方法。我也与许多其他 Rust 项目负责人讨论了如何使 Bevy 成为一个优秀的生态系统参与者。我们应该尽可能地构建共同的基础。如果你知道潜在的协作领域，请联系我（Twitter 私信或 Discord）。

Bevy 目前的关注领域 #

以下列出了 Bevy 目前的关注领域。我将把我的注意力以及尝试将所有人的注意力都集中在这些领域上。没有截止日期。我们将花尽可能长的时间来把它们做好。我会尽最大努力（全职）来确保我们能够快速取得进展

编辑器就绪的 UI #

在我们开始构建 Bevy 编辑器之前，我们需要一个可靠的 UI 实现。Bevy UI 已经有了不错的“弹性盒”布局，我们已经对按钮和交互事件进行了首次尝试。但如果我们要找到“正确”的模式和范式，Bevy UI 仍然需要进行更多实验。编辑器就绪的 UI 具有以下要求

  • 拥抱 Bevy 架构：Bevy ECS、Bevy 场景、Bevy 资产、Bevy 事件
  • 一个 Canvas 风格的 API，用于使用形状和抗锯齿曲线绘制小部件
  • 定义一种一致的方式来实现小部件
  • 一组核心小部件：按钮、输入、可调整大小的面板等
  • 主题化
  • “交互”和“焦点”事件
  • 翻译友好。我们不能以英语为中心。

建议其他 UI 框架或堆栈不在讨论范围内。Bevy 编辑器将构建在 Bevy UI 之上。有关我的理由，请参阅 Introducing Bevy 博客文章。

基于物理的渲染 (PBR) #

PBR 是一种标准化的方式，用于在 3D 中逼真地渲染。人们对这一领域既有浓厚的兴趣，也有大量脑力，因此现在构建 PBR 是有意义的。该关注领域具有以下（最低）要求

  • PBR 着色器（这意味着 hdr）
  • 泛光（用于传达 hdr）
  • 阴影（迫使我们构建一个真正的“管道”）
  • 对当前的中级渲染抽象进行实战测试，并在必要时对其进行重构

场景 #

Bevy 场景目前完成了我们想要的大部分工作，但在它们成为 Bevy 状态管理的基础之前，还需要做一些工作。该关注领域也是 Bevy 编辑器的一个要求。

  • 资产管理：内联资产、资产依赖项、从磁盘加载时的稳定 ID
  • 更好的场景格式：改进场景文件的可读性和人体工程学，使它们易于阅读和手动组合。我们的目标是实现与这类似的东西。
  • 启用/禁用系统：场景应该能够在添加/删除时切换其所需的系统。

想帮忙吗？ #

如果你想和我们一起踏上这段疯狂的旅程，以下是一些你可以帮助我们的方法

  1. 为原型插件做出贡献：开始构建新的原型 Bevy 插件，并为其他人正在开发的插件做出贡献。理想情况下，这些插件应该位于上述的关注领域内。在这个阶段，我们正在寻找能够展示新想法的快速原型。如果你想在一个给定的关注领域内开始一个项目，请
    • 阅读 GitHub 上相应的focus-area issue
    • 查找该 issue 中的当前项目，并找出潜在的协作领域。
    • 如果你找不到现有的项目，并且你想开始一个项目，请设置一个新的板条箱/代码库，并在“focus-area” issue 中链接到它。我们将维护一个位于主题顶部活跃项目的索引。当工作看起来过于重复时，我们也会鼓励协作。
  2. 帮助 Bevy 社区：如果您有能力，请帮助我们解决 Bevy Issue Tracker 上的问题，审查 pull requests，并在 #help channel of our Discord 上提供帮助。跟上这里庞大的工作量确实是一个挑战，所以任何帮助都非常非常感谢。
  3. 帮助我实现全职开发的可持续性：我需要您的帮助来使 Bevy 开发可持续！五个月前，我辞去了微软舒适的资深软件工程师职位，全职投入 Bevy 开发。我现在用自己的积蓄支付房租和生活费。我无法长期维持这种状态，虽然我很想这样做。我们已经达到了可持续开发的 37%，而且这仅仅是两天！

期待在 Bevy 社区 见到您！