My RustConf 2018 Closing Keynote

Here's an index. As you can see, it's got an index, but also a generation https://github.com/steveklabnik/indexlist/blob/master/src/li...

The list itself keeps track of the current generation: https://github.com/steveklabnik/indexlist/blob/master/src/li...

When an entry is removed, this is increased: https://github.com/steveklabnik/indexlist/blob/master/src/li...

Each entry also keeps track of the generation it was inserted with: https://github.com/steveklabnik/indexlist/blob/master/src/li...

When you call get, which takes an Index, the generation is checked https://github.com/steveklabnik/indexlist/blob/master/src/li...

Same as if you try to delete something at a given index: https://github.com/steveklabnik/indexlist/blob/master/src/li...

Does that make sense?

Components that are only used by a minority of entities can be kept in a map. The talk refers to `specs`, which is an ECS system implemented in Rust. It allows you to use different backends (a vector, a couple types of map, etc.) and it uses bitsets to optimize determining which entities have which components: https://slide-rs.github.io/specs/05_storages.html

As to why "struct of arrays" might be preferred to "array of structs", it's all about locality of data. Game Programming Patterns explains it way better than I possibly could: http://gameprogrammingpatterns.com/data-locality.html

For any properties that are stored in a linear list, yes. Typically, values that are found in almost every object, and values that are small are placed in simple vectors. Values that are more rare and/or large enough to care about can be placed in a different, denser data structure.

> Also I'm not sure how a system is meant to recognize which entities to do its work on, without iterating over the entire associated vector, every frame?

For a lot of things you do in a game, iterating over the entire vector is substantially faster than deciding on what items you need work on. Linear access is really fast, cache misses are slow, and if the work done per entity is low enough, it can legitimately be faster to do it for everything and then just use a conditional move to only store the valid values, instead of eating branch prediction failures when choosing what to work on. Especially as SoA layout makes vectorizing code really easy.

If behavior is controlled from the top level(as is suggested by the cases where the main loop grows to 10's of thousands of lines) your behavior branching also appears there. The data is still driving everything, but if the data model is inherently complex it bubbles up to the surface. And you can use sum types(whether provided by the language or in less structured "match a magic constant" type deals) to check your coverage. During prototyping, you can lean on dynamic types instead and get a similar outcome with more fluidity in model changes and lower debuggability.

That feels instinctually wrong if you're dosed up on polymorphism and expect a kind of "ultimate abstraction" where any of the enemy types could be totally different and you just write to an interface, but - the thing you want, and that is the practical situation in most gameplay logic, is not "wholly bespoke behavior per type of enemy, hide everything behind a facade and either duplicate code or use a complex indirection to reuse it where it's the same" but "98% of the behavior is on the same code path and reads top to bottom, except for the one or two important pieces of business logic that isn't". The latter is both more compact in total SLOC and by being surgically precise, gives more visibility into what the code does at the moment you try to debug or extend it - which is what we're really aiming for.

And if you have really complex behaviors, you do end up with Turing-complete script logic embedded in the data, just naturally growing out of data model extension to cover FSM logic. That indicates that you are never really "giving up power" at any point in this process - you're just gradually moving things up the abstraction chain in a controlled fashion, until your main loop is really an interpreter that deals with "opcodes" and "commands" more than it does any particular algorithm or data layout.

And then when you get there, you can go, "well, now that I have a virtual machine, let's optimize around that..." and then you start writing some tech to lower the overhead of the interpreter...and it just goes from there. You never have to jump off that train, but you can usually ship something well before you get it even to the Turing-complete level of programmability, too.

I-- what does this even mean??

On the one hand, they don't need something like GC, as this clearly shows. Many larger games can't afford it, and wouldn't really benefit if they could, since they've already worked out more special-purpose access patterns.

And on the other hand, those games that can afford it often do use it already- Unity games are written in C#, UE4 has a limited GC for game objects, Minecraft was written in Java, tons of games use scripting languages like Lua for gameplay logic.