My comment has nothing to do with implementation. We're talking about ECS in the context of DoD so I'm not sure what relevance being data-oriented by default ha

My comment has nothing to do with implementation. We're talking about ECS in the context of DoD so I'm not sure what relevance being data-oriented by default has. It seems like you're just confusing the concepts of ECS, DoD, and composition. Your entire post on ECS is, "If you don't use DoD with ECS than you're not using DoD". Well yeah.. obviously? If you implement an ECS and then use it without data-oriented structures, then yes obviously you don't have data-oriented design. You're creating a strawman. You're saying if you take ECS, remove the idea of storing components independently of entities, and pass them in an inefficient manner to systems, then you don't have DoD. ECS isn't inherently DoD, literally nothing is. Arrays aren't inherently cache friendly. There's nothing stopping you from making a language that allocates data randomly throughout reserved memory and every array element points to each location. No one is arguing ECS is inherently DoD, but it is a good design to facilitate DoD. > For example we might want to do damage to another entity entirely. Add a damaged component to the entity to damage. Consume damage component in a system. > Or we might want to look up the properties of the piece of ground we're stood on Use a position component on the entity standing on the ground. Consume the position in a system and look at the properties of the terrain map at that position. Even simpler for grid based maps. > We're also ignoring interacting with other components or the world and how that might work You interact with other components by defining interactions in systems based on those components. You've created an ECS in a way that doesn't take advantage of any of the benefits, and complaining that all you're left with is the disadvantages.