EnTT: Gaming meets modern C++ 3.9 (ECS library and much more)
1–10 of 27 posts
Re: EnTT: Gaming meets modern C++ 3.9 (ECS library and much more)
#2A great FAQ on ECS is available here:
Re: EnTT: Gaming meets modern C++ 3.9 (ECS library and much more)
#3A great FAQ on ECS is available here: https://github.com/SanderMertens/ecs-faq#what-is-ecs
Something I've had trouble wrapping my head around with ECS -- how does it fundamentally differ from an in memory relational database?
They describe a "sparse set" designed for sequential identifiers -- how does that compare to something like an in memory b+ tree?
Re: EnTT: Gaming meets modern C++ 3.9 (ECS library and much more)
#4A great FAQ on ECS is available here: https://github.com/SanderMertens/ecs-faq#what-is-ecs
Something I've had trouble wrapping my head around with ECS -- how does it fundamentally differ from an in memory relational database? They describe a "sparse set" designed for sequential identifiers -- how does that compare to something like an in memory b+ tree?
I don't think there is a fundamental difference. ECS is the application of relational databases in a dynamic real-time context with relatively modest amounts of data, but lots of sequential processing. Sparse sets work well in this context, but they are ultimately an implementation detail. There are other ECS implementations that don't make use of it but can still deal with large throughput.
Re: EnTT: Gaming meets modern C++ 3.9 (ECS library and much more)
#5A great FAQ on ECS is available here: https://github.com/SanderMertens/ecs-faq#what-is-ecs
Something I've had trouble wrapping my head around with ECS -- how does it fundamentally differ from an in memory relational database? They describe a "sparse set" designed for sequential identifiers -- how does that compare to something like an in memory b+ tree?
ECS is less about access patterns (relationships and queries) and more about efficient storage. Games care about page faults still so making your tight loop execute quickly on many smaller pieces of data and "do the right thing" is a win. Also, from an architectural perspective it's easier to write abstract code like `Health.value -= 10` instead of PlayerHealth.value -= 10`. By coding against a single components interface you can get consistent behavior across all entities with that component. You could also do this with inheritance but that becomes complex and (the real killer) very slow. jblow has some rants about this in the witness.
Re: EnTT: Gaming meets modern C++ 3.9 (ECS library and much more)
#6Earlier quoted context omitted.
Something I've had trouble wrapping my head around with ECS -- how does it fundamentally differ from an in memory relational database? They describe a "sparse set" designed for sequential identifiers -- how does that compare to something like an in memory b+ tree?
I don't think there is a fundamental difference. ECS is the application of relational databases in a dynamic real-time context with relatively modest amounts of data, but lots of sequential processing. Sparse sets work well in this context, but they are ultimately an implementation detail. There are other ECS implementations that don't make use of it but can still deal with large throughput.
> ECS is the application of relational databases in a dynamic real-time context with relatively modest amounts of data, but lots of sequential processing.
This is probably the best explanation that I can imagine -- that they're not fundamentally different, just that ECS tends to make a sufficiently different set of design choices that it warrants some of it's own terminology.
I can't help but wonder what a more generalized take on ECS might look like, if it were to continue drawing from relational databases. For example, support for multiple indices to assist with different query patterns. Or triggers to abstract away cascading updates. Or perhaps materialized views to keep query patterns simple.
I've never had the opportunity to use an ECS system, especially in a performance sensitive context, so I don't have a good sense of where any pain points are in practice versus what my imagination can conjure up.
I also wonder what it might look like to use SQL to generate an optimal C++ representation while keeping the data definition high level.
Just idle musings - maybe one day I'll take the time to experiment.
Re: EnTT: Gaming meets modern C++ 3.9 (ECS library and much more)
#7It's interesting to note that Minecraft uses this library.
Re: EnTT: Gaming meets modern C++ 3.9 (ECS library and much more)
#8What are compile times like? I'm always suspicious that "header only" libraries translate to excruciating compile times
Re: EnTT: Gaming meets modern C++ 3.9 (ECS library and much more)
#9Unpopular opinion, but I personally think ECS has no place in C/C++ game dev. Every supposed advantage is either curbed by limitations of the language (e.g. serialization) or can be implemented more logically in a stateless manner.
Re: EnTT: Gaming meets modern C++ 3.9 (ECS library and much more)
#10Unpopular opinion, but I personally think ECS has no place in C/C++ game dev. Every supposed advantage is either curbed by limitations of the language (e.g. serialization) or can be implemented more logically in a stateless manner.
I can't even imagine game dev without ECS. There's more performant architectures but it's such a useful mental model for the type of rapid iteration games need that so many people are willing to put up with the drawbacks