4 ms·

That's certainly an interesting way to organize things, though I dislike the reliance on several 'manager/coordinator' classes. (though part of this is my super

That's certainly an interesting way to organize things, though I dislike the reliance on several 'manager/coordinator' classes. (though part of this is my superstition that class names shouldn't end in -er or -or) The main mechanism seems to be for 'systems' being able to iterate over tuples of 'components' of a specific type for all 'entities'. I can't help but wonder if there isn't a more elegant way of doing this than trying to keep the set of entities for each system up to date. Though I suppose it depends on what you want to optimize.

sparkie 4y ago
One of the main goals of ECS is to improve the use of the cache and reduce the amount of dereferencing. An alternative approach, which does not sacrifice the more common OOP style: https://www.doc.ic.ac.uk/%7Escd/ShapesOnwards.pdf https://www.doc.ic.ac.uk/%7Escd/ShapesOnwards.pdf
- contravariant 4y ago
  Is that really what you get when you put all entity IDs in a set and iterate over those? Sure the component arrays are packed but that's kind of pointless if you're iterating over them in a random order (note that the system proposed here will also gradually destroy the ordering in the packed arrays). Not that I know an easy way to keep a lists of components that ensure that iterating over them is anywhere close to cache-efficient. Perhaps some kind of self-ordering system would work? (you could for instance move components to consecutive positions as a system uses them, ideally in way that's stable so you don't mess up the ordering of other systems)
  - samatman 4y ago
    If the system starts ordered and is iterated frequently, and things move (due to deletion) rather less than they are iterated, you can use... bubble sort. It's basically free to do one stripe of bubble sort while iterating, and for games, you'll iterate everything once or more per frame, but introduce and delete things less.
    - contravariant 4y ago
      The trick there is to ensure things work nicely if different subsets are iterated one after the other. Note that merely ordering isn't quite enough, let's say a particular system needs components ABC and component C is rare, then the ideal situation would be to sort A and B such that those entities with component C are close together.
      - samatman 4y ago
        The devil is indeed in the details when one sets out to use memory in this Fortran-esque fashion.

sparkie 4y ago

One of the main goals of ECS is to improve the use of the cache and reduce the amount of dereferencing. An alternative approach, which does not sacrifice the more common OOP style: https://www.doc.ic.ac.uk/%7Escd/ShapesOnwards.pdf https://www.doc.ic.ac.uk/%7Escd/ShapesOnwards.pdf

contravariant 4y ago
Is that really what you get when you put all entity IDs in a set and iterate over those? Sure the component arrays are packed but that's kind of pointless if you're iterating over them in a random order (note that the system proposed here will also gradually destroy the ordering in the packed arrays). Not that I know an easy way to keep a lists of components that ensure that iterating over them is anywhere close to cache-efficient. Perhaps some kind of self-ordering system would work? (you could for instance move components to consecutive positions as a system uses them, ideally in way that's stable so you don't mess up the ordering of other systems)
- samatman 4y ago
  If the system starts ordered and is iterated frequently, and things move (due to deletion) rather less than they are iterated, you can use... bubble sort. It's basically free to do one stripe of bubble sort while iterating, and for games, you'll iterate everything once or more per frame, but introduce and delete things less.
  - contravariant 4y ago
    The trick there is to ensure things work nicely if different subsets are iterated one after the other. Note that merely ordering isn't quite enough, let's say a particular system needs components ABC and component C is rare, then the ideal situation would be to sort A and B such that those entities with component C are close together.
    - samatman 4y ago
      The devil is indeed in the details when one sets out to use memory in this Fortran-esque fashion.