3 ms·

This project is what I would call data oriented, as discussed yesterday on hn https://news.ycombinator.com/item?id=24506744 https://news.ycombinator.com/item?id

This project is what I would call data oriented, as discussed yesterday on hn https://news.ycombinator.com/item?id=24506744 https://news.ycombinator.com/item?id=24506744. It takes some parts of ECS but the UI is OOP-ish. I wonder if there is a good ECS UI architecture. I have been exploring this lately in Rust, and right now I have settled on jquery style selectors (don't laugh) where you have a generic entity builder and associate a selector (id + class list) with each entity. When an event fires, you check what selectors are associated with the focused entity and call the associated callbacks. I also do this for rendering. I'm not too crazy about this though. But I'm having a hard time figuring out how to do behavior composition in Rust.

the_duke 6y ago
> I wonder if there is a good ECS UI architecture. orbtk [1] is based on ECS. I have not used it, so I can't comment on the the quality of the architecture. [1] https://github.com/redox-os/orbtk https://github.com/redox-os/orbtk
- adamnemecek 6y ago
  I am not crazy about orbtk. I don't think it's not quite ecs, and I'm not crazy about the overuse of macros.
  - bronson 6y ago
    Why?
pjmlp 6y ago
ECS is also OOP. I guess someone needs to provide examples in Objective-C, Eiffel and CLOS to settle it up.
- DecoPerson 6y ago
  ECS is not OOP. In ECS, one system can touch the innards of multiple kinds of components directly, and one kind of component can be touched by multiple systems. Components only hold data and no logic, so in most ECS designs systems will know about the internals of components intimately. This shows a design can ECS-compliant while violating a key part of OOP methodology: encapsulation. You can use ECS and OOP in tandem by re-introducing encapsulation, as well as any other parts of OOP lost, but you need to be careful not to violate key parts of ECS, such as component not being allowed to have any “logic” (I out logic in quotes because it’s not well-defined: does logic mean ANY code or just... non-boilerplate code?) One must consider how a codebase will evolve over time, which requires putting yourself in the shoes of those who will be working on the codebase. What benefits does strictly confirming to both ECS and OOP bring? Does the introduction of ECS bring enough structure that the codebase can remain clean, performant, maintainable, portable, etc even without OOP? Is there some kind of hybrid of ECS and OOP where the rules of each are relaxed to create an even better structure? How do all of these potential designs actually look in practice, and is there clear mappings from problems in the problem domain to the philosophical structure being imposed? In games, it’s hard to map some of the problems to OOP structures (while remaining conformant, clean, performant, maintainable, portable). ECS isn’t perfect, but it’s much better. I find using C-style, OOP, Actor model, and ECS structuring for different bits of code the best solution. There isn’t a one-size-fits-all when it comes to those things, unfortunately. Though I believe there will be one day (that is: a language arrives which has a model that everything maps to nicely and we’re all happy using and we all say “Wow everything’s so simple now”)
  - pjmlp 6y ago
    I named Objective-C, Eiffel and CLOS on purpose. ECS is just game developers discovering about protocols from 1986, made popular in three well known languages with OOP support, and giving other name just because they don't get OOP has many ways of being implemented.
    - DecoPerson 6y ago
      Entities are a collection of component instances and nothing more. Components in ECS are data-only. Systems in ECS are logic-only. If you follow this strictly, then you cannot support encapsulation or data-hiding. There is no sole definition of OOP, but it is widely accepted that the ability to do encapsulation, including data-hiding, is a key part of OOP. Therefore, ECS is not OOP. QED If you’ve not seen the Overwatch team’s talk in which they discuss ECS, I can highly recommend it as a good resource to learn about ECS: https://youtu.be/W3aieHjyNvw https://youtu.be/W3aieHjyNvw There may be models commonly used in those languages you mentioned that are similar to ECS, but you seem to be implying that ECS is a form of OOP; it is not. Even if you implemented OOP using Structs of Arrays, a thread per object, or whatever you like, you cannot strictly conform with ECS’s requirement that “components have no logic” while also strictly conforming with OOP’s requirement that “objects should not know about each others’ internals” (object hierarchy).

the_duke 6y ago

> I wonder if there is a good ECS UI architecture. orbtk [1] is based on ECS. I have not used it, so I can't comment on the the quality of the architecture. [1] https://github.com/redox-os/orbtk https://github.com/redox-os/orbtk

adamnemecek 6y ago
I am not crazy about orbtk. I don't think it's not quite ecs, and I'm not crazy about the overuse of macros.
- bronson 6y ago
  Why?

pjmlp 6y ago

ECS is also OOP. I guess someone needs to provide examples in Objective-C, Eiffel and CLOS to settle it up.

DecoPerson 6y ago
ECS is not OOP. In ECS, one system can touch the innards of multiple kinds of components directly, and one kind of component can be touched by multiple systems. Components only hold data and no logic, so in most ECS designs systems will know about the internals of components intimately. This shows a design can ECS-compliant while violating a key part of OOP methodology: encapsulation. You can use ECS and OOP in tandem by re-introducing encapsulation, as well as any other parts of OOP lost, but you need to be careful not to violate key parts of ECS, such as component not being allowed to have any “logic” (I out logic in quotes because it’s not well-defined: does logic mean ANY code or just... non-boilerplate code?) One must consider how a codebase will evolve over time, which requires putting yourself in the shoes of those who will be working on the codebase. What benefits does strictly confirming to both ECS and OOP bring? Does the introduction of ECS bring enough structure that the codebase can remain clean, performant, maintainable, portable, etc even without OOP? Is there some kind of hybrid of ECS and OOP where the rules of each are relaxed to create an even better structure? How do all of these potential designs actually look in practice, and is there clear mappings from problems in the problem domain to the philosophical structure being imposed? In games, it’s hard to map some of the problems to OOP structures (while remaining conformant, clean, performant, maintainable, portable). ECS isn’t perfect, but it’s much better. I find using C-style, OOP, Actor model, and ECS structuring for different bits of code the best solution. There isn’t a one-size-fits-all when it comes to those things, unfortunately. Though I believe there will be one day (that is: a language arrives which has a model that everything maps to nicely and we’re all happy using and we all say “Wow everything’s so simple now”)
- pjmlp 6y ago
  I named Objective-C, Eiffel and CLOS on purpose. ECS is just game developers discovering about protocols from 1986, made popular in three well known languages with OOP support, and giving other name just because they don't get OOP has many ways of being implemented.
  - DecoPerson 6y ago
    Entities are a collection of component instances and nothing more. Components in ECS are data-only. Systems in ECS are logic-only. If you follow this strictly, then you cannot support encapsulation or data-hiding. There is no sole definition of OOP, but it is widely accepted that the ability to do encapsulation, including data-hiding, is a key part of OOP. Therefore, ECS is not OOP. QED If you’ve not seen the Overwatch team’s talk in which they discuss ECS, I can highly recommend it as a good resource to learn about ECS: https://youtu.be/W3aieHjyNvw https://youtu.be/W3aieHjyNvw There may be models commonly used in those languages you mentioned that are similar to ECS, but you seem to be implying that ECS is a form of OOP; it is not. Even if you implemented OOP using Structs of Arrays, a thread per object, or whatever you like, you cannot strictly conform with ECS’s requirement that “components have no logic” while also strictly conforming with OOP’s requirement that “objects should not know about each others’ internals” (object hierarchy).