3 ms·

IMO, ECS is a better way of doing OO (even on a non-OO language) than OO languages themselves: - Avoid the inheritance vs. composition issue - Entity as a fir

IMO, ECS is a better way of doing OO (even on a non-OO language) than OO languages themselves: - Avoid the inheritance vs. composition issue - Entity as a first-class concept (no more Object vs. "Just Value Object", confusion regarding equality of objects, object hash methods) - System as a first-class concept (not just a consequence of a call stack between multiple inter-dependent objects) - It serves much of the same purpose of the Flyweight Pattern - Naturally conductive of functional programming This particular implementation is interesting, it introduces some additional pieces (Component Manager, System Manager).

politician 4y ago
That's a really interesting take. I'd love to see an experimental language based around this approach because I think it could really push your idea much further than a library.
drittich 4y ago
I have a similar feeling, but have not converted that feeling into building production code that way yet, partially because it conflicts with a large amount of existing code that I work on in terms of design. It definitely has tradeoffs, but I found a large class of problems went away when I used it.
klabb3 4y ago
I've read up on ECS thrice now, (but never used it because I don't do games) and I really WANT to like it, and I feel it does have value in other domains. But... I realize every time that I forget what an entity, component and system really "is" (i mean to be fair the naming is almost satire of genericness), and the abstraction doesn't stick to my brain in a way that I had hoped. Kinda similar to how monads don't stick, and fades away over time (if you're not doing FP). Usually, this is a red flag for abstractions, but perhaps the material I've read has been poorly written. Does this feeling go away when you're used to it? Does it just feel natural and obvious after a while?
- ChadNauseam 4y ago
  You need to use it to have it stick. If you like Rust, spend 30min playing with bevy and you’ll be set.
ummonk 4y ago
One of the core tenets of OO is encapsulation. ECS rightly treats encapsulation as a bad thing, because data (i.e. entities) should not be encapsulated in the components and systems which operate on them.
- nine_k 4y ago
  I'd say that encapsulation may be problematic because it's essentially hidden mutable state, which makes reasoning about systems hard(er). An attempt to hide private pieces of data may be counter-productive when an entity system tries to globally optimize the handling of state. A lack of protection though may result in inadvertently depending on parts of data that are a fleeting implementation detail; tight coupling has its own problems.
crabmusket 4y ago
This article makes a convincing argument that ECS is not necessarily as opposed to OOP as some proponents would have you believe: https://www.gamedev.net/blogs/entry/2265481-oop-is-dead-long-live-oop/ https://www.gamedev.net/blogs/entry/2265481-oop-is-dead-long... > I've been a long-time ranter in many "ECS" threads on the forum, partly because I don't think it deserves to exist as a term (spoiler: it's just a an ad-hoc version of the relational model), but because almost every single blog, presentation, or article that promotes the "ECS" pattern follows the same structure: > 1. Show some terrible OOP code, which has a terribly flawed design based on an over-use of inheritance (and incidentally, a design that breaks many OOD rules). > 2. Show that composition is a better solution than inheritance (and don't mention that OOD actually teaches this same lesson). > 3. Show that the relational model is a great fit for games (but call it "ECS"). > This structure grinds my gears because: > (A) it's a straw-man argument.. it's apples to oranges (bad code vs good code)... which just feels dishonest, even if it's unintentional and not actually required to show that your new architecture is good, but more importantly: > (B) it has the side effect of suppressing knowledge and unintentionally discouraging readers from interacting with half a century of existing research. Sorry for the lengthy quote, but I reckon this article is a classic.

politician 4y ago

That's a really interesting take. I'd love to see an experimental language based around this approach because I think it could really push your idea much further than a library.

drittich 4y ago

I have a similar feeling, but have not converted that feeling into building production code that way yet, partially because it conflicts with a large amount of existing code that I work on in terms of design. It definitely has tradeoffs, but I found a large class of problems went away when I used it.

klabb3 4y ago

I've read up on ECS thrice now, (but never used it because I don't do games) and I really WANT to like it, and I feel it does have value in other domains. But... I realize every time that I forget what an entity, component and system really "is" (i mean to be fair the naming is almost satire of genericness), and the abstraction doesn't stick to my brain in a way that I had hoped. Kinda similar to how monads don't stick, and fades away over time (if you're not doing FP). Usually, this is a red flag for abstractions, but perhaps the material I've read has been poorly written. Does this feeling go away when you're used to it? Does it just feel natural and obvious after a while?

ChadNauseam 4y ago
You need to use it to have it stick. If you like Rust, spend 30min playing with bevy and you’ll be set.

ummonk 4y ago

One of the core tenets of OO is encapsulation. ECS rightly treats encapsulation as a bad thing, because data (i.e. entities) should not be encapsulated in the components and systems which operate on them.

nine_k 4y ago
I'd say that encapsulation may be problematic because it's essentially hidden mutable state, which makes reasoning about systems hard(er). An attempt to hide private pieces of data may be counter-productive when an entity system tries to globally optimize the handling of state. A lack of protection though may result in inadvertently depending on parts of data that are a fleeting implementation detail; tight coupling has its own problems.

crabmusket 4y ago

This article makes a convincing argument that ECS is not necessarily as opposed to OOP as some proponents would have you believe: https://www.gamedev.net/blogs/entry/2265481-oop-is-dead-long-live-oop/ https://www.gamedev.net/blogs/entry/2265481-oop-is-dead-long... > I've been a long-time ranter in many "ECS" threads on the forum, partly because I don't think it deserves to exist as a term (spoiler: it's just a an ad-hoc version of the relational model), but because almost every single blog, presentation, or article that promotes the "ECS" pattern follows the same structure: > 1. Show some terrible OOP code, which has a terribly flawed design based on an over-use of inheritance (and incidentally, a design that breaks many OOD rules). > 2. Show that composition is a better solution than inheritance (and don't mention that OOD actually teaches this same lesson). > 3. Show that the relational model is a great fit for games (but call it "ECS"). > This structure grinds my gears because: > (A) it's a straw-man argument.. it's apples to oranges (bad code vs good code)... which just feels dishonest, even if it's unintentional and not actually required to show that your new architecture is good, but more importantly: > (B) it has the side effect of suppressing knowledge and unintentionally discouraging readers from interacting with half a century of existing research. Sorry for the lengthy quote, but I reckon this article is a classic.