So your saying everything is a entity, and that entities have components, and the systems operate on entities (possibly based on their components). Do I understand that correctly? That understanding is definitely worth the time it took to read.
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).
> 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.
The storage part of ECSs could actually be considered a form of columnar db.
For example, locking is at column level, so you can have as many mutable accesses to a single entity (like a row) as there are columns (in reality, it's more complicated, due to access via iterators, but that's the principle).
Entity is Mario, the koopa troopers, the coins, the clouds, the floor tiles, the spikes, the mushrooms. All the proper nouns.
Component is the XY location in the world, ability to jump, sprite image, the height, are they affected by gravity. All the adjectives.
System is gravity - all entities with weight drop at the same rate until they hit ground. Another system may be the collision mechanic - if a mario entity lands on a koopa entity, the Koopa dies and some sound effects plays.
Functionally, an Entity is an ID. A Component is Data. A System is a function that operates on a set of Components.
In a sense "that's it". Having the hard separation between data (components) and code (functions) leads to some interesting consequences. For example the ability to more easily multi-thread System updates because each System clearly defines what Component type it needs const or mutable access to.
Most "things" don't exist in ECS. There's no singular "Mario" or "gravity". If you feel like you ought to split it into multiple identifiers for your systems (for example, treating each part of Mario like a different sprite), then you do so.
The hardest part of ECS IMO, is that dependencies between systems are super loosely defined since it's meant to be modular and the dependencies can only be tracked by components. The semantics of ECS systems are also highly technical (do you have hard sync points, how do you deal with recursive entities etc...) which means it can be quite fiddly to work with.