A simple agenda for the Rust Game Development WG

Back in August I started talking about a Working Group for Rust game development and the community (having already cooked up all kinds of game tooling over the past year) responded with a resounding YES!

The tricky thing about forming this WG is that it has long existed in a highly distributed form:

• Website: AreWeGameYet.com
• Chat: Discord (#gamedev), IRC (irc.mozilla.org#rust-gamedev), Matrix (#rust-gamedev:matrix.amethyst-engine.org)
• Forum: /r/rust_gamedev
• Twitter: @rust_gamedev
• GitHub: rustgd

I am talking with everyone involved in any of the above so that we may soon co-manage all these disparate properties together, lower our collective bus factor and present a united front.

What’s our collective goal? We haven’t really had that discussion at scale yet, but I’ll venture a fairly simplistic answer:

We’d like to make “Game Development” a target domain. I.e. we wanna show up here:

To get a better idea of how the existing 4 target domains went about pursuing their agenda I looked at their individual landing pages and noted some different approaches to goal-setting. One stood out to me, the Rust Network Services Working Group. Their mission statement is as follows:

Our goal is to improve web programming in Rust by:

Bolstering web components, i.e. assessing the state of foundational crates for web programming (like http and url), and working to improve it by writing documentation and examples, making API improvements, standardizing interfaces, and in some cases writing whole new crates.

Building Tide, which is a combination of a modular web framework built on the above components, and extensive documentation on what the components are, how to use them directly, and how they integrate into a framework. The name “Tide” refers to “a rising tide lifts all boats”, conveying the intent that this work is aimed to improve sharing, compatibility, and improvements across all web development and frameworks in Rust.

…and since these statements are deeply underspecified (as intended) I feel pretty confident doing my own remix. Here goes:

The tentative mission statement of the ‘Rust Game Development Working Group’ reads as follows

Our goal is to improve game development in Rust by:

Bolstering gamedev tooling, i.e. assessing the state of foundational crates for games programming (like gfx-rs ,winit,nalgebraandspecs), and working to improve it by writing documentation and examples, making API improvements, standardizing interfaces, and in some cases writing whole new crates.

Hard to argue that any of this would be bad for the game development domain. This next one is where it gets more opinionated.

Building Amethyst, which is a combination of a modular game framework built on the above components, and extensive documentation on what the components are, how to use them directly, and how they integrate into a framework. This work is aimed to improve sharing, compatibility, and improvements across all game development and frameworks in Rust.

I’ll make my case with as few words as possible, though I’ll be happy to defend my reasoning with greater fidelity in subsequent dialogue. If Amethyst was an openly traded stock, the following would be my lightning-round reasoning for investing in it.

Reason 1: Amethyst is demonstrating a rare convergence of contributors

It’s not often that you see pictures like this on GitHub:

The ‘Number of People Contributing Regularly over an Extended Period of Time’-metric.

Open source communities is my full-time gig at Discourse, so I see more of them than most. Each one is like a resume, often incredibly rich in detail. I reckon I’ve gotten pretty good at guessing whether a project will fare well or not, judging by its open data (including the README).

There is no silver bullet metric, but one of my favourites is ‘Number of People Contributing Regularly over an Extended Period of Time’, as illustrated above. 99.9% of open source projects don’t look like this. In my experience the vast majority of projects that have contributor graphs like these end up generating a great deal of value for their parent ecosystem as well as the software industry at large.

Reason 2: Amethyst is getting organised, literally and figuratively

Amethyst has already formed a legally registered organisation. Not only that, it is also borrowing a lot of ideas from the likes of the Rust Working Groups to form its own, highly autonomous teams for contributors to opt into at will.

Reason 3: ECS will soon be boring, and that’s a good thing

Jeff Atwood (my boss) says it well when explaining why Discourse opted for the Ruby programming language:

Ruby isn’t cool any more. Yeah, you heard me. It’s not cool to write Ruby code any more. All the cool people moved on to slinging Scala and Node.js years ago. Our project isn’t cool, it’s just a bunch of boring old Ruby code. Personally, I’m thrilled that Ruby is now mature enough that the community no longer needs to bother with the pretense of being the coolest kid on the block. That means the rest of us who just like to Get Shit Done can roll up our sleeves and focus on the mission of building stuff with our peers rather than frantically running around trying to suss out the next shiny thing.

After being around for decades, ECS has finally gone mainstream:

Job System & ECS - Unity

With Unity leading the charge a very significant portion of the game industry is conforming on ECS as a superior design pattern for a lot of the scaling issues they face. No longer fringe, ECS is fast becoming delightfully boring.

For now, until we’ve sussed out a proper structure for the core of the Rust Game Development Working Group, if anyone asks me “how can I contribute to the ecosystem of Rust gamedev?” I will reply:

Please contribute to our flagship project, Amethyst.