The State of Game Development in Rust

Game Development is one of the fields in which Rust can gain a lot of traction. As a modern compiled language with performances comparable to C++, Rust can finally free us from the tyranny of C++ bloated feature set, hard-to-link dependencies, and header/implementation file double-madness (I am obviously exaggerating, btw).

However, if this freedom arrive, it will be a very slow process. To make it slower, the feature of memory safety in videogames is not a huge priority compared to the ability to quickly prototype. The borrow-checker and the strict compiler are an obstacle in this regard. On the other hand, memory safety also means easier multi-threading. And this is sweet!

Fortunately, the annoyances of borrow-checker will get less in the way while people becomes more confident with the language, and while tooling gets better and better. I am confident we may see Rust carve out its space in this domain.

But this is the future. What about now?

State of the Ecosystem

Let's look at the current ecosystem and let's see what the community has to offer.

Low-Level Graphical Libraries

Game are made of graphic. To make graphic you need graphical libraries. The most core library I am aware of is GFX. GFX is a low-level abstraction layer over platform specific graphical interfaces (OpenGL, Metal, Vulkan) and offers some handy wrapper over windows backend (glutin the Rust one, or wrapper around Vulkan system, GLFW and more).

I put this at the core because it is the most developed graphical library on Rust right now and it is at the core of more complete engines (see later). I can go deeper talking about the very low-level stuff. But it is unnecessary.

The problem is that GFX version is 0.17 and it is rapidly evolving. This is a common factor of many gamedev library on Rust. It is expected, but I want to be clear.

More Complete Game Engine

In the Rust ecosystem there are three main (more) complete solutions for game developers. They are game engines (or, at least, they try), they include graphical rendering (of course), but also scene management, game loops, audio, inputs, assets management, and more.

In Rust, there are actually 3 main frameworks like that:

Piston

Piston is the oldest game engine tentative of the Rust community. As the oldest, it is also the most stable and the one with the best documentation (best among the others, not exceptional). However, many people find Piston confusing and hard to use. Why? Because it is super-modular by design. Each module of Piston is a separate crate. Sometimes it is even hard to understand which module to load for achieving a certain goal.

Amethyst

Amethyst is a more recent game engine/framework with a more simple approach, inspired by commercial monolithic game engines. It is shipped as a single crate containing everything you need to get started. The problem of Amethyst is that it is quickly evolving. It is just at version 0.6 and it is so fast changing that the official documentation is totally outdated. If you are looking for an open source game engine to contribute to, Amethyst is looking for a lot of people who can write examples and keep documentation up to date.

GGEZ

GGEZ is a simple 2D game engine inspired by LÖVE. It is explicitly designed to provide a super-easy way to write simple 2D games in game jams or in hobby projects. Even GGEZ is very new and changes quickly. But the limited scope, and the design simplicity makes it a better bullet to bite.

Other Libraries and Utilities

There are some other interesting game-development related libraries.

noise-rs / a noise generator. Useful for many procedural content generation stuff.
rlua / High level bindings between Rust and Lua
sfxr / Reimplementation of DrPetter's "sfxr" sound effect generator as a Rust library
I will reserve here some space to update this list.

Developer Opinion

One of the most real-world opinion on Rust for game development comes from this AMA-like post on /r/rust from Catherine West of Chucklefish (official website). It is a quite enthusiastic description of the game studio experience with Rust. Even if they are mostly focused on 2D It is a huge thing for a young system language like Rust. At the question "do you have any regrets yet?" she answered:

Regarding choosing rust specifically, not too much honestly. I was pleasantly surprised once I was done with the portability side of things with how much effort it actually was. If anything, at least for me personally, if I was the technical lead of another game project the decision wouldn't be between rust and C++, it would be more between using rust and using an existing engine, and then using whatever language had the least friction with that engine. Obviously if Chucklefish branches out and does some work in 3D, then the equation is going to change haha.

This is super nice. But note that it comes from guys that are very strong in doing 2D custom engines from scratch. This allows them to just skip the documentation and instability problems of the game frameworks I listed above.

For what 3D is concerned, there is another quite enthusiastic opinion. It comes from the developers of SHAR. You can find their “postmortem” here.

First of all - Rust is an amazing language for game development, maybe it is the best one.
We have Rust stable on build machine and nightly for development. Nightly is used only for compiler intrinsics for a profiler. There were problems with nightly one or two times, but simple downgrades to previous nightly solved the problem. The main issue was compilation time - our biggest crate compiled for about 3 minutes. But with incremental compilation, it’s almost fixed. It still takes minutes sometimes, but often - only a few seconds. I am using incremental compilation from very early testing versions - and I had only one time when it generated invalid code.
During this year I had only one (ONE!!) bug in the code that was really hard to find. The entire program behaved really strange, crashing sometimes with strange backtrace inside a hashmap implementation. This bug was found within a day, I just double-triple-etc checked all usages of “unsafe” keyword in the codebase (there were 3 times). And yes, the bug was in one of those unsafes.

Conclusions

The state of GameDevlopment for Rust is promising and encouraging but it is actually very early in its development. For a language so recent that it is trying to attack a the C++ domain in the game development field, we can see a lot of great early successes.

However, this is yet a direction for low-level game developers that are not scared of doing a game engine from scratch. The pre-built solutions are still very unstable. They are just not there, yet. They still require a lot of “dirty work”.

Many of the problems we have seen abovewill disappear with the maturation of the general language. A proper IDE and better tooling will improve Rust in general and, as a result, the life of game developers. Other problems, as I said before, will become less severe when the game developers will become more aware of limitations and strength of Rust.

Finally, the remaining difficulties will be put away with the stabilization of game development libraries. Actually, there is no stable game development crates. This can only get better with time.

It will be this year? I think not. But we are getting there.