I can understand the fast lookup, but if I understand correctly, every object in the game is an entity, and every entity is represented in every vector? So if you have a hundred game properties, an object that only utilizes three properties still has to be allocated a hundred times over?
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?
It seems like there's a lot of waste in this model
I'm also not sure why struct of arrays is better than an array of structs, where each struct implements each component as a trait (but still relies on the system to do the work), at least logically. It would definitely be more memory efficient if there's a high number of components that are rarely used, if I understand things correctly
The talk presents a fairly simplified version of what game engines actually do.
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
> I can understand the fast lookup, but if I understand correctly, every object in the game is an entity, and every entity is represented in every vector? So if you have a hundred game properties, an object that only utilizes three properties still has to be allocated a hundred times over?
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.
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?
It seems like there's a lot of waste in this model
I'm also not sure why struct of arrays is better than an array of structs, where each struct implements each component as a trait (but still relies on the system to do the work), at least logically. It would definitely be more memory efficient if there's a high number of components that are rarely used, if I understand things correctly