I work in gaming, so I cannot speak to your specific experiences. Entity Component Systems are extremely performant, really good science, and shipping in middlewares like Unity. However, in order to ship an ECS game, in my experience, you have to have already made your whole game first in a normal approach, in order to have everything be fully specified sufficiently that you can correctly create an ECS implementation. In practice, this means ECS is used to make first person shooters, which have decades of well specified traditions and behavior, and V2 of simulators, like for Cities Skylines 2 and Two Point Campus.
So this is not meant to diminish the achievements of what you have built at all, it is more intellectually honest to say that "any high performance framework is most suitable for projects that are exact clones of pre-existing, mature things with battle-hardened specifications and end user behavior." While this might cover some greenfield projects, including the best capitalized ones that may matter to you, it does diminish the appeal of a framework for the vast majority of success stories from small & poorly capitalized teams. Those small & poor teams are very innovation and serendipity driven and hence rarely copying a pre-existing thing. And even if they try to become well-capitalized, they are almost always doing so by having worked on the thing they are copying already (i.e., already shipping version 1.0 for years).
Yes, this is along the lines of what I'm suspicious of too, as an also-gamedev that has done some ECS.
It's too easy to study an existing system and, given the resources, create a perfect demo for how to dramatically improve it in certain ways. You can go on to ship the demo, but the demo wasn't made by the same kind of organization, with the same kinds of goals, as the original system builders. The extreme example of this is, of course, the demoscene and its hardware-bending tricks that achieve the impossible through a significant modification to the design of a "production" equivalent.
So it's better by performance metrics, better by codesize, but unknown on other metrics. Like, "do I know how to start building new things with this?"
Asking “what are you optimizing for/building towards” and getting different answers for different products isn’t proof that either is inferior, just that they may be better at different things.
Your comment makes it seem like their post is misleading, when it isn’t it just might be that what they do best isn’t useful to you (or possibly anyone).
I can’t go into specifics due to NDAs, but I’ve been a developer on a game that was designed and programmed with the EnTT library from the ground up. [1]
I don’t know if I’d suggest ECS for every team as you need the right tooling, culture, and leadership to pull it off. That said, I think the paradigm has unrecognized benefits when it comes to greenfield gameplay programming.
Or, your data structures become a way for sub-teams to communicate and share state without stepping on one another’s toes. A group handling pathfinding and a different one handling scenario/mission logic can both pay attention to the position data without needing to be highly coupled. It becomes easy to “just add a system” or “an extra component” to build on existing functionality.
The Fred Brooks quote about “showing me your tables” comes to mind.
I only hobby in game dev. I have read some basics of ECS and IMO it seems a lot more intuitive than the “normal approach”. I think this is a case of using familiar tools we are comfortable with, not necessarily better. Unity’s ECS implementation is a hot mess though. I am looking forward to seeing what Bevy delivers as it matures.
I agree that copying an existing product will be easier and is usually cheaper and more performant because you can leverage your competitor’s R&D and lessons learned. I presume this is why some tech companies’ product lines are full of clones.
So this is not meant to diminish the achievements of what you have built at all, it is more intellectually honest to say that "any high performance framework is most suitable for projects that are exact clones of pre-existing, mature things with battle-hardened specifications and end user behavior." While this might cover some greenfield projects, including the best capitalized ones that may matter to you, it does diminish the appeal of a framework for the vast majority of success stories from small & poorly capitalized teams. Those small & poor teams are very innovation and serendipity driven and hence rarely copying a pre-existing thing. And even if they try to become well-capitalized, they are almost always doing so by having worked on the thing they are copying already (i.e., already shipping version 1.0 for years).