Hacker News Reader

Comment by hcarvalhoalves | Hacker News Reader

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

View on HN

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?

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

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.

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.

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.

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

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

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.

Reply on news.ycombinator.com