Hacker News Reader

Comment by cardanome | Hacker News Reader

ECS is for me the natural way to design games. I wouldn't even know to design them any other way.

I started game dev with love2d which is a pretty minimalist framework. When I participated in a game jam, I needed a very flexible system that would allow for quick prototyping and would handle many different entities. I ended up writing something which I later realized would be an ECS system. It worked great and I would copy it over for other games.

I know there is that ECS-faction that is talking about performance benefit and stuff but honestly I don't care. I don't even know most of the terminology these people use. I just use ECS to structure my code while being very flexible. I use OO in other domains but it would never occur to me to structure games that way. OO just feels way to brittle for a domain where you do lot's of experimentation and can't really know what you will need and how your entities might end up looking.

View on HN

ECS and OOP are sides of the same coin, although apparently it is only visible to those that read SIGPLAN papers.

"Component Software: Beyond Object-Oriented Programming"

https://www.amazon.com/-/en/Clemens-Szyperski/dp/0201745720

One of the first publications on the matter.

Not sure I get what you mean. As I see it, ECS has more of a relational character. Feels more like data pipeline than operations/messages on objects. I think the mental model matters the most here and that depends on how you think of objects. But then any attempt of defining OO objectively seems to be futile, there are conflicting historical and contemporary notions plus a whole bunch of jargon on top, depending on who you're asking.

As an example you could say that Scheme is more object oriented than Java or vice versa and there would be valid, typically cultural reasons for each.

In terms of ECS what kind of happens is that, yes, you have a model of an entity and can think of that as an object, but that is a projection of a set of components or a relation. You're not really talking to the entity as a whole all that much anymore. And it's not just "it satisfies this set of interfaces" either. Your systems literally define data transformations, each on a focused set of related components that matter to a system, which seems kind of the inverse of hiding data behind object interfaces.

That is when data oriented programming gets into the equation.

Classical ECS as it originally appeared on the literature is coding against interfaces, COM or Objective-C protocols style.

So yeah, one composes those interfaces together, there is no class inheritance, only composition, delegation, and a system is composed from a jungle of such components.

It is also a reason why DirectX is COM based, instead of basic Win32 calls.

What do you mean by classical ECS? I’ve always read that the Entity-Component-System approach originated in the gaming industry, completely unrelated to what you wrote about COM, etc.

Yes, the famous GDC talk.

Usually most stuff in game development tends to be rediscovered, as most people don't come from CS backgrounds.

> There has been an explosive growth in component software technologies since the first edition of this classic book was published. The advent of EJB, J2EE, CORBA 3, COM+ and the .NET framework are evidence of a maturing market in component software that goes 'beyond OOP'.

This book seems to be discussing distributed object systems, which is a sense of the word "component" that has little or nothing to do with the sense used by game developers in reference to the ECS architecture. Distributed object systems are designed to enable an object-oriented design philosophy to be used for a system which spans multiple address spaces or machines. The entity-component-system architecture is a methodology for organizing data layout and program functionality, usually within a single address space on a single machine, where the data associated with a given entity is spread across multiple components or subsystems and associated by index relations (much like a relational database), rather than being all grouped together in one place (as encouraged in OOP).

These two concepts (distributed object systems and ECS) are designed to solve different problems, they are generally used in different scenarios, and they apply at different levels of system organization. There is so little resemblance between the two that I have to conclude someone calling them "sides of the same coin" is either completely unfamiliar with one of them or is being deliberately misleading.

I also did not state that book was the canonical ECS model, rather that it was one of the first sources to move into discussing components instead of classes.

COM and DirectX aren't distributed object systems, nor Objective-C protocols, for example.

Don't confuse COM with DCOM and COM+.

Then there are the component models based on traits, mixins, patterns, message passing, type classes,... plenty of variants scattered around SIGPLAN and ECOOP papers.

You are still conflating two totally unrelated things.

The book is one of the first sources to move into discussing "components," as in coding against interfaces/protocols/traits/etc.

ECS deals with "components," as in pieces of data composed using a relational model. This has nothing to do with interfaces or protocols whatsoever! It is practically the opposite thing- working directly with raw data, with no abstraction boundary.

You can't just pattern match on the word "component" and expect it to mean the same thing to everyone.

That is the next step, data oriented programming, which many confuse with ECS, as they tend to be used together.

I am not talking about data oriented programming. With or without that sort of memory layout optimization, ECS "component" still refers to un-abstracted chunks of concrete data rather than interfaces/protocols/etc.

Let's step back even further and consider Unity's pre-DOTS "entities" and "components." These do not take the data oriented approach, are not typically even classified as ECS (e.g. because they lack the System aspect of that design). However, the components are clearly chunks of concrete data (transforms, meshes, rendering parameters, rigid bodies, etc.) rather than interfaces/protocols.

This is the sense in which ECS means "component." That book is not relevant to this sense.

A book that I clearly referred it was only one of the first ones that somehow started talking about this, I never stated it was the definition of ECS.

Apparently making the point about how relevant this specific book is, is what matters in this whole thread.

It didn't start talking about "this." It started talking about something unrelated that you mistook for "this."

Reply on news.ycombinator.com