Book: Game Engine Programming in Rust

[AlexEne]

One of the main drivers behind this is to get more new people into low-level game engine development.
While engines like Unity & co. have lowered the barrier of entry for game makers, game engine development is hard to get into or learn about so I think there's value in making it more accessible.

There are also rust-specific things that appear when you try to do a game engine in rust (the most obvious is your architecture most likely has to be ECS or ECS-like). Could be combined with making your first rust game or a continuation of it that dives deeper into more specialized concepts.

[Lokathor]

I've got a lot of Handmade Hero code ported to Rust, but I cannot yet share it because HH is not yet open source.

That said, I'm interested in the book idea, but you have to decide how much you're trying to teach. A lot of Rust stuff just pulls in a crate and calls it a day. A book of this particular nature, of trying to be a low level engine development book, should probably abhore crates as much as possible. Winit for cross platform windows, gfx-hal/rendy/wgpu for some sort of graphics API, a sound API (rodio?), and then stop there. Don't pull in specs, explain how to make ECS yourself, even if you make an imperfect version and say "maybe use specs for real, but for education we'll use the one we built ourselves". Don't pull in nalgebra, again, actually explain what's being built and how it's used. Link to tech papers, link to Rust RFCs, link to external RFCs, show people Khan Academy playlists on Math couses so they can do Matrix work, all that.

It's a grand design, not easily finished, but if we want Rust to find a serious place in gamedev we need a complete pure Rust tech stack, and that includes a complete pure Rust education stack.

[Ralith]

Detailed documentation on how and why to build and/or use an ECS would be particularly valuable, as this is practically necessary in Rust and seems to be a common stumbling block.

[AlexEne]

I cannot agree more :). And my bias for this book would be to limit the breadth of it instead of depth.

For example, Even if it has a few main topics (whatever they may be), it should be going super deep into them. Not using any ECS crate, but showing how to build an ECS and what trade-offs are there when doing so.

And I know it's a bit of a scary and complex subject but it doesn't have to build a full game engine and a game in order to be a good book. For example something I consider good on this topic: https://www.amazon.co.uk/Game-Engine-Architecture-Jason-Gregory/dp/1568814135

It just has to explain the problems, the design decisions that you may have to make in that space and their trade-offs etc.

Also right now game engine development is a bit of a fancy and mystical thing with good conference content unfortunately behind greedy paywalls like the gdc vault. It also would help to make this kind of info more accessible because actually things are usually simpler than people expect in this space.

[ebkalderon]

Another vote for Game Engine Architecture by Jason Gregory as a good example of such a book. It provides a very good high-level view of how game engines suited for different game types work, including the rationale behind building an ECS for certain kinds of games. Code snippets from a variety of existing engines are provided to show what implementation approaches exist in the wild, allowing the reader to consider the possibilities and choose whatever works best for the kinds of games they wish to cater towards. Nowhere does the book actually give an opinionated step-by-step guide on how to build a game engine; it only demonstrates the fundamental concepts.

[thomcc]

Winit for cross platform windows, gfx-hal/rendy/wgpu for some sort of graphics API, a sound API (rodio?), and then stop there.

I think all of these are not exactly stable API surfaces (could be wrong, certainly several of them are), and so any example code you'd give would likely be out of date after a few months.

Sure, someone could still build it by pointing to your old version, but my experience with using old versions of graphics / games crates is that they tend to suffer bitrot from platform issues rather severely.

[Lokathor]

In discussion with the #game-and-graphics-dev channel of the Rust Community Discord, a few conclusions were arrived at:

Game Engine Architecture In Rust would take at least a year to write properly, probably more. And then when it's finished we don't really sell it so we don't really get paid, which means people are actually just making it with their free time, so 1 year is probably overly optimistic.

Next to nothing in Rust is stable enough. Like, not any of it. Not even the language we're writing with is actually that stable compared to the pace that C and C++ live at. I mean your old code will still compile, but it won't be using any of the best features and standard lib APIs. Like, look at where we were at as a language one year ago, and then start scrolling up. This is great, and I wouldn't want Rust to go any slower, but it makes code from even 1 year ago start to seem a little crufty. Soon enough our slow-to-update pal Debian will even have rustc 1.34 in their stable branch (up from 1.24.1) and we can reasonably say "we simply don't support versions before 1.34, even Debian has that much", but that doesn't stop Rust itself from marching on ahead.

Outside the std lib it's the same thing. Take winit, which we most all consider to be the best hope for a pure rust windowing system: a year ago it was at 0.16 and the API was very different from what it's starting to look like now. It's a lot of little things, but they pile up quickly. We don't have the Rust version of SDL2, and we won't for a while (if ever).

Besides the bitrot issues, there's a question of style. A book about theory that's light on code is great and timeless, except for the fact that it's light on the code which is terrible and useless. It's needed to have exact code, and actually struggle through each issue as it arises. It's easy to say "oh you'd do it like this" in a casual way, but as things build up and constraints bump into each other it gets harder and harder to go. Sometimes books cut out around there, but that's exactly when people need the most help in their work.

So we definitely want the book that's higher level, coherent, timeless. I don't know that we can immediately make that book.

Proposal: in addition to the book project, we have a separate "engine dev project", where the goal isn't just to make a working game engine. It's to document the process of making a working game engine. We start with a minimal set of cross-platform libs so that there's input and output (even those might get replaced eventually), then we use no other outside crates and force ourselves to actually go through the motions of building the blocks that build up an engine. This isn't just Amethyst Next, there's actually a fairly big catch: Before a PR that makes a change can be accepted the PR has to include a "dev journal" about what this adds and what was hard or easy. This isn't just commit messages, it's a fully written out markdown file that goes into a folder that people can read later like a blog sort of thing. This series of (probably scattered) journal entries then feeds back in to the book writing process.

[AlexEne]

I feel like we're missing the bigger picture here and we get lost in details.

I will re-iterate the book that I consider a good example here. Maybe we have different views on what such a book can contain, but I am re-posting the example I consider a good guide (as long as we focus it on rust language-specific things): https://www.amazon.co.uk/Game-Engine-Architecture-Jason-Gregory/dp/1568814135.

Just to clarify what I mean by us getting lost in details:

Outside the std lib it's the same thing. Take winit, which we most all consider to be the best hope for a pure rust windowing system: a year ago it was at 0.16 and the API was very different from what it's starting to look like now. It's a lot of little things, but they pile up quickly. We don't have the Rust version of SDL2, and we won't for a while (if ever).

This is a detail almost tangential to what engine development actually is. Having it in pure rust or not isn't necessarly a requirement. There is a SDL2 crate that's good enough for most needs.

I am unsure what we mean by the language being not stable, but I think we should try and focus on what we can do about game engine development in rust here as a book.

The proposal is interesting and I suggest to raise a separate issue that can be discussed instead of us combining threads here. Do keep in mind that the proposal you are making is heading towards one of the things that's explicitly called out in the charter so it should probably try to either steer away from it or clarify the proposal a bit more: https://github.com/rust-gamedev/wg/blob/master/docs/charter.md#what-we-are-not-doing