离开 Rust 游戏开发三年后：一位开发者的反思

原文来源：LogLog Games — 一位独立游戏开发者分享他用 Rust 开发游戏三年后的反思，包括学习曲线、编译时间、生态缺口和最终转向其他语言的原因。

Rust 在系统编程领域的风头正劲，但游戏开发是一个特殊的领域。一位用 Rust 做了三年独立游戏的开发者最近分享了他的经历——不是成功案例，而是为什么选择离开。他的反思对考虑用 Rust 做游戏的人很有参考价值。

初识 Rust 的兴奋

这位开发者最初被 Rust 吸引是因为它的承诺：C++ 级别的性能，但没有内存错误。对于游戏开发来说，这听起来很完美——性能是关键，而内存错误（use-after-free、buffer overflow）是 C++ 游戏中最难调试的 bug。

Rust 的所有权系统确实消除了整类错误。编译器在编译期就保证了内存安全，运行时不需要 GC，性能接近裸机。这些特性在理论上非常适合游戏引擎的开发。

编译时间

Rust 的编译时间比 C++ 更长。小型项目可能感觉不到，但游戏引擎规模的项目，完整编译可能需要 10-20 分钟。增量编译好一些，但某些修改（如修改 trait 定义）会触发大量重新编译。

对于游戏开发这种需要频繁迭代的工作流，编译时间直接影响开发效率。改一行代码等几分钟才能看到效果，累积起来的时间损失很可观。

学习曲线

Rust 的所有权、生命周期、借用检查器——这些概念对系统编程是合理的，但对游戏开发中的常见模式造成了摩擦。

游戏开发大量使用回调、事件系统和动态分发。Rust 的所有权模型让这些模式变得复杂。一个简单的观察者模式，在 Rust 中可能需要 Arc、Mutex、Weak 引用的组合，而在 C# 或 GDScript 中就是直接的引用。

生态缺口

游戏开发需要完整的工具链：引擎、编辑器、资源管线、调试工具、性能分析器。Unity 和 Unreal 提供了这些全套工具，而 Rust 游戏生态还在建设中。

Bevy 是 Rust 中最成熟的游戏引擎，但相比 Unity 仍然缺少很多功能：可视化编辑器不够完善、资源导入工具链不完整、第三方插件生态很小。对于独立开发者来说，这意味着很多基础功能需要自研。

迭代速度

游戏开发的核心是快速原型和迭代。想法需要快速验证，不好的设计需要快速抛弃。Rust 的严格类型系统和编译器检查虽然减少了运行时错误，但也增加了实验成本。

在 GDScript 或 Lua 中，改几行代码立刻运行看效果。在 Rust 中，改几行代码可能需要解决编译器错误、调整所有权、更新类型签名——这些对于探索性开发是阻碍。

这位开发者最终转向了 Godot（GDScript）和 Zig。他的体验对比：

他发现，对于独立游戏开发，"足够好"的性能比"极致"的性能更有价值。Godot 的性能对于大多数 2D 游戏和中等复杂度 3D 游戏完全够用，而开发效率的提升直接转化为更多时间打磨玩法。

这并不意味着 Rust 不适合游戏开发。而是说，Rust 的定位需要更精确。

Rust 适合的场景：

Rust 不适合的场景：

如果你正在考虑用 Rust 做游戏，这位开发者的建议是：

先评估项目类型。 如果是性能敏感的 3D 游戏或自定义引擎，Rust 值得考虑。如果是 2D 独立游戏或需要快速迭代的项目，Unity/Godot 更合适。

评估团队经验。 如果团队没有 Rust 背景，学习成本会显著影响开发进度。独立开发者尤其需要考虑时间成本。

不要忽视工具链。 语言特性只是开发体验的一部分，编辑器、调试器、资源管线的完整度同样重要。

考虑混合方案。 用 Rust 写性能关键的模块，用其他语言写游戏逻辑和玩法代码。Bevy 支持这种混合模式，Unity 也可以通过 Native Plugin 实现。

Rust 是一门优秀的语言，但优秀不等于适合所有场景。游戏开发对迭代速度和工具链完整度的要求，与 Rust 的设计优先级（安全、性能、正确性）并不完全重合。

这位开发者的经历不是 Rust 的失败案例，而是技术选型中"合适比先进更重要"的又一次验证。对于游戏开发，Godot、Unity、Unreal 仍然是更成熟的选择，Rust 更适合作为特定模块的优化手段，而不是整个项目的基础。