EnTT is quite nice because it's more than just a ECS (if you want), it also includes libraries for a variety of other features like resource management. It's more of a "game engine" library, which is fantastic for projects that don't need to muck about in a "game studio" like Unity/Unreal (e.g. for games or simulations that don't require traditional level design).
Yes, I think I like the overall EnTT design, but I've only toyed around with the ECS part, to learn how to use it. I still haven't entirely figured out when it's best to use an ECS and when to use a scene graph and if it makes any sense to use both at the same time in a project.
IMHO most games should use both. Think of the game as a 2D table, with Entities on one axis and their Components/Systems aligned on the other axis. Some operations go (densely) along the Component axis, like updating your physics simulation every frame. But many operations go (sparsely) along the orthogonal Entity axis, resolving events and other game rules involving many tiny sets of entities. These are orthogonal operations with different optimizations and I don't think there is one architecture to rule them all. However, I think an ECS like Flecs or EnTT is a good core to build off of.
Agreed. Especially the ability to split an object into multiple components/traits and have an operation run automatically for every component type appeals to me. It just seems elegant and 'good design', similar to 'composition over inheritance'. I think the strength of the scene graph is in the explicit parent-child relationship, where it applies, but I probably need a deeper understanding than I now have to mesh them in the right way.
