> is a entity, and that entities have components, and the systems operate on entities (possibly based on their components) In an object-based design, objects a

> is a entity, and that entities have components, and the systems operate on entities (possibly based on their components) In an object-based design, objects are monoliths, with fields. You get a reference to player, and each Player instance has attributes. When you work on a player, you get the Player instances as a whole. In an ECS design, you'd create a player entity; the main differences are that the Entity is just a reference, but most importantly, you access each field (called "component") separately. The bulk of querying is performed on components, which, importantly are all global; entities are typically retrieved starting from a component instance they own. This makes the radical difference with a traditional object-based design; example: - in OB, you have, say, players and enemies; when you draw, you'll cycle the players, and enemies, and draw them. - in ECS instead, you'll query something like "drawable sprite" components, and draw them It's a very interesting design, as it forces to reason more generically. It tends to get messy very easily though, since it's harder to think in terms of location of a system (in the project). The best book for beginners to understand ECS is (IMO) Hands-on Rust (https://pragprog.com/titles/hwrust/hands-on-rust https://pragprog.com/titles/hwrust/hands-on-rust). > So your saying everything is a entity Not sure about other ECSs, but Bevy has also the concept of "resources", which are globals; they're monolithic, and there's only one isntance of each type.