Game development in Rust has made some big leaps in the past few years. While it’s pretty hard to nail down “what is a gamedev library?”, the metric of success is very straight forward: Every new game written primarily in Rust is a win.
The current state of Rust gamedev is showing lots of promise:
Rust has two quickly maturing game engines in ggez and Amethyst
Rust’s cross-platform story (including intense focus on WASM) is immensely valuable for game developers.
gfx-rs is shaping up to become the de facto graphics backend for Rust whilst playing well with a lot of other independent projects.
I’ve seen a great deal of ECS fragmentation in gamedev. If the Rust gd community manages to consolidate around Specs, that’ll make all the shared pieces that much more compatible.
A very strong backbone for games is quickly maturing: gfx-rs, glutin & winit, lyon, PistonDevelopers, specs, nphysics, gltf, rodio, RustAudio, rlua etc.
Bless certain toolchains as “editor’s pick”. One of the most frequent questions on rust_gamedev is “How do I get started?”. @kvark made one such doc a year back. Good to see that everything listed is still highly relevant and not defunct one year later.
Try to map & track the dependency graph. Figure out which problem areas to highlight for new contributors.
Organise Rust-specific game jams
Coordinate a group of evangelists who will readily and honestly talk about the upsides and downsides of Rust for game development as it stands today.
I am not volunteering to lead this group, at least not alone. I know there’s plenty of Rust gamedev giants out there so my hope is that I can help those giants get organised.
On a personal note, I’d like to explain what excites me most about Rust. As a non-programmer I can only measure its technical merits in the number of projects that I see having success with it, but it’s the leadership’s focus on community that really excites me more than anything else. I’ve never before seen a major open source project (especially a programming language) be so obsessed with actually maintaining a culture of positivity and constructive dialogue. The team is also very transparent and accessible.
I co-led the Java game engine jMonkeyEngine for 7 years. With Java there was this huge divide between the language developers and the library developers. In Rust many of the low level graphics libraries that this fledgling gamedev ecosystem is growing on top of are maintained by developers from Rust core and/or Mozilla.
I’d also like to see language changes based on feedback from the industry/community. For example create and/or drive rfcs to address problems that are currently present in Rust.
How to write runtime allocation free code? Drive the custom allocator implementation for libstd
How to write performant code? Keep an eye on the generated machine code. Potentially add more stuff to the compiler to ease some pain points. Potentially similar things that Unity does with its Burst compiler. Help to write more optimization passes for MIR.
Math libs: What language features are missing to write a sane and efficient math library? Eg const generics. fast-math is only available on nightly.
How to write portable code? Make sure everything works smoothly on different consoles
We have the basis for a really great list in @tomaka's gamedever wishlist for Rust over on Users. For now that's probably the best place to drive the discussion of language features forward.
Your fundamental questions are excellent. Providing canonical answers to these could certainly be under the purview of a Rust GameDev WG. That reminds me, one of my former hobbyist partners in crime once wrote this general purpose tutorial on game math:
It was written for jMonkeyEngine but it is not engine-specific. Also I should note that I'm not a fan of the "for dummies"-part since not everyone will get that "joke".
Just to add my two cents here - I’ve thought before that something like this should exist. Game development is one of the fields where Rust could really shine. There’s a lot to be said for it as a “better C”, before even beginning to talk about its safety features and ergonomics.
I feel like Rust is mostly ready for game development, at least for medium-sized projects. Some evangelizing and polishing of game dev crates could be a real benefit.
The plan is to make it as automated as possible. At the moment to contribute one has to edit html by hand, which is not nice.
@viperscape has a version of this static generation functionality, that I haven’t integrated yet.
Actually, I was planning to have some time to help with that next week.
The objective would be to have arewegameyet auto-build and deploy on commit.
I wasn’t thinking on changing the look, or structure of arewegame yet, just how the html is generated.
That’s great news. Getting more collaborators on board who can help merge PRs would also be good. I know a handful of games that should be added to the list (like the 4 LD entries listed above).
There also ought to be a dedicated section for “Commercial use” to better highlight those particular milestones.
Having a dedicated WG for rust-gamedev would be great! I have considered it, but essentially realized I don't have the capacity to organize the whole thing. I'll be happy to participate in the meetings though.
This is a blessing and a curse: there isn't one gfx-rs that Rust community is converging on. There is one that is published (pre-ll), used by ggez, Amethyst, three-rs, and a bunch of games. Essentially, it's in maintenance mode, it supports OpenGL/GLES/WebGL and Direct3D-11 (requiring separate shaders though).
Then there is gfx-hal, which is a from-the-ground-up redesign and re-implementation of the project that is focused on Vulkan-like API. This is what's being actively developed, but there isn't much adoption because gfx-hal API is neither published or stable yet. There is a Vulkan Portability frontent for it though, which could be used more.
I don't expect the WG to help us with stabilizing the API, but what they/we could do is to at least making sure that the Vulkan-related Rust projects share as much as possible:
single low-level bindings people agree on, e.g. ash-sys because it's auto-generated.
direct hookup to gfx-portability, which is stable (!), so that Vulkan users (Ash, Vulkano, etc) don't have to go through the C boundary and can get more code in-lined.
unified documentation aka "The State of Vulkan in Rust", explaining the moving parts.
Hello! I would be interested in being a part of this. (I was sad when the domain working groups kicked off earlier this year and gamedev wasn’t represented, so thanks @erlend_sh for getting this ball rolling!)
I have been developing games in Rust quasi-professionally for the past 2 years, including releasing a commercial project written entirely in Rust (which I’ve written a little bit about). Small-yet-serious work like this definitely has a different set of concerns that hobby games and AAA games, and I’d love to represent these interests in the WG.
I am also interested in being a part of this. I’m a professional game developer at a AAA studio, but I focus mainly on Tools development, which is a bit of a different beast. We don’t yet use Rust, but that doesn’t mean I wouldn’t like to, and the more barriers I can knock down there, the more chance I’ve got.
I’m still very new to Rust, but I’m a big fan and want to participate in any way I can.
I'm curious about this too. I get that the domain working groups are special, but I seem to be missing a clear explanation of how these many other working groups are formed and how they function. The only "perk" of formalisation that I'm aware of is a dedicated channel in the official Rust Discord.
Meanwhile I've been quietly trying to bring the existing gd community efforts closer together:
The mods of /r/rust_gamedev agreed to deprecate its wiki in favour of arewegameyet.com so that we'll have a single source of truth for Rust gamedev resources. I'll do a series of PRs for the resources covered in the wiki not currently present in AWGY.
I reached out to the AWGY team of @doppioslash, @viperscape & co. to ask if they'd be willing to bring on some more collaborators so we can reduce the bus factor and overall maintenance burden. Haven't heard back from them yet.
@ozkriff suggested that a bridge between #rust_gamedev on IRC and #gamedev on the community-run Discord server would be useful. I'm guessing something like discord-irc would be used? That's not something I can help with but I think it's a great idea. Would need to coordinate it with @erickt, @Mark_Simulacrum and whoever manages #rust_gamedev.
We've yet to identify any prospective leadership for the group.
In other words, my short-term goal is to make sure Rust gamedev's primary forum, chat & directory is all managed by the same people because they're all part of the same community effort.
I get that the domain working groups are special, but I seem to be missing a clear explanation of how these many other working groups are formed and how they function.
In general, there is no set process for this. I usually jokingly say: if more than 3 people want to work on a topic, you can slap a label on it and make it a WG. A WG makes you addressable for the project and for other people. Make sure to let us know of your intention, goals and especially where you want to meet and how to get in touch.
I know that our project infrastructure is currently not quite setup to document that all, but that will hopefully improve soon.
For what it's worth, I've been working on something that could do it. It's far up the backlog at the moment, but if consensus is "we want a bridge, but we want it in Rust", I can cobble together a specific solution.
I am interested in being part of the working group, as well. Have been on and off working (solo, mostly hobby) on gamedev-related Rust projects for the past two years, used Rust in two Ludum Dare jams (acutally finished last one), contributed to ggez. I don't have any first-hand knowledge of how GD industry (be it large studios or indie teams) actually does things, but I know Rust GD ecosystem fairly well, and have been giving advice and "proselytizing" whenever prompted.
Thanks for the info. In that case I think we'll start by uniting the somewhat fragmented gamedev efforts under one "Rust GameDev" banner before moving on to formalising an official WG.
Good to know that a Rust library is available. I think the most pragmatic approach would be to start off with the already stable JS library since it hopefully won't require any JS programming, only configuration. If it turns out this setup is hard to maintain we could reconsider the pure-Rust approach.
That said I can't be hands-on with this item so the final call on technical implementation will be made by whoever steps up to actually drive this forward.
I think there are a couple milestones we can shoot for as proof of maturity.
The book on Rust game development
All the cool working groups are putting together proper handbooks dedicated their domain. I think “someone should write a book about this” is a good litmus test to justify the existence of a working group. The first version of this could simply be a curation of existing resources of high quality, such as Catherine West’s ECS talk.
A proper bundle of AI libraries
I wish there was an AI equivalent of the excellent RustSim. Essentially a Rusty version of gdx-ai. If someone pursues consolidation with some conviction in this area they could quickly amass a meaningful number of patrons.
More finished OSS games
There’s a pressing need for small, finished, playable games for greenhorn developers to learn from. There’s plenty of existing tutorials to RIIR, for example:
So, recently I got into Rust on the GBA. I’m not sure who is familiar with the Rust Community Discord (distinct from the Rust Development Discord), but it turned out that there were a few other folks on there who were also doing “Rust on a console” stuff (GBA, 3DS, GameCube). I’ve also seen Rust on Switch, though I haven’t spoken to them, just seen their repo on GitHub.
Anyway, I talked to the embedded-wg and they were happy to help with any particular issue with targeting weird chips, but didn’t want to take on crates targeting that stuff directly (out of scope and all), so I made a GitHub group that we can migrate our crates into as we have the time and inclination. Every console is it’s own quirky beast, but I’m fairly convinced that any console you can target with C you should be able to target with Rust too. It’s mostly an issue with documenting how to do it.
Of course, a lot of the usual “game dev” crates for Rust don’t at all make sense in the context of a console. You definitely can’t put gfx-hal on the GBA, and you probably can’t put it on the 3ds or GameCube either. Still, this thread for Rust [PC] gamedev seems obviously close to Rust console dev.
I’m not asking for help or that people do work for us, I guess I’m just making a halfway announcement about our GitHub group existing. If you have a crate that you’d like to add to the group just send me a message (I guess here or on the Community or Development Discord) and I can get you set up with a repo.
Just make sure you aren’t breaking any NDAs by putting code on GitHub. I know at the very least for the WiiU, any and every detail of the development environment is under NDA (other than what’s available on the public website, which is basically just “you can use Unity or a web framework”). I’m pretty sure you could share a Rust adapter for the WiiU SDK on those forums, which are blocked behind accepting the NDA, but I’m also pretty sure that putting it on GitHub would open you up to attack by Nintendo Ninja.
TL;DR make sure you don’t host any interfaces based on non-public information.
