RustConf 2018 - Closing Keynote - Using Rust For Game Development by Catherine West

There was a great talk recently about how to properly build an entity component framework in Rust if you haven't seen it yet. [VIDEO]

I rather enjoyed RustConf 2018's Closing Keynote, "Using Rust For Game Development" by Catherine West: [VIDEO] I learned about the ECS pattern and got to see some Rust refactoring in action. Previous HN discussion here: [LINK]

It depends, I am over a year in Rust and it doesn't take me that much longer to write something in it than say in Python. The confidence I have that the thing I wrote is way higher in Rust and it is usually much faster. And: it is incredible easy to build and deploy. I think whether Rust is useful or not depends entirely on the application. If you need high confidence in what the thing is doing, it should run parallel and fast and you are familiar with the concepts Rust is using – it isn't a bad choice. For me it replaced Python in nearly every domain except one-use scripts and scientific stuff. It can be hard for advanced programmers to abandon certain patterns they bring from other languages though. In the first months I tried too much to use OOP, which doesn't make any sense and leads to convoluted code. If you work more in a compositional and data oriented way while making use of Types and Traits, you will end up with much simpler solutions that work incredibly well. Katherine West's RustConf 2018 Talk on ECS Systems describes this incredibly well and might be even good to watch if you are never intending to use Rust at all, because the patterns discussed are quite universal: [VIDEO]

+1. Like you, I've seen both sides. Unreal lineage evolved from inheritance-based into ECS-like. Frostbyte is heavily ECS. Googling... the author is ex-amazon, ex-microsoft - with xbone and 360 title experience. Perhaps the author was exposed to that pattern at one of those institutions, or perhaps the author saw the 2018 Rust Conf Closing Keynote[0] and was inspired to continue down that path. I think people tend to either go with what they've seen work in the past, or heard works well. Maybe it's cargo culting, or maybe in the case of rust (which I have no current experience with), it helps? Either way, the most important point is to focus on the fun and not let technologies get in the way of making a good game. [0] - [VIDEO]

Catherine is relatively known in the Rust community, hence why I didn't mention anything else. Here is her keynote talk at Rust Conf 2018. [VIDEO]

But do they use linked lists for them? I would have assumed you would use an arena for something like that, precisely because you already need to iterate over all of them and can represent any graph as keys into a generational index, so that reading stale keys is trivially handled. Again, I'm not a game dev and this is just my understanding after reading up on these topics after watching [VIDEO] .

Chucklefish, the developer of Starbound, uses Rust too. The lead dev on the project gave a great presentation [1] at RustConf. [1] [VIDEO]

I just recently came across these two videos. Using Rust For Game Development by Catherine West: [VIDEO] Counter-rant from Jonathan Blow: [LINK]

This is basically what an Entity Component System is, right? I always find myself linking back to this talk: [VIDEO]

It is a very different and seemingly weird approach. It's almost like writing SQL queries for your game world (e.g. "find all entities with a Flying component and attach them a WooshSound component). A clever memory layout makes these queries super fast. It makes separation of concerns very natural. Different parts/layers of the game, like inputs, AI, sounds, graphics, effects and animations can be coded separately. You don't end up with "god class" for player's object that does a bit of everything. You have player entity that has components attached, and each system operates on its own set of components. I can't really do it justice in a comment. It's a quite different approach, so it's not directly comparable. It's like OOP vs Rust's traits. ECS happens to match Rust's memory model and traits incredibly well. Here's a more in-depth talk about this: [VIDEO]

This Rust conference talk, of all things, is still my favorite ECS explanation, because she builds the concept piece by piece starting from megaclass-hell to full entities-as-IDs with reasons for each step. Also she's a pretty entertaining speaker IMO. [VIDEO]

If you're looking for something with a narrative you can watch, the RustConf 2018 closing keynote [VIDEO] is a great talk that has an overview on "generational arenas", which are effectively "just" a vector with a custom index type that holds the "pointed-to" generation, and the stored values also store their generation inline. This allows: all objects to be stored in a contiguous block of memory (increasing the likelihood of "pointer-chasing" style of code to have the pointed to value warm in cache, significantly speeding them up), allows relocation (because you're no longer dealing with pointers, but rather offsets to the beginning of the pointer), and doesn't have the pointer invalidation problem (because the "pointer" now asserts that the pointed to value hasn't changed, and if so return an Err/None). It also has the benefit that because you're not dealing with pointers you don't need to write any unsafe Rust code, out of bound accesses are checked, and the borrow graph becomes simpler because the arena owns all of its contents, instead of having to keep track of the lifetime of borrows at compile time (the famous "fighting with the borrow checker") nor is as "expensive" as the tracking an Arc<RefCell<T>> could be.

The Entity Component System (ECS) pattern seems to side-step the Rust borrow checker entirely in order to solve the following issues, all at the same time: 1.) allow a "parent" entity to have a reference to a "related" entity, 2.) allow such a reference to a "related" entity to be mutable, 3.) allow multiple "parent" entities to reference the same "related" entity, and 4.) allow the overall system to deallocate a "related" entity at any time without invalidating the state of all the observing "parent" entities. I have never written a game before, so Catherine West[1] might have very good reasons for choosing ECS, but I... am not so crazy about it. ECS seems to replace Rust references (raw pointers) and/or Rust smart pointers with indexes into one, large "registry" (a container: e.g., a `Vec<T>`) of entities (e.g., `struct` instances). In other words, instead of allowing a Rust pointer (a managed memory address) to keep a piece of memory alive, ECS chooses to have a "registry" keep a piece of memory alive under a particular index, managing allocation and deallocation manually. In a sense, ECS dumps Rust memory management in favor of... writing the good, ol', data-and-function -oriented C. Quite needlessly (?), since the same (?) can probably be accomplished with Rust reference counted pointers[2], weak pointers[3] and interior mutability[4]. ----- CUT HERE ----- use std::rc:: {Rc, Weak}; use std::cell::RefCell; type WeakMutEntity = Weak<RefCell<Entity>>; struct Entity { relate