Well, I don't think I've enough skills on this and I'd follow the project eagerly to learn something new, so I'd go with what you feel confident and/or you like!
My thoughts are that such a project would be of interest for tons of people though, I'd willingly share it as much as possible. :)
The design is such that you pay for what you need. To do what you're looking for, that is, a linear access on multiple components without jumps nor anything else, there exist groups. They are the fastest thing you can imagine because you iterate literally N arrays for N components in order with no jumps nor branches. They affect performance on creation/destruction though, in order to speed up quite a lot linear accesses.
Also, views are such that it doesn't worth it creating a group when one of the components involved in a query is assigned to few entities, since the view internally uses the shortest pool.
And so on, there are tons of details and use cases. The documentation (the wiki, not the README) contains all the details but it's pretty big and takes a while to go through all them.
The fact is that a real world software isn't made only of linear accesses, so the whole library is meant to allow optimizing the given access pattern when needed.
Feel free to ask if I triggered you and you want more details. ;)
Reach me out here, on gitter, discord, by mail, whatever...
With this post I wanted to go into details on the grouping functionalities that can be implemented with sparse sets. This is something I have been asked about since I published the last part of the series and I think it can help to better understand how EnTT works under the hood.
My thoughts on a possible implementation made on top of the registry, waiting to find the right way to offer them as a built-in feature. Feedback or suggestions for alternative solutions are welcome.
Stay tuned then. I was already planning to write something about scene graphs and component-based models. Nothing forbids to write also about the rest.
I saw the video, but they don't go much in details on the actual implementation, so it's hard to say where, how and if things are optimized or not. Moreover, the speaker stresses also on the fact that ECS is used for code organization in most cases and they benefit a lot on this aspect.
Good point. I put it in wrong wording probably. I didn't want to say that it's a shitty thing, just let the reader know that it's not a great improvement in terms of performance. However, I point out also how the halfway approach already is worth it and brings in some benefits, the same you nicely described in your comments. ;-)
Maybe. However it makes sense to stick with the paradigm with which you are more comfortable. There is no shame with using OOP instead of component-based models or the other way around. I think that knowing both of them can help sometimes, because they fit different problems and can work side-by-side tho.
That said, if you'll ever write such an article, ping me!! I'm pretty sure it will be an interesting point of view to think of.
My goal is exactly to give details on how to implement different component-based models from easier ones up to hardest ones to develop and provide links to real-world implementations. In the last part, I'd like to go in depth into one or two of them, but I'm doing all of this in my free time, so it will take a while to publish everything. I hope you'll stay tuned and keep reading, because feedback like these ones are invaluable.
I agree that component-based models should not be taken as all-about-performance solutions. I'm using ECS as the core of some software of mine but of course OOP is still present around to treat other aspects and problems that don't fit well with ECS in general. I mean, such an architectural patter solves a specific problem in an elegant way, but it doesn't solve everything in let's say a game. Try to put everything into components is a common mistake that leads to poor code sometimes. However, for those part where it fits, I like to use this architectural pattern because it's closer to the way I think and thus easier to work with for me.
Yeah, I'm the author of EnTT C++ ECS (https://github.com/skypjack/entt) and I can guarantee you there are no holes there. :-)
The next post (part 2 of the series) will be more or less all about this point. I hope to publish it as soon as possible.
The idea is exactly to guide the reader through different models, from the easiest to implement to the ones that are probably hardest to develop but have no holes, perfect matches, higher performance and so on.
Stay tuned.
To be honest I use composition over inheritance because it fits better with my mental patterns. I've nothing against OOP in general and I'm pretty sure we can have code with good performance also without a component-based model. The fact is just that I'm not as good at designing things with OOP in mind as I'm when I design them with components in mind. But this is me, not a golden rule.
I don't think the idea is difficult actually. What I've found difficult when I decided to implement my own tool (https://github.com/skypjack/entt) was that technical details on how to design something that was both easy to use and with good performance were scattered all around the web. I'm just trying to summarize what I've discovered so far for the "future me". :-)