I just want to add that this step is not necessary. The components can be owned by the entity, and that's okay

I actually completely agree - the only reason why I mention having a separate container with the components is because of post #1 and #3 - and many people will argue that iterating over components of a specific type in a given system is more "cache friendly" if done in this way.

However, I agree that the OP is far from needing to worry about what is or what is not "cache friendly" at this point. I think that it could be a good exercise to implement components in this way though - as I have found this pattern useful for many other things besides just "components". But maybe it's just me.

@[member='EarthBanana'], The more info and knowledge the better :). Very interesting though as i was worried that having both the vector/map of components for the entity and then also a vector of components for each type of component would be very wasteful (though i could very much be wrong)

Hey guys,

I have managed to create a ECS (thanks to your help) but if its ok (and since the post has not reached the time limit yet) i was hoping i could ask one last question.

Is it ok for non systems to pull a components entity, personally i cant see a problem with this atm but I thought it be best to ask. Currently i have an oct tree class that does request the aabb and obb components of the entity (as well as other collision parameters to test the collision type) and checks for collisions. I could prob find a way to move this to a system but is it really needed?

Thanks again for the time :)

It's your code, your rules. Personally I think it might be strange that the octtree needs to know anything about entities. If I was handling collisions with your code, it sounds like I would have a collision system, and that would be responsible for requesting the bounding boxes from entities and providing those to the octtree.

@[member='Kylotan'], So your saying that i should just pass the aabb's to the octtree and then when it comes time to do collision, loop through the entities that can collide and test them agains the aabb's in the same node (as well as in the parent node)

The collision system doesn't necessarily have to loop through the entities - if it knows which bounding boxes came from which entities then it can just check for collisions and if any happen, get the entity ID that was stored alongside the bounding box involved in the collision.

@[member='Kylotan'], hmm interesting. The way I have it currectly is that the octtree gets updated and places all of the entities in vectors for each node and then another system called collisionrun calls root.update which check all the collisions from the root of the octtree down to the last nodes (atm with around 200 entities just using AABB and no logic after this is taking 19ms's (debug mode) so might be something i have to look at optimising a bit better).

I also have heard that another way i can make things more efficient is to have different entity lists for different systems (as not all entities need to be checked by a system) is this a good tool?