"Entity Component Systems" are common in game engine architecture, and there are a lot of variations on them - but they are a high-level architecture for making modular behavior in games. Generally they were thought of as "better than Object Oriented, because they very very heavily favor composition over inheritance."

The idea is that everything in your game - like Players, NPCs, Bullets - are Entities. Entities are simply an ID. That's their only property. Nothing else.

But there are Components - they have the data. For example, you might have a `PositionComponent` that has an `X Position` and `Y position` property. And maybe a `MassComponent` that has a property `Mass`. Somewhere in the framework (like a database table), a given Component will be related to a given Entity ID. The Entity therefore becomes a "bag of Components" through the relations.

Finally there are Systems. They do stuff with the data. One system might be `GravitySystem`. It doesn't care directly about `Entity`s, but can query the relations. It might ask for anything that has BOTH a `PositionComponent` and a `MassComponent` (it doesn't know which Entity it is for - it only gets the Components). It takes any `PositionComponent`s it gets and applies gravity: `component.y += gravity`.

The effect is that you can mix and match Components in weird and wonderful ways without having to hard-code behavior and rules for certain entities. You can obviously achieve this with other architectures too - but that's the primary goal of this one.