20 ms·

Sure ECS is object oriented in the same way C99 is. Yeah, technically you are building up some OOP functionality, the same way you emulate constructors and inst

Sure ECS is object oriented in the same way C99 is. Yeah, technically you are building up some OOP functionality, the same way you emulate constructors and instance methods in C by making functions to init data structures and functions that take references to a struct to modify it's data. That doesn't make C object oriented. In ECS you are decoupling data from behavior, which is basically the entire paradigm of languages like rust and go. You could argue that by defining systems in a way that they run on certain components you are defining behavior and data in one, but I think that's a stretch. It clearly differs from OOP when I have 2 entities with components that have overlapping and non-overlapping systems. If e1 has components c1 and c2, and e2 has components c2 and c3, and c1 and c2 are used in system s1 while c2 and c3 are used in system s2, I don't see how you would model that with OOP without adding data to classes that don't need it. In OOP both e1 and e2 would need all the logic from s1 and s2, or needlessly specialized versions of s1 and s2. Which would be solved via inheritance (either class based or interface based). In ECS your data exists in an array of components and any part of your program can operate on any component however it wants. I've never needed message passing for anything I've worked on. That's not to mention that the main benefits of ECS have nothing to do with language paradigm. ECS main advantage is cache coherency and easier parallelism.

meheleventyone 5y ago
You're too worried about the underlying implementation. Think a bit more about the runtime expression in terms of the resulting Entities and how the set of components linked to them defines data and behavior and what you could do conceptually to extend that. > That's not to mention that the main benefits of ECS have nothing to do with language paradigm. ECS main advantage is cache coherency and easier parallelism. ECS is not data-oriented by default. :) I have a long post explaining things in this thread here: https://news.ycombinator.com/item?id=27663218 https://news.ycombinator.com/item?id=27663218
- adamdusty 5y ago
  My comment has nothing to do with implementation. We're talking about ECS in the context of DoD so I'm not sure what relevance being data-oriented by default has. It seems like you're just confusing the concepts of ECS, DoD, and composition. Your entire post on ECS is, "If you don't use DoD with ECS than you're not using DoD". Well yeah.. obviously? If you implement an ECS and then use it without data-oriented structures, then yes obviously you don't have data-oriented design. You're creating a strawman. You're saying if you take ECS, remove the idea of storing components independently of entities, and pass them in an inefficient manner to systems, then you don't have DoD. ECS isn't inherently DoD, literally nothing is. Arrays aren't inherently cache friendly. There's nothing stopping you from making a language that allocates data randomly throughout reserved memory and every array element points to each location. No one is arguing ECS is inherently DoD, but it is a good design to facilitate DoD. > For example we might want to do damage to another entity entirely. Add a damaged component to the entity to damage. Consume damage component in a system. > Or we might want to look up the properties of the piece of ground we're stood on Use a position component on the entity standing on the ground. Consume the position in a system and look at the properties of the terrain map at that position. Even simpler for grid based maps. > We're also ignoring interacting with other components or the world and how that might work You interact with other components by defining interactions in systems based on those components. You've created an ECS in a way that doesn't take advantage of any of the benefits, and complaining that all you're left with is the disadvantages.
  - meheleventyone 5y ago
    The approach I talk about with archetypes is the one used by Unity and many open source ECS implementations. It’s a pretty standard way to solve the issue.

meheleventyone 5y ago

You're too worried about the underlying implementation. Think a bit more about the runtime expression in terms of the resulting Entities and how the set of components linked to them defines data and behavior and what you could do conceptually to extend that. > That's not to mention that the main benefits of ECS have nothing to do with language paradigm. ECS main advantage is cache coherency and easier parallelism. ECS is not data-oriented by default. :) I have a long post explaining things in this thread here: https://news.ycombinator.com/item?id=27663218 https://news.ycombinator.com/item?id=27663218

adamdusty 5y ago
My comment has nothing to do with implementation. We're talking about ECS in the context of DoD so I'm not sure what relevance being data-oriented by default has. It seems like you're just confusing the concepts of ECS, DoD, and composition. Your entire post on ECS is, "If you don't use DoD with ECS than you're not using DoD". Well yeah.. obviously? If you implement an ECS and then use it without data-oriented structures, then yes obviously you don't have data-oriented design. You're creating a strawman. You're saying if you take ECS, remove the idea of storing components independently of entities, and pass them in an inefficient manner to systems, then you don't have DoD. ECS isn't inherently DoD, literally nothing is. Arrays aren't inherently cache friendly. There's nothing stopping you from making a language that allocates data randomly throughout reserved memory and every array element points to each location. No one is arguing ECS is inherently DoD, but it is a good design to facilitate DoD. > For example we might want to do damage to another entity entirely. Add a damaged component to the entity to damage. Consume damage component in a system. > Or we might want to look up the properties of the piece of ground we're stood on Use a position component on the entity standing on the ground. Consume the position in a system and look at the properties of the terrain map at that position. Even simpler for grid based maps. > We're also ignoring interacting with other components or the world and how that might work You interact with other components by defining interactions in systems based on those components. You've created an ECS in a way that doesn't take advantage of any of the benefits, and complaining that all you're left with is the disadvantages.
- meheleventyone 5y ago
  The approach I talk about with archetypes is the one used by Unity and many open source ECS implementations. It’s a pretty standard way to solve the issue.