Thanks for reminding me to check it again, more in depth.I think the Artemis system has quite elegant ways of handling cross-component dependencies via placing an 'Aspect' abstraction between Systems and Components. But it doesn't remotely give you any of the data-oriented caching benefits. At that point, you have to ask what benefit it's giving you as compared to a simpler Unity or Unreal style component, i.e. as a simple encapsulated sub-object.
Well yes, zealotry is never good and i've almost always think about OOP code not in term of deep inheritance hierarchies, or basically all the "bad" characteristics people give to it.Most of the aversion to putting behaviour in components stems from several people incorrectly asserting that components are somehow 'against' object-orientation, and that therefore we need to ditch all object oriented features to truly embrace components. In fact components have been a key part of object-oriented design for decades. The Design Patterns book was saying "favor 'object composition' over 'class inheritance'" way back in 1995.
At the same time i recognize that sometimes in the pursue of giving better interfaces, this complicates refactoring for concurrency and giving priority to data flow.
Here i was thinking of a loop that needs to access to components of the same type, one after the other. It obviously all depend on the pattern access and data sizes.Being nice to cache doesn't always mean "make all the things contiguous". In the example implementation I mentioned, the entire hash table was two cache lines. Once they're fetched once, they likely remain in cache for the entire system update. The same can be true for larger hash tables too - sometimes you may be able to pre-fetch the entire hash map...
And this surprise me, i supposed that the fact that ECS talks about systems which have the logic and components are only data was to kind of enforce DOD.Extremely. They're opposite philosophies -- one says "look at the actual problems that need to be solved and craft minimal solutions to them" and the other says "lets make a generic framework that will solve every problem, and then solve every problem in the one way that makes it fit into our framework".
As before i was still thinking of the same type of loop.As a general rule of thumb having contiguous data helps the cache. That's not true for every situation though. [...]
Well i find that to be pretty wrong too, as i've said with Kylotan.Wait wait wait. Deep inheritance hierarchies are not normal. A core rule of OOP is that composition (i.e. the use of components) is preferred over inheritance.
If you've been reading the kinds of blogs that say "OOP is bad because deep inheritance trees have a bunch of problems, so here's ECS and it solves everything!"... then I'm sorry but these are straw-man arguments made by people who suck at OOP and instead of choosing to learn how to do OOP properly, they've instead given up and invented a new, completely unrecognised/informal pattern as a crutch for their ego issues. They're basically saying "OOP is bad because I'm bad at it, so I'm going to reinvent an ad-hoc version of the relational model and claim it as a new invention". Those blogs are bad.
What i meant with normal (probably poor choice of word) is what commonly (and probably wrongly) people referred to inheritance based games which have to be despised.
Not trying to follow any specific religion, if it seems so is because i still want to evaluate them fully to understand what seems the best and the worst parts, keeping the worst ones limited to few areas, where possible.If you drink the ECS cool aid, then it doesn't matter, just implement any solution and use it everywhere. If you drink the DOD cool aid, then everything is a case by case decision and you shouldn't bother with a component framework at all. If you stick with OOP, then everything is a component already, you have a multitude of choices for how they're connected to each other and you don't need a framework.
And you all are helping with that :).