Using Rust For Game Development
- Went over common ways to potentially structure game state in C++
- Use a single struct for the entire state and have everything “borrow” the entire state mutably
- OO gives you decent organization, but accessor hell is real, and cross-cutting concerns are hard to represent
- The OO approach in Rust is a non-starter without something like
Rc<RefCell> for mutability
- This is a good thing, because Rust is guiding you away from a bad design faster.
- A data-oriented is much better; focus on the data and how it’s represented separately from the functions that operate on it
- A couple of ways you can represent this in Rust:
- Single struct for the entire game state; Rust can “split-borrow” so you only borrow the parts of the struct you need.
- Use an
Entity trait/enum to represent different entity types
- Explode this trait into and
Entity struct that has
Option<T> fields for the union of all fields it’s “subclasses” might need.
- Move all these fields directly to the top level (no
Entity struct), and use indexes to keep things coherent.
- This is apparently what an ECS system is; I haven’t ever heard that term before.
- The Rust approach of using indexes to refer to a graph rather than raw pointers is a great starting point.
- Generational Indexes are better, and allow you to deal with stale indexes.
- The last bit of the talk dealt with dynamic typing, and I didn’t really understand this at all.
- Something about the
AnyMap crate and a registry pattern and listing all your types.