9 ms·

Based on many of the comments here, it seems like there’s a lot of misunderstanding of what an ECS is - unfortunately the name does this no favors as it should

• Buttons840 4y ago
  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
• Nition 4y ago
  It gets particularly confusing because the standard Unity paradigm is still one of entities and components, as I believe was first promoted by Dungeon Siege at GDC 2002[0]. But it's not quite the same as what is called an ECS. [0] https://www.gamedevs.org/uploads/data-driven-game-object-system.pdf https://www.gamedevs.org/uploads/data-driven-game-object-sys...
  • KronisLV 4y ago
    We could all probably benefit from some slightly better naming, so that EC and ECS don't refer to almost completely different things. Otherwise you get some of the confusion as Java and JavaScript might have had back in the day. If the concepts are so different, they should be named more distinctly.
• andrewflnr 4y ago
  This Rust conference talk, of all things, is still my favorite ECS explanation, because she builds the concept piece by piece starting from megaclass-hell to full entities-as-IDs with reasons for each step. Also she's a pretty entertaining speaker IMO. https://youtu.be/aKLntZcp27M https://youtu.be/aKLntZcp27M
  • fartsucker69 4y ago
    This is also one of my favorite talks, because it showed me that Rust is mostly recommended by people who don't know what they're talking about made me not waste any time on it (besides the horrendous compile times in real projects even compared to cpp). For example, she spends a significant amount of time there explaining how to implement her component placement strategy while working around the borrow checker and at the end proclaiming how great it now is compared to a cpp implementation... ...not realizing that what she's just done is implement a custom allocator (not literally allocating memory, but the operations are the same: give me space for a component, free it, memory is latter accessed by an address instead of being some opaque thing hidden behind language semantics, etc) that can fail in most of the typical ways and that she's gained nothing over the cpp implementation while wasting effort to force Rust into allowing her to do something really basic.
    • spoiler 4y ago
      Wow... Okay. I see you didn't even bother watching the video in full. You somehow managed to ignore all the points of the talk. Like literally every one of them, and I'm not even exaggerating. And then you somehow both managed to focused on irrelevant details and to talk out of your ass (like, at least be right about the details?), all to make a tangential point about how "sUpErIoRlY sMaRt CpP dEvs ArE" because they know this really basic shit. But, I'll respond in case your misinformed comment manages to deter people from watching it. Let's start. First you talk about "borrow checker issues" she's demonstrating in the OOO design. The point here was to illustrate the amount of coupling and "explosion" in size with this approach. The point was "OOO is probably not a good design paradigm for game dev". Then she continues how Rust surfaces this bad design paradigm much earlier than it would've happened in other languages/ecosystems. That's all. More, what you call a custom allocator with tombstoning/generations are just things that exist with a lot of ECS implementations (regardless of language), and it's just become "tribal wisdom" at this point that this table-esque storage backend work really well with ECS (I dunno which one came first; older game devs might know more about ECS history/evolution than I do).[1] Also not sure what you mean by "that can fail in most of the typical ways and that she's gained nothing over the cpp implementation while wasting effort to force Rust into allowing her to do something really basic"... Maybe I misunderstand what you mean, but it sounds to me like you're comparing working with `Option` as being the same failure mode as working with `void*`. That's just utterly ludicrous nonsense. Her ECS implementation is... Well, it was made to fit inside a few slides for a 40-minute talk. So, yeah it's not great; there's plenty of small issues with it, but none of them are with Rust, or with ECS itself... Did you expect a production ready ECS library you can copy off of slides and use them in your next game, lol? If anything, her implementation has too much passing resemblance with what a C++ implementation would look like (which is something she's very familiar with and her starting point) than a Rust one. So, I'm just bewildered why this is the bone you decided to pick. If you're interested in what a production-ish ECS implementation in Rust looks like, check out Amethyst's Legion or Bevy's ECS. Although, Bevy takes takes ECS a few... staircases (rather than steps) further with its own ECS. I really encourage everyone to read up on Bevy's ECS and check out the unofficial Bevy cheatsheet book; I'm certain at leat UE game devs will know how to appreciate how beautiful and ergonomic the design is, but others should as well). Aside: her ECS implementation is still safer than most C/C++ implementations used in published games, but that's a bit besides the point since that's the borrow checker doing its job. Anyway, the irony is that she much better explains the pitfalls of her own implementation details that you do and she also explains why they're "fine" sometimes. And it was kinda implied that it's fine (from what I remember) because it's no worse than what you end up doing in C++ or Java when implementing ECS, but at least it's safe in Rust. She acknowledges that there's probably better ways to do it. Here's a few links on some of the stuff I mentioned: - https://github.com/amethyst/legion https://github.com/amethyst/legion - https://bevyengine.org/learn/book/getting-started/ecs/ https://bevyengine.org/learn/book/getting-started/ecs/ Edit: formatting [1] Edit 2: I kinda phrased this poorly. I'm not saying the best way to implement tables or just ECS is this approach, but it's common enough approach used to avoid memory bandwidth/allocations in games.
• bodge5000 4y ago
  I think maybe the problem with explaining ECS is that the database-like part you mention is just given a passing mention, rather than being a critical part of the explanation. Obviously ECS is not a database which I think is why people avoid it, but it really helps for understanding it. Entities are basically tables (just the table, not the data in the table), components are fields/data in them and systems are the SQL you write for them. Its obviously not a perfect representation, especially for components, but it gets the rough idea out there. Maybe CSE is a better name for it. Its a longshot, but maybe entity being first in the list tricks people into thinking they play a big part, whereas actually they are, as you say, just an ID. Components are probably most important, then systems, then entities
  • Negitivefrags 4y ago
    I would say Systems are Tables, Components are rows, and Entities are Primary Keys.
    • bodge5000 4y ago
      Entities as primary keys is very good! Though as systems generally handle the data transformation, Im not sure they equate to tables
      • spoiler 4y ago
        IMO most analogies kinda fall short, but kinda makes sense in my head is: Entity as ID; Components as Columns, but only kinda; Systems as Application code or functions Tables in this database/ECS analogy are just tables here too, or memory rather. The data is often conceptually (and implementation wise) laid out as tables in ECS, too