Hacker News Reader

Comment by syntaxfree | Hacker News Reader

I don’t know what ECS is. You should define the acronym…

"Entity Component Systems" are common in game engine architecture, and there are a lot of variations on them - but they are a high-level architecture for making modular behavior in games. Generally they were thought of as "better than Object Oriented, because they very very heavily favor composition over inheritance."

The idea is that everything in your game - like Players, NPCs, Bullets - are Entities. Entities are simply an ID. That's their only property. Nothing else.

But there are Components - they have the data. For example, you might have a `PositionComponent` that has an `X Position` and `Y position` property. And maybe a `MassComponent` that has a property `Mass`. Somewhere in the framework (like a database table), a given Component will be related to a given Entity ID. The Entity therefore becomes a "bag of Components" through the relations.

Finally there are Systems. They do stuff with the data. One system might be `GravitySystem`. It doesn't care directly about `Entity`s, but can query the relations. It might ask for anything that has BOTH a `PositionComponent` and a `MassComponent` (it doesn't know which Entity it is for - it only gets the Components). It takes any `PositionComponent`s it gets and applies gravity: `component.y += gravity`.

The effect is that you can mix and match Components in weird and wonderful ways without having to hard-code behavior and rules for certain entities. You can obviously achieve this with other architectures too - but that's the primary goal of this one.

Correct me if I’m wrong, but isn’t one of the other motivations to store your data in CPU/memory management friendly ways? It’s not purely about developer ergonomics.

I think originally it was primarily about developer ergonomics - here's the first thing I ever read about them in 2007 where they tested it on Tony Hawk Pro Skater (http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy...). The CPU/memory management has been an on-going discussion ever since! Being able to process domains as flat arrays helps with cache misses - but there is a lot of other overhead, depending on how you designed everything.

Making it performant was one of the big problems initially, and it seems like the `Component Graph System` this thread is about trying to answer "how do systems efficiently process components?"... But I don't really get how it answers that actually.

As far as I understand it this is about the ECS equivalent of an INNER JOIN, that is, some variation on "iterate over all entities that possess instances of component A and B". Iterating over single component types in a system is trivial if they are separated into pools by types. When you have a system requiring more than one component, it isn't that easy to do better than iterating over all entities and checking whether they possess each required component. You can decide to maintain back references from components to their entities, but this means that you incur that management overhead pretty much globally. This essay says that doing away with entities altogether and just keeping direct links between your components is better. And it probably is when it comes to handling related components.

However, I believe (without having actually tried it) that this proposal has its own drawbacks. it's harder to thoroughly clean up all components that form a single entity. My suspicion is that it's easier to produce bugs like keeping e.g. a stray collision shape or sound source around while the other parts of an entity are removed. All you need for that to happen is an incomplete graph traversal.

I think CGS boils down to smart links between components, which may include SQL-like automatic checks: deleting components that refer to deleted components or components owned by the deleted component.

When this has to deal with a myriad of different component types individually while staying reasonably performant, this can easily become convoluted. This makes me believe that maintaining it becomes a bit of a error prone chore.

My reading of CGS is that it also means to boost ergonomics. Without "entity" concept of ECS triad, it should be 33% easier to understand how everything works, and what pitfalls exist.

Correct, you basically invert the typical component/object oriented approach, so each property relating to some Component isn't stored in memory alongside the game object it relates to (causing the values relating to e.g. physics to be scattered around memory) but is instead stored in an array (indexed by an id - the Entity id) with all the other values for this component type, making it much more cache efficient when a System (e.g. particle system, physics system) needs to perform updates on all components of a given type (which typically happens once per run loop iteration in a game engine). See also https://en.wikipedia.org/wiki/AoS_and_SoA

there are two distinct definitions of ECS, the first one given in https://news.ycombinator.com/item?id=27856030 is the "(entity-component-system) architecture" where there are entities, components, and systems, as distinct objects in your software. The second is "(entity-component) system" or "entity-component architecture" where the behaviour goes inside components (for instance, Unity3D gameobjects with their components).

It's good old procedural programming. Systems (procedures) are mutating state (components) grouped by a common ID (entity).

I'm no expert on any of this but that doesn't seem right; is it? IIUC, most procedural programming is nearly as wedded to the "one entity, one master data structure, one address in memory" frame of mind as OO is. (And the same is true of most functional programming, come to that.)

Entity Component System

commonly used in game programming

Reply on news.ycombinator.com