4 ms·

In ECS I don't understand where you put the collections (scene graphs, quad trees, etc) or what manages them. Does anyone have insight in this?

by plopz 8y ago

kvark 8y ago
The collections with any connections between elements are not exactly fitting the ECS model, which works best for independent components. When I was thinking about it back in the day, I came up with a Component Graph concept (implemented in [1]), which has the data locality similar to ECS but doesn't have a notion of systems. [1] https://github.com/kvark/froggy https://github.com/kvark/froggy
osaariki 8y ago
Like kvark said, they don't really fit the ECS model well. The standard answer would be to encapsulate them into a system (i.e. go outside the ECS). The way I see ECSs is that they are in-memory relational databases that only support equijoins (look up component matching entity ID) and optimize for table scans. The typical choice of an index structure is a contiguous ordered array, making for very fast lookups and scans. If insertion/deletion performance becomes an issue you can add one level of indirection and only keep a list of pointers to components ordered. However, like you indicated, games also need other kinds of queries, so scene graphs and quad trees should be supported as indices on the same level as the arrays and hash tables that are traditional for ECSs. I would love to see an in-memory database with all the features required by games. There are some very different tradeoffs to be made than in typical in-memory databases: - The most important queries are known up-front, since the simulation/rendering loop is fairly defined. - Transactions don't need to be durable. Just need to be able to checkpoint once in a while. - Lots of bulk updates from the simulation. - Query language needs to be well integrated into the application language to avoid overheads.
meheleventyone 8y ago
The main thing to realise is that not everything has to go into the ECS. This is a bit more clear with middleware like physics engines where you’re forced to integrate two views of the world. The game view and the physics view and need to translate and update between the two. Similarly with data in an ECS you can separately process spatial relationships either reusing the required data or keeping local copies as an optimisation.

In ECS I don't understand where you put the collections (scene graphs, quad trees, etc) or what manages them. Does anyone have insight in this?

by plopz 8y ago

In ECS I don't understand where you put the collections (scene graphs, quad trees, etc) or what manages them. Does anyone have insight in this?

kvark 8y ago

The collections with any connections between elements are not exactly fitting the ECS model, which works best for independent components. When I was thinking about it back in the day, I came up with a Component Graph concept (implemented in [1]), which has the data locality similar to ECS but doesn't have a notion of systems. [1] https://github.com/kvark/froggy https://github.com/kvark/froggy

osaariki 8y ago

Like kvark said, they don't really fit the ECS model well. The standard answer would be to encapsulate them into a system (i.e. go outside the ECS). The way I see ECSs is that they are in-memory relational databases that only support equijoins (look up component matching entity ID) and optimize for table scans. The typical choice of an index structure is a contiguous ordered array, making for very fast lookups and scans. If insertion/deletion performance becomes an issue you can add one level of indirection and only keep a list of pointers to components ordered. However, like you indicated, games also need other kinds of queries, so scene graphs and quad trees should be supported as indices on the same level as the arrays and hash tables that are traditional for ECSs. I would love to see an in-memory database with all the features required by games. There are some very different tradeoffs to be made than in typical in-memory databases: - The most important queries are known up-front, since the simulation/rendering loop is fairly defined. - Transactions don't need to be durable. Just need to be able to checkpoint once in a while. - Lots of bulk updates from the simulation. - Query language needs to be well integrated into the application language to avoid overheads.

meheleventyone 8y ago

The main thing to realise is that not everything has to go into the ECS. This is a bit more clear with middleware like physics engines where you’re forced to integrate two views of the world. The game view and the physics view and need to translate and update between the two. Similarly with data in an ECS you can separately process spatial relationships either reusing the required data or keeping local copies as an optimisation.