I'm no expert, but here are my 2cents. One of my "ahhh moments" with ECS was when someone pointed out. The ECS has a very 'strict' boundary on DATA(attributes,

I'm no expert, but here are my 2cents. One of my "ahhh moments" with ECS was when someone pointed out. The ECS has a very 'strict' boundary on DATA(attributes,entities,components) VS BEHAVIOR (methods,systems,functions). The 'traditional OOP' usually 'smash/hide/design/encapsulate' these two conflicting powers into one 'Entity' I think it's 'easier' to write a ball-of-mud in OOP for games, then it is to write ball-of-mud with ECS. *NOTICE I said 'easier' not 'impossible' I love the distinctions between BEHAVIOR and DATA, from an organizational point of view. The bigger the whole system is the more value I think a good programmer can get with ECS. Imagine having to "implement" gravity for 100 different types of 'Objects'. Sure The ECS way would be to have a System(Gravity) that executes the 'same computing' on all entities with a 'MassComponents' and 'PosComponents' for example. The Entity would usually not need to know ANYTHING about Gravity. Sure the OOP way one can inherit but eventually you inherit yourself into a corner (diamond-problem). My 2cents - YMMY TL;DR (just squint hard enough) ECS ~= (Data | Behavior) OOP ~ (Data + Behavior)