5 ms·

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 underst

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.

pmichaud 4y ago
This is essentially correct, yes.
reidjs 4y ago
That’s my understanding too. Think of super Mario. 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.
- forrestthewoods 4y ago
  I would not describe it quite that way. 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.
  - ywei3410 4y ago
    I think it's worth noting that when we talk about a system operating on a set of components, it literally means a function which either reads and creates new components or entities or mutates existing components. 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.
deleted 4y ago
[deleted]
pizza234 4y ago
> 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.
- tcoff91 4y ago
  This makes the cache locality excellent and is great for game performance.
  - meheleventyone 4y ago
    With the caveat that it’s actually quite a lot of work on top of this basic concept to actually make this happen.
  - brobinson 4y ago
    It also makes saving and loading state a breeze... you're basically just doing a database dump/restore. Coming across ECS was one of the few "holy shit what" moments of my time as a programmer.
- 4y ago

pmichaud 4y ago

This is essentially correct, yes.

reidjs 4y ago

That’s my understanding too. Think of super Mario. 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.

forrestthewoods 4y ago
I would not describe it quite that way. 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.
- ywei3410 4y ago
  I think it's worth noting that when we talk about a system operating on a set of components, it literally means a function which either reads and creates new components or entities or mutates existing components. 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.

deleted 4y ago

[deleted]

pizza234 4y ago

> 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.

tcoff91 4y ago
This makes the cache locality excellent and is great for game performance.
- meheleventyone 4y ago
  With the caveat that it’s actually quite a lot of work on top of this basic concept to actually make this happen.
- brobinson 4y ago
  It also makes saving and loading state a breeze... you're basically just doing a database dump/restore. Coming across ECS was one of the few "holy shit what" moments of my time as a programmer.
4y ago