title = "Rust Game Development - Ecosystem Survey"

draft = true

In August last year, we conducted a survey for the Rust gamedev ecosystem. After an unfortunate delay, we can finally present the results. We received a whopping 403 responses!



For the free-form answers that follow, a basic sentiment analysis was used to distill 400 replies into digestible form. The "III" signs underneath a heading indicate *roughly* the number of times that topic came up. Think of it as the **signal strength** of a given topic.

Priorities for professionals and hobbyists are largely the same. The biggest differences were:

- Hobbyists call for ecosystem maturity 2x more than anything else.

- Hobbyists care much more about mobile/web support

- Professionals care much more about console support

- Professionals care much more about C++ interop

IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII

* From playing in the space I know it's possible to make games using Rust. However in the ecosystem my biggest negatives is the [lack of] case studies and demonstrations of it working.

* Rust is still a risky choice, compared to C++.

* Still feels like a new community. There is always risk associated with that - does the language take a big swing in direction - does support drop off. I'm encouraged by the support for low level (embedded / OS ) development, which hopefully means the core feature set remains robust.

* Many unfinished, unmaintained crates. Lots of churn.

* A lot of common needs are not yet available 'out of the box'.

IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII

* Compile time, no runtime reflection, updating deep dependency in the tree is hard.

* Iteration time is I think too big, due to compilation time, [lack of] hot-reloading tooling, etc.

* Iteration time (especially while prototyping). This includes both compile time but also sorting out lifetimes when I know I'll be rewriting something very soon anyway, this "frontloading" the effort of having the borrow checker run at compile time is useful for most tasks but when I want to try something quickly it can be a draining experience, in this regard GC'd languages have an advantage imo.

* Prototyping seems not as easy in Rust due to "fighting the compiler"

IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII

* Not enough documentation to get past beginner stage

* Lacking examples for gamedev libs.

* Documentation is usually either high level or examples but rarely both. Very few real world examples to draw from.

IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII

* Lack of a data-and-script based engine like Unreal Engine or Unity means even small projects end up feeling very bring-your-own-engine.

* Missing graphical editors, frictionless prototyping of games

IIIIIIIIIIIIIIIIIIIIIIIIIIIII

* The language has a higher upfront cognitive load than any other mainstream language I know of, mostly due to the borrow checker. It's very hard to hack through stuff and get away with it, which makes it a particularly hard sell for game prototypes.

* I know that it is a less common language to use so as a company I will have to have my staff learn Rust before they can start.

* Rust could be tricky to hire for, and hiring someone who doesn't know Rust to work in Rust will come with a ramp-up period.

IIIIIIIIIIIIIIIIIIIIIIIIIIII

Tooling around IDE is limited compared to Visual Studio with C++ or C#.´

* Definitely lack of proper IDE (like out of the box Cargo integration and working debugger - yeah, I tested Visual Studio Code and it's very slow, suggestions are not great, fastest way to run, check and build is to use terminal - not IDE) - I would say that something like QT Creator or Visual Studio would be great

* Regarding debugging, the industry standard is (or that I'm aware of) Visual Studio, for its very good IDE and tools, also, a lot of users are very used to that kind of tools and looks like Rust is missing some of them.

* rust-analyzer is still very incomplete, but it's the only thing that works for me

* Poor IDE and debugging support in IDE. Mainly visual studio.

* Can't debug it properly, hashmap (for example) is absolutely not debuggable. Not sure how it works inside (instead of C++).

- debug mode way too slow, often need to set opt-level=1 or 2 for dev profile

IIIIIIIIIIIIIIIIIIIIIII

* As a tools developer, a major negative point is the current absence of a reliable GUI framework (we use WPF + C# with Visual Studio).

IIIIIIIIIIIII

* No first party support for console development makes Rust a tough sell for a lot of professional work.

* Rust is not officially supported on console by Sony or Microsoft.

* Rust can't be seriously considered yet, because it does not have support from the PS4 SDK. Although there are other considerations (studio culture, integration with existing systems, etc.), official support from Sony is a requirement before Rust could be used in a PS4 game.

IIIIIII

Our code, and any middleware/engine that we might license, is in C++. Using Rust and C++ together is painful, and rewriting the existing tech to be purely Rust would be very expensive.

Testing and too much things linked to C.

* Also, no professional game engine (UE4, Unity) integrates with Rust yet.

* Unknown compatibility

- Lack of a straightforward path to make rust work easily with C++ in both directions. The only trustable way I see now is through manual C wrappers, which is error-prone and time consuming.

IIIIIIIIIIIIII

IIIIIIIIII

IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII

* Strong type system allows for easily enforcing some performance and safety best practices

* Multithreading safety

* Elimination of data races greatly improves reliability for multithreaded code.

* Safe concurrency

IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII

* Great performance and compile time verifications

* Performance and reliability

* Parallelism

IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII

* the ecosystem is full of passionate and smart people who take quality software very seriously

* a really welcoming community with great goals and courage to pursue them

* Collective community effort to "build the right thing" and "build the thing right"

IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII

* being able to pull down libraries piecemeal and have them build with your stuff immediately is great

IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII

* A mature Rust ecosystem will (hopefully!) have a lower bar for entry than a mature C++ ecosystem, without giving up performance.

IIIIIIIIIIIIIIIIIIII

IIIIIIII

IIIIIIII

IIIII

III

It really shines in network code that needs to be 100% safe and resist bad actors! My current game server code has 0 unwraps/panics/expects and so I just *know* it can't crash... I wish I could have that feeling in C++.

C++ on the contrary makes it easy to whip up something which then has a 20% crash rate and tanks perf and takes 2 weeks to hammer into shape, and after those 2 weeks it looks like Rust code anyway.

Unfortunately, knowing the management culture in the gamedev industry, Rust has an extremely hard road in front of it due to this. In my experience gamedev is plagued by extreme short term (like, 1 month) reasoning resulting in crunches and awful technical tradeoffs. Rust made many choices that delay that fateful "demo day with the execs" because it forces you to do things right. But very few can express why this is valuable up the chain and be listened to.

IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII

- better onboarding to rust gamedev

- Better explanation of best practices

- How to get started

- Rust for seasoned gamedevs

- What works *right now*?

- Example games

- Standard practices for common gamedev problems

- How to do windowing

- How to do graphics

- How to do ECS

- More documentation for foundational libraries

IIIIIIIIIIIIIIIIIIIIIiiIIIiIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII

- Lobby for Rust adoption on next-gen consoles.

- Clearer information about console support.

- Start an entity capable of getting and maintain console NDAs to keep official rust builds made for console support. It’s a huge pain, but other open source projects do it, and it would be awesome for the community.

- Wasm/web support (heavier from hobbyists)

- Paint a clearer picture of what the path to gaming consoles looks like, within the confines of what those proprietary SDKs and APIs allow.

- Mobile support

- Easier packaging

- Cross-compiling

- XR (AR/VR)

IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIiIIIIIIIIIIIIIII

- Develop contacts within the industry so that the WG can be a liaison between industry and OSS developers. By inviting and involving industry, the ecosystem can grow and potentially receive support (in the form of PRs, open sourcing existing tools, or financial support for OSS developers.)

- Encourage & facilitate collaboration on existing tools.

- Library “blessings”

- more things like this survey

- Ecosystem mapping

- Outreach / evangelising

- Game jams

- Better insight into WG’s current agenda

- Come up with ways to unblock foundational projects if they get stuck

- Identify in-progress issues, and propose new issues, for the Rust language, that are relevant to game development. (For example, debug Rust is very slow, so we need good ways to control what is and isn't optimized.)

- Seek opportunities to address cross-cutting concerns where possible. The recent investigation into raw-window-handle and evaluation of if we can/should converge on a math library are both good examples.

IIIIiiiiIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII

- Simple 2D game engine

- Basic editor workflow

- An SDL-like

- A Unity/Unreal competitor

IIIiiIIIIIIIIIIiIIIIIIIiIiIIIIIII

- Improve accessibility of graphics programming

IIiIIIIIIIIIIIIIIIiIIIIIIII

- UI libraries

- Windowing

- Audio

- Graphics

- Collection of “Standard crates” with some form of WG support

- Push for stabilisation

IIIIIIIIIIIIIIIII

- Hot code reloading

- Scripting

- Faster compile times

- More libraries like Processing

IIIIIIIIIIIIII

- C/C++

- Xcode, Android studio, Visual studio, Blender

- Unity/Unreal/Godot

IIIIIIIIII

IIIII

IIIII

[graphic pending]