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

[@Condog64]

I feel bad because I originally came to this talk from Jonathan Blow's critique years ago. And I guess I'm really glad he did that video, because I love this talk. Ignoring the stage jitters that just goes with the territory, Catherine West is a fantastic speaker. I've watched this video maybe 3-4 times now.

[@The9TKitsune]

"And this a shared pointer to void-" KZbin app crashes. Couldn't be more perfectly timed.

[@nexovec]

hahaha that's priceless

[@godmodeon666]

I am sad she said this might be the most uninteresting talk of the conference. She is an excellent speaker and I was eagerly listening the entire time. I usually skip like a madman thru talks and found myself 30 minutes in having not skipped at all.

[@drbawb]

I've been hearing people reference this "great ECS keynote at rustconf" for a week or two now. Glad I finally get the opportunity to watch it! -- Nobody mentioned it was re: chucklefish/spellbound, and now I'm even more excited!

[@TheBicPen]

I love this talk as just a talk about game design, not just as a Rust talk. I've been searching for good tutorials on designing a game for a while now, and most either use an existing engine, or use an extremely simple design.

[@ErichDonGubler]

Hah, that was me right at the beginning saying "You'll do great!". Glad to see it made the cut! :)

[@Huy-ed2re]

I like the way she warned the audience for things they might not like about her talk. That sounds even more sincere.

[@mani98]

Experimenting with Rust myself and watched this talk before jumping in. Thanks a ton this saved me from hours of OOP work for sure!

[@Hoowwwww]

First of all, thanks, you show OOP example, then say why it is bad, then you try to translate it into an other language, and show why it is bad, and then you show what are the alternatives, slowly you focus on the data, then you explain why ECS makes sense This is how people show treat the OOP issue, instead of just saying "LOL u idiot why u use OOP".. So Catherine West thanks a lot! i'll experiment with ECS a bit more, even if i don't use rust, i'll do it with my favorite language

[@JP-mc3bv]

Yea it's always great when people take you through their reasoning and how they got to their conclusion instead of being derisive about it.

[@nexovec]

17:00 "private: // ..." :D :D :D :D

[@Mautar55]

I know right? Now i can show the issue to my friends.

[@tiagodagostini]

Well I would prefer if universities stopped teaching and PREACHING OOP. OOP is nice to teach basic programming, but it is horrible for system with complex relations.

[@zhou7yuan]

Question I Keep Being Asked [0:49] (code sample) An Answer: The Design of a Medium Sized Game Engine [1:43] Rust Makes Certain (BAD) Patterns more painful than others, which is a good thing! [2:49] The simplest possible Game Engine - Global Mutable Game State with "SYSTEMS" [4:57] What can we learn from this [6:10] downsides: everything global & public everything procedural & unchecked, systems have unlimited mutable access Too Much Object Oriented Design [7:55] (code sample) Making a game engine with OO design [9:21] (C++ sample) EntityIndex (no one use pointer) Using Classes & Interfaces [12:14] New Requirements Start Coming In [14:01] The more layers you have for re-use, the more accessors you need [15:59] How many accessors could you possibly need? [16:53] Let's Try this is Rust [19:11] -> Rust [19:37] (Entity, GameState) The larger the structure is, the more you borrow [22:13] Takeaways for game development and Rust Development in General [23:24] Back to the beginning [24:46] And the simple update loop structure with "systems" [25:05] Let's unify our Entity type [26:38] generalizing the fields on our entities [27:18] Takeaways for rust uses in general [29:37] Generational Indexes are awesome [31:18] better than Vec [32:27] Putting it all together [32:53] Takeaways for rust users in general [33:22] Dynamic Typing is nice in Controlled Quantities [34:09] Adding a component always has to change our game state [34:53] Let's use AnyMap to store our components [35:26] The "REGISTRY" PATTERN [36:22] We can add all of our individual "registries" to one big top-level "registry" [37:48] Takeaways for rust in general [38:40] Closing thoughts [40:00]

[@PBrrtrn]

"forceNude()? What kind of game did I make?" This cracked me up really badly, had to stop the video for a minute. This presentation was awesome, not just because of the little stuff like that but also really loving the down-to-earth rationale for ECS and the problems OOP brings in the long run.

[@flwi]

That's an excellent talk! So glad it popped up in my timeline. Will watch it again after reading through the article and experimenting a bit.

[@blenderpanzi]

I'm not a game developer, but there is a certain small indi game with public source (not sure if FOSS license, but you can compile/port/whatever it yourself). It did the taking internal pointer thing to elements of a std::vector and then it sorted the vector. I actually experienced the resulting crash while playing, debugged it and submitted a patch to fix it. :)

[@akj7]

Of course saving a pointer to elements of the vector is stupid: the internal array gets reallocated to increase its size, which places the elements of the vector at newer positions. It is even mentioned in the reference. Is C++ at fault?

[@camthesaxman3387]

If it was a linked list instead, then it's valid to store a pointer to one of its elements, since list items never move.

[@cvrptn]

I like the talk a lot, and it's made me reconsider the design for my own lightweight game engine written in Rust. However, I'm wondering whether the whole generational indexes approach is the best way to go. Either you have very sparse entities with lots of different component arrangements (in which case you'll be allocating a lot of memory in your EntityMap component stores for entities not using these components), or your entites all have sort of the same set of components (in which case you might wonder if it's not better to just have a single Entity struct that contains all your components and store it in a large Vec). Granted, the EntityMap pattern allows for very fast O(1) lookups of your components but it comes at the cost of wasted memory.

[@PledgeBass]

Such an amazing talk! Takes a lot of skill and thought to communicate this much information in such a clear way.

[@sindisil]

Thank you so much doing this presentation! It's my favorite, by far, of the past year!

[@mindstreamx]

Now that was a clear explanation and made some very valid points about OO design.

[@RG001100]

I read the blogpost not the video. Wow, what a great post!

[@phlimy]

Thank you SO much, I'm so happy to have stumbled upon this. I've struggled for a long time to organize my game code cleanly, and this talk will help me a LOT. I love how we get to see the actual problems with OOP hands on. These are problemd that I stumbled upon and prevented me from going too far down the OO road but I wasn't sure if the problem was just with me. The transition over to ECS is perfect and feels very natural, and it's a great explanation of the design decisions. I'm super eager to get started playing with this! Again, THANK YOU!

[@AlexHoratio]

I watched the whole thing but I realize at this point that I have no intentions to make my own game engine and I don't know how to use Rust. ._.

[@nonenothingnull]

"...what you can learn from it, even if you're not a game developer"

[@okdoomer620]

welcome to youtube

[@CripplingDuality]

Well, look at it this way: she is making a convincing argument that Rust's idioms and constructs make programmers more productive in building high quality, performant software. I haven't bought a game at launch in years because I find that it can take up to a year before the product is stable. Wouldn't it be nice to not have to delay that gratification? If we have good evidence that the tools that game devs use are inferior to some of the alternatives, and we speak their language, we can hopefully convince them to give those alternatives a try. :)

[@timdiekmann5751]

Is your Blog post already uploaded? I'm really excited about it. Great talk!

[@bradleat]

i was waiting for 28:44 the entire time. i don’t program game engines, but it just seemed like the best idea to me

[@sitton76]

Seen a good deal of rust video talks, and this one was really really informative.

[@Vigilon]

So... how do I implement the "monster damages player" functionality under this architecture? Where does the code live? Is it a method on one of the component traits? What arguments does it get? Does it need a mutable reference to the entire ECS? I'm a tiny bit disappointed because it seems like the talk ended without explaining how the proposed solution actually solves the problems that it brought up. Well, it does explain some of them but not all.

[@peppeppeppepp]

You will learn that here: slide-rs.github.io/specs/ But in short: You register functions to ECS that use some components as an input and modify some other components and these functions are called on every entity that has those components present. This way those functions can even run in parallel. So for example basic physics is implemented by function that takes position, motion and mass components and updating position component.

[@Abubalay]

You write it as (part of) a System- so yes, it gets a mutable reference to the entire ECS, but that's fine because it runs as its own phase of the game loop. Instead of zooming in on one interaction ("monster damages player") you zoom out and handle things holistically, detached from any individual piece of that interaction (e.g. maybe "player/damager interaction"). That way as these interactions get more and more intricate, all of that complexity stays together in one place rather than spreading out across the entire codebase.

[@anotherelvis]

This code is often saved in procedures named Systems (the S in ECS). One solution is to have write procedures such as update_all_positions that iterate over all entities. If you give each procedure mutable access to he entire game state, then you can introduce a trait named System and implement it for each of the procedures. This allows you to iterate over systems/procedures to update the entire game state. If you want better of scalability, then you can introduce message passing (event sourcing).The idea is that update_all_position works on an immutable ECS, and it generates a list of events to update the state. These events are processed afterwards. I tried this and it was fun to write, but in hindsight I don't think that it was worth the trouble. EDIT: But you get much of this for free by using specs

[@tommmlas]

Great presentation. Had to revise written version multiple times & managed to implement base version, but still have some questions. So at some point we have all structs to store our "players" entities and different type of components. But how do we relate those? I mean for player entities for sure we'll allocate generation index with alocator. But what about components? Do we expect to set components by entity index to retrieve it back while just having entity id. Or maybe allocate new indexes for every component as well? In case of latter, how do we query components by entity id?

[@IgneousGorilla]

What an amazing talk fr

[@tathanhdinh]

19:11 => Let's try this in Rust

[@MathieuTanguay2802]

I would really like to have a link to the blog post when it is published. Very interesting talk.

[@Auroden]

Maybe you already saw it but: kyren.github.io/2018/09/14/rustconf-talk.html

[@scriptozavr]

Great talk Catherine, thank you!

[@samphire]

Please use the mouse pointer to point next time you present, we can't see your laser pointer so its really hard to follow what you're talking about. Also, camera person, please stop moving the camera, frame the shot and leave it alone. Thanks!

[@hatorizenzo8769]

Thanks for the video, I learned a lot today. Never heard of ECS before let alone consider it. I was trying to make a sandbox-ish program for a game I play, went ahead with OOP and it gets weird really fast in Rust.

[@renney77]

I'm unsure about two parts here. 1. At 29:00 ish change from an array of structs to a struct of arrays. I don't think I came across this before, what is the advantage in certain context for that? If it's conventional, any links to good resource on that? 2. At 35:30 ish Catherine is talking about using this AnyMap because you don't have to list all the arrays of EntityMap. But don't you have to add them all into the AnyMap at some point anyway?? Great talk!!

[@etodemerzel2627]

1. en.wikipedia.org/wiki/AOS_and_SOA and google some other resources

[@Wren6991]

Struct of arrays gives better locality of reference. When you're doing your physics calculations, you'll get better performance if your top level cache is filled with physics data rather than, let's say, 20% physics data and 80% unrelated stuff that happens to be in the same object.

[@Neightr0]

Does anyone know what the official name for the registry pattern is? I'm curious to read more about it, and I'm trying to find a name for it. I think the pattern would have a lot of potential for creating plugin interfaces. Maybe you could just have every plugin contain some sort of metadata, and then when you load the plugin you read it and load the specified types?

[@sirdorius361]

Service locator pattern

[@User-cv4ee]

With generational indices, how do you know if an object has indices stored to it in some container and if it is safe to delete it? I could store players in all_players and again same indices in team_1, team_2 etc. An `Rc` would prevent this?

[@Architector_4]

When you're retrieving an entity (i.e. its components) with an index, you get back an Option (or multiple) from the storage. This explicitly requires you to check if that Option actually has a component in it or not. You are free to delete the entities entirely at any time; later on, when checking an index of a deleted entity, you just get the "None" results. At that point you're free to just skip to the next index, if any, or clear it from your index map lol

[@atarawhisky]

Wow, I LOVED this talk!

[@AxWarhawk]

Blog post is up: kyren.github.io/2018/09/14/rustconf-talk.html

[@loganhodgson6343]

In rust, how do you access different fields of the AnyMap at the same time? Each get_mut call blocks you from accessing other fields mutably.

[@ddystopia8091]

Did you solve your issue?

[@espadrine]

The Vec would grow unbounded, though right? I assume that is the point of the generational index, but wouldn’t a HashMap be better than the Vec? You wouldn’t need the Option, too.

[@tech6hutch]

I don't think a `HashMap` would work because you'd have no way (at least no `O(1)` way) to get an entity by its index. The point of generational indexes is that they overlap on the index part. Maybe you could use a `HashMap`? But then storage wouldn't be contiguous in memory, which is the advantage of using a `Vec`.

[@lflime]

@@tech6hutch A HashMap get is by design O(1), if you have the hash of your enity (which you have most of the time). Plus youd get a add and delete of O(1) also. I build an ECS based on dictionaries in C# and it worked like a charm and was fast. BUT. If you have Systems that need to iterate over the full collection (like physics) a Vec or a List is faster and easier. Like always the anwer is "it depends" on what you need in your game.

[@nazarkostetskiy4822]

I'm not from Rust, but I'm also wondering why they are using Vec and making abstraction on it and then naming this abstraction EntityMap. Why just not use HashMap for this and get entities by key? We don't need any indexes and etc

[@kulkalkul]

Vector has better data locality. It is mostly about iterating. When you apply physics results into transforms for example, there could be lots of updates for majority of the entities each frame. So, iterating them in predictable arrangement of physics stats and transform order plays to the cpu cache.

[@neoplumes]

Does anyone know if there's a crate out with this ecs?

[@mzg147]

What is the difference between arena allocator and "vecs with indexes"?

[@ddystopia8091]

Simplicity idk

[@NickDrian]

great talk!

[@TadejKanizar]

Really great talk

[@monomere]

Amazing talk!

[@TheLavaBlock]

Interesting and great talk. Thanks

[@veetaha]

Awesome talk, did learn a lot from it, thank you very much!

[@adamblance3346]

This was super informative, thanks!

[@gabrielguitiánestrella]

Thank you

[@lordofwizard835]

She is soo awesome

[@shreevari]

This was fun

[@MikeMike-bd8vw]

That was great. Thanks.

[@tvanantwerp]

New ambition: play Starbound for as many hours as there are lines of bad OO code in the player class source code.

[@stevesan]

can you explain to me why those lines of code are bad? aside from "omg that's a lot of boilerplate"?

[@naxaes7889]

@@stevesan The player class has too many responsibilities and is not very dynamic. Given enough time, it's likely to become a "God class" as well.

[@codmw2FrEaKk]

Is the Blog Post already out? I can't find it...

[@QuestionBlockGaming]

kyren.github.io/2018/09/14/rustconf-talk.html

[@stevesan]

alright alright, can someone explain to me what's so bad about that C++ player class with all those accessors? yes, it's a lot of accessors...but all those are things that one might want to read/write about the player..i don't see the problem. is it just the volume of boilerplate?

[@Mathspy]

If you're making an OOP system and all those "private" by default things are just private behind accessors you ought to realise "There has gotta be something I am doing wrong" because then the pattern just exists for no reason.

[@skaruts]

Well another thing I noticed is that it seems to know more stuff than just about how to be a player and behave like one. The scope of the class went beyond what was probably originally intended. That may or may not be a bad thing, but it certainly breaks the principle of single responsibility, and that one turned out a bit messy and bloated. I think it's been one of the major problems of OOP is that it's really hard to actually follow its principles. Currently trying to wrap my head around other paradigms because of that. OOP is great for some things, though, like UIs.

[@charonstyxferryman]

Breaking encapsulation. If private fields actually, via getters and setters, are public - just create a strut with public fields and borrow it out to anyone who is interested in using its data.

[@aprettz]

Great talk! By the way the video title here should be changed to something more informative than "Closing Keynote"

[@RustVideos]

Fixed! Also added a link to her slides.

[@jsonft5417]

Just... thanks!

[@maverickreal09]

If rust is not the future then the future is rusty.

[@jonathanmoore5619]

In the beginning there was ....

[@kim15742]

Heh, this is funny, because I wanted to give up rust with the exact though "I nedd RefCell" everywhere

[@sergesolkatt]

HARDCORE

[@deanroddey2881]

It has to be said that there's a lot of anti-OOP in here, but that's not because OOP is bad, it's a very powerful tool. You just need to use it where it's applicable. Too many people these days take these types of talks as proof that OOP is inherently bad and should always be avoid, which is just silly. Everything is inherently bad if it's the wrong tool for the job. If there are natural hierarchies involved, and very often there are, OOP is a perfect tool for the job.