There is a saying in programming: "data that changes together - belongs together". So ideally, the components should be combined/organized appropriately. Like for example "width" and "height" in this case don't mean much without a position.airstruck wrote:What do you do if you have a system that requires two components, like "position" and "velocity?"
Can't think of an example to this. Generally, you want the critical systems like drawing and collisions to use just 1 component. Higher level systems (pathfinding or AI) may access 2 or more components, but that code would usually run less often.airstruck wrote:What do you do about systems that require a component *not* be present?
Sure, I've used this approach and it works pretty good.airstruck wrote:This seems like a lot of trouble to go through in the name of performance, have you actually perf'd this against the "simple approach?" Note that if components are primitive values they don't create *any* extra tables in the "simple approach" (obviously). Although, entities will need to be tables, where I guess they can just be ids in your example. I'm skeptical about pairs ruining everything, though.
It's not perfect, but the main advantage is that you can easily iterate all entities that have a specific component.
This way you don't have to loop over all the entities in each one of your systems.