[slides] ECS Paradigm

Hiya, I made some slides explaining the ECS model for an upcoming talk1, based on Catherine West's RustConf 2018 closing keynote (video, blog).

If you're in Auckland and don't want to be spoiled, don't look!

Please enjoy + help improve:

  • It's meant to be a 1 hour talk, the content might be too dense
  • The components in the system examples switch between Pos, Vel, Renderable, Position, and Position, Input
  • ... anything else you can find

1 We don't know where the talk will be, nor when :stuck_out_tongue:, still waiting on a venue/food sponsor

5 Likes

I think this is a good set of slides and makes it much clearer to me what the different options are to structure this kind of game in Rust efficiently! Some minor comments I wrote down while reading:

https://gitpitch.com/azriel91/ecs_paradigm/master#/5

  • is "contact_detailses" a typo or intentional?

https://gitpitch.com/azriel91/ecs_paradigm/master#/9/3

https://gitpitch.com/azriel91/ecs_paradigm/master#/12/6

  • I guess an obvious "memory bloat" drawback of the generational approach is that indices take up twice as much space—might not be relevant in practice but it's the first thing that came to mind for me

https://gitpitch.com/azriel91/ecs_paradigm/master#/17

  • the description of the lock/key analogy is very useful, might want to put it before the slide before it, I was confused by "exclude/blacklist components" snippet until then

https://gitpitch.com/azriel91/ecs_paradigm/master#/18/2

  • might want to mention what lifetime 's is
  • there's suddenly a Bgm system here not introduced before, I'd venture this is "background music"?

General remarks:

  • is all of this how it is implemented in the eecs crate? wasn't entirely clear to me as that is only briefly mentioned at the end
1 Like

Love the talk!

Very small nit: on this slide, the code wouldn't compile. You probably meant to write:

enum Entry<T> {
...
}

What does this (&x, &y).join() syntax mean? I haven't seen it before.

example:

// PositionSystem update():
for (mut pos, vel) in (&mut positions, &vels).join() {
    pos += vel;
}

EDIT: oh nvm i see that this is something in the specs lib

It was intentional as a point of humour, though it is meant to also distinguish it's a plural of a plural type. That's come up twice now so perhaps it's best to keep the singular plural form.

Oh! That didn't cross my mind, shall add that in.

Ditto :sweat_smile:

Shall! Couldn't decide on the order (curse of knowledge?), so this kind of feedback helps a lot.

Re: 's, I'm half clear on that myself, asking for some help from the specs people, I might remove it from the diagram.
Yeap Bgm is background music – trying to show that systems can be independent. Easier to clarify random new things when talking; hard to squeeze the text into the slide without being too crowded. Need to keep a consistent set of component types between slides.

The system part is quite accurate to the specs crate, albeit I don't go into so much detail; the EC storages part is close – combined reading from @kyrenite's blog, generational-arena, slotmap, and parts of specs code. DenseVecStorage is a bit more complex than presented (the implementation is seriously clever, I drew it on paper to see what it was doing). I'll add a note to mention specs early on

Thanks for the detailed feedback :bowing_man:!

1 Like

I like making sure things like that are fixed, thanks!

oh ya, I didn't mention bitsets, but 70 slides seemed enough :sweat_smile:.