Rust游戏开发2020生态圈展望 调查结果(译)
Rust Game Development - Ecosystem Survey
2020 年 2 月 6 日
去年 8 月，我们对 Rust gamedev 生态圈进行了一次调查。在不幸的耽搁之后，我们终于可以交出结果了。我们收到了高达 403 个回复！这些宝贵的反馈将为工作组 2020 年的路线图提供动力。
- 爱好者 or 开发者?
- 游戏开发你会用 Rust 吗?
- 如今, 系在 Rust 游戏开发与你之间最亮眼的红线是什么?
爱好者 or 开发者?
在 400 名受访者中，有 3/4 被确定为爱好者(Hobbyist)。还应注意的是，*专业人士(Professionals)*这个极其重要部分，更准确地说是“有抱负的专业人士”，他们承担了他们的第一个游戏开发风险。依然让 Rust 游戏开发引起了大量的商业兴趣！
游戏开发你会用 Rust 吗?
在专业人士中，只有 1/4 的人说他们目前在游戏中使用 Rust。这意味着，目前在 gamedev 中使用 Rust 的 200 名受访者大多是爱好者。这并不奇怪，因为大多数专业人士都无法承担成为早期使用者的风险。赞美推动现状的所有爱好者，对少数在产品中使用 Rust 的制厂点赞，而这些制厂早在大多数行业同行"闻到这种气味"之前, 就已经开始使用 Rust 了。
对于随后的自由形式的回答，使用基本的情绪分析，将 400 个回答提炼成可消化的形式。标题旁边的（#）数字大致表示该主题出现的次数。把它想象成主题的信号强度。
如今, 挡在 Rust 游戏开发与你之间的最大阻力是什么?
专业人士和业余爱好者的关注重点基本相同。最大的区别是：
-
爱好者们要求”生态圈成熟度“是其他的 2 倍。
-
爱好者更关心移动/网络支持
-
专业人士更关心主机支持
-
专业人员更关心 C++互操作
Ecosystem 成熟 (114)
从在太空中玩我知道用 Rust 做游戏是可能的。然而在生态圈中，我最大的阻力是[缺乏]案例研究和演示。
与 C++相比，Rust 仍然是一个危险的选择。
仍然感觉像一个新的社区。总有风险与此相关 - 语言是否朝着某个方向有很大的变化-是否支持 drop。我对底层（嵌入式/操作系统）开发的支持感到鼓舞，这意味着, 核心特性集仍然是健壮的。
许多未完成的，未维护的箱子。总是在搅来搅去。
很多常见的需求还没有“开箱即用”。
迭代用时 (68)
编译时，没有运行时反射，更新树中的深层依赖关系很困难。
我认为迭代用时太长了，因为编译的时间，[缺乏]热重载工具等。
迭代用时（特别是在原型设计时）。当我知道我很快就会重写某些内容时, 其中包括编译时，也包括对 lifetimes 的整理，在编译时, 这种“预先准备”借用检查器运行的努力对大多数任务都是有用的，但当我想快速尝试某些内容时，这可能就拖我后腿了，在这方面，GC(垃圾回收)’d 语言有个 imo 优势。
由于“fighting the compiler(‘天天’编译器)”，在 Rust 中, 原型设计似乎不容易.
文档 (43)
没有足够的文档度过初级阶段
缺少 gamedev libs 的示例。
文档通常是高阶的或示例的，但很少两者都有。很少有现实世界的例子可以借鉴。
缺乏完整功能的引擎 (35)
缺乏一个基于数据与脚本的引擎，比如虚幻引擎或 Unity，意味着即使是小项目，最终也会是“自己订自己的快餐单(引擎)”。
缺少图形编辑器，游戏的无摩擦原型
Rust 学习曲线 / 入门到小众语言 (29)
这种语言比我所知道的任何其他主流语言都有更高的前期认知负荷，主要是由于借用检查器。很难深入并逃脱，这使得它成为一个特别难以叫卖的游戏原型。
我知道这是一种不太常见的语言，所以作为一家公司，我必须让我的员工学会 Rust，然后才能开始工作。
Rust 人员可能很难雇佣，而雇佣一个不懂 Rust 的人来从事 Rust 工作会有一个爬梯期。
IDE/RLS story (28)
相比于 VisualStudio 与 C++ 或 C 语言，IDE 中的工具是受限的。
显然缺乏合适的 IDE（比如现成的 Cargo 集成 和 working 调试器 —— 是的，我测试了 Visual Studio Code，它非常慢，建议不好，运行、检查和构建的最快方法是使用终端 —— 而不是 IDE）-我想说 QT Creator 或 visualstudio 之类的东西会很棒
关于调试，行业标准是 Visual Studio（或者我知道的是 visualstudio），因为它是非常好的 IDE 和工具，而且，很多用户非常习惯这种工具，看起来 Rust 缺少了一些工具。
rust-analyzer 还很不完善，但这是唯一对我有用的东西.
IDE 的调试支持较差。主要是 visual studio。
无法正确调试，例如, 哈希映射绝对不可调试。不确定它是如何工作的（而不是 C++）。
调试模式太慢，通常需要为 dev profile 设置
opt-level=1或 2.
GUI 工具 (23)
作为一个工具开发人员，一个主要的缺点是目前缺乏可靠的 GUI 框架（我们在 Visual Studio 中使用 WPF+C）。
游戏主机 (13)
没有官方对主机开发的支持，这使得 Rust 在很多专业工作中都很难存活。
Rust 在索尼或微软的游戏机上不受官方支持。
目前还不能认真考虑 Rust，因为它没有 PS4 SDK 的支持。虽然还有其他的考虑（Studio 文化，与现有系统的集成等），索尼的官方支持是一个要求，这样 Rust 才可以在 PS4 游戏中使用。
Web/mobile 支持 (14)
Allocators (10)
C++ interop (7)
我们的代码，以及任何我们可以授权的中间件/引擎，都是 C++的。使用 Rust 和 C++是痛苦的，对现有技术, 改写成纯粹的 Rust 将是非常昂贵的。
测试和太多东西是与 C 联系的。
而且，还没有专业的游戏引擎（UE4，Unity）与 Rust 集成。
未知的兼容性
缺乏一个简单的路径，使 Rust 与 C++ 互通有无。我现在看到的唯一可信任的方法是通过手动 C 包装器，这是一种容易出错且耗时的方法。
如今, 系在 Rust 游戏开发与你之间最亮眼的红线是什么?
安全 (100)
强类型系统允许轻松执行, 一些性能和安全最佳实践
多线程安全
消除数据竞争, 大大提高了多线程代码的可靠性。
安全并发
性能 (89)
出色的性能和编译时检验
性能和可靠性
并发性
社区 (69)
生态圈中充满了热情和聪明的人，他们非常重视高质量的软件
一个真正热情的社区，有着伟大的目标和追求目标的勇气
集体努力“构建正确的事情”和“把事情构建正确”
Cargo (57)
能够一点一点地把库拆下来，让他们马上用你的东西来建造，is great.
生态圈 (50)
一个成熟的 Rust 生态圈将会比 一个成熟的 C++生态圈，（希望！）具有更底的门槛, 而不放弃性能。
WASM (web) 支持 (20)
没有垃圾回收机制 (8)
ECS; 数据驱动; 面向数据 (8)
跨平台 (5)
C 互操作 (3)
置顶讨论
这种语言比其他主流语言具有更高的前期认知负荷。这意味着，在一个已建立的、更大的项目（也许幕后有个团队），与 C++相比，生产率是惊人的！表达强而安全的接口要容易得多，而这些接口会使 bug 更难浸入。且在网络上大放异彩，网络代码是需要 100%安全和‘对坏淫的抵制’！我当前的游戏服务器代码有 0 个 unwrapps/panics/expects，所以我就知道它不会崩溃… 我希望我能在 C++中有这种感觉。相反，C++很容易激发出 20%的崩溃率和性能下降，并且需要 2 周的时间来敲击成形，在 2 周之后，它看起来却像 Rust 代码。不幸的是，由于了解 gamedev 行业的管理文化，Rust 面临着一条极其艰难的道路。以我的经验，gamedev 被极端的短期（比如，1 个月）所困扰，自然导致了崩溃和糟糕的折中技术。Rust 做了很多选择，推迟了那个决定命运的“demo day with the execs”，因为它迫使你正确做事。但很少有人能解释为什么这是对行业有价值的，和倾听。
我喜欢 Rust！•它非常适合“有 API 头脑”的系统程序员 • 随着越来越多的生产用户的到来，一切都会变得非常好非常快 • 跨平台比以往任何时候都容易 • 重构非常有趣• proc 宏非常酷非常有用 • serde 非常有用 • 真的有很多很棒的箱子 • 我知道我们最终会在一起的！
我们对程序生成和人工智能的数据驱动游戏特别感兴趣。Rust 似乎非常适合这种计算密集型的工作。
由于大多数游戏开发人员都是修补工，而不是工程师或科学家，整个行业都饱受代码质量差、缺乏体系结构和糟糕的代码设计的困扰。未定义的行为、nullptr 异常、释放后使用、多线程问题等都是经常出现的问题。Rust 最大的积极意义在于它解决了所有这些问题，而不需要改变游戏背后的人。这就是为什么我这么相信它 :）。同样值得注意的是，模块系统和箱子在当今非常重要，因为数百万行代码的庞大而僵化的代码库真的是一个地狱般的工作。
你怎么看在接下来的 3-6 月, game-dev 工作组的优先事项?
Documentation (107)
- 更好地参与 rust gamedev
- 最佳做法的更好地解释
- 如何开始
- 经验丰富 gamedevs 的 Rust
- 现在能工作是什么?
- 示例游戏
- 常见 gamedev 问题的标准实践
- 如何制作窗口
- 如何制作图形
- 如何制作 ECS
- 基础库的更多文档
跨平台支持 (59)
- 下一代游戏机采用 Rust 的讨论室。
- 有关主机支持的更清晰信息。
- 启动一个能够获取和维护主机 NDAs 的实体，以维持对主机支持而创建的官方 rust 版本。这是一个巨大的痛苦，但其他开源项目也会这样做，这对社区来说是一件了不起的事情。
- Wasm/web 支持（爱好者较多）
- 在那些专有的 SDKs 和 APIs 允许的范围内，清晰地描绘出游戏主机方面的发展道路。
- 移动端支持
- 更容易包装
- 跨平台编译
- XR（AR/VR）
生态圈提议 & 协作 (51)
- 发展行业内的联系，以便工作组可以成为行业和 OSS 开发人员之间的联络人。通过邀请和参与行业，生态圈可以增长，并可能得到支持（以 PRs，开源的现有工具，或为 OSS 开发人员提供资金支持形式）。
- 鼓励和促进现有工具的协作。
- 库“打上鸡血”
- 更多像这样的调研
- 生态圈路线图
- 转发/安利
- 游戏比拼
- 更好地了解工作组的当前议程
- 想出一些方法来解锁基础项目, 一旦被卡住
- 识别正在进行的问题，并为 Rust 语言提出, 与游戏开发相关的新问题。（例如，调试 Rust 非常慢，因此我们需要好的方法来控制哪些是优化的，哪些不是优化的。）
- 尽可能寻求解决交叉问题的机会。最近对’原窗口控制’的研究, 和对是否可以/应该在数学库上收敛的评估都是很好的例子。
头等游戏引擎/框架 (46)
- 简单的二维游戏引擎
- 基本编辑器工作流
- 像 SDL 一样
- Unity/ Unreal 的竞争对手
图形库 (33)
- 提高图形编程的可访问性
功能库 (27)
- 用户界面库
- 窗口
- 音频
- 图性
- “标准箱子”合集，并提供某种形式的工作组支持
- 推动稳定标准
更快的迭代用时 (17)
- Hot 代码重加载
- 兼并脚本
- 更快的编译时间
- 进展更多库
现有工作链的集成 (14)
- C/C++
- Xcode、Android studio、Visual studio、Blender
- Unity/Unreal/Godot
自定义分配 (10)
调试支持和 IDE 集成 (5)
库与库之间的"眉来眼去(互操作性)" (5)
你可以说说哪些库是你想感谢的或是感兴趣的?
为了好玩，我们让受访者说出他们感谢的库或项目。在这项调查结束后的 6 个月里，有相当多的新来者正在崛起.，如果我们今天再问一次，他们可能会在这里表现得更为突出。请放心，会有更多的调查。
多亏了调查对象和所有不懈努力的人们，Rust 来到了游戏开发语言以及生态圈发展的第一层。
Rust Game Development Working Group
了解 Rust 游戏开发工作组的最新进展和最新进展。