[andre-la]

Also, I think it's important to say that ECS is not the only composition option, you can just use "EC" (or also CES): while on ECS the behavior runs on systems, on "EC"/"CES" the behavior runs on components, which is the case on Unity (by default) and O3DE.

I believe the mentioned Scott Bilas famous talk about composition follows this "EC" model instead of ECS, except that he calls it Game Object instead of Entity.

[dpig_]

Forgive me if I'm wrong about this, still trying to get my head around ECS concepts, but isn't the whole point that data and behaviours are uncoupled? Whereas Unity's Game Objects both hold data and are composed of behaviours (rather than being data-only objects that are operated on from with-out by systems)?

[andre-la]

Yes, I made this comment because sometimes I see some devs calling Unity an ECS (although it has an ECS option, but that's not the default mode most unity games uses).

Just to say that ECS is not the only composition option: Entity with composed behaviors is also an option (and the most traditional one I believe), and it does not have the infamous complexity of "pure" ECS in my opinion.

[krapp]

Just as no battle plan survives contact with the enemy, no design pattern survives contact with a specific implementation. You will often have to compromise purity for the sake of efficiency, the quirks of a specific language, performance, or in the case of a framework a consistent and general purpose API.