ECS can mean many things. the idea that you put components together (physically, in memory) and try to set up your processing so stuff is processed together may be quite natural.

but actual ECS systems add a lot of stuff on top that's not very natural (in any programming paradigm, not just OOP).

it's about enabling you to add and remove components at runtime, manage complicated relationships between entities and their components in a generic sense. this has all the advantages and disadvantages that those kinds of abstractions bring. bad if you don't need it, good if you do.

no it doesn't. most OOP approaches to game dev end up with some kind of mixins or components that carry methods (like Unity).

I think the future of game dev may end up being immutable and event driven actually... but I’m yet to see anything beyond a prototype.

In 2D games it is often times some kind of object hierarchy (scene graph, display list, nodes) imposed by the engine/library, which never plays well with ECS IMO. In these instances I think it is better to just inherit from a carefully thought out god object (yeh yeh I know).

If you are using a low level rendering library, or immediate mode library, you can more easily define your state however you want, but still ECS incurs massive overhead compared to basic arrays of structs. If your language allows structural typing then ECS seems to me as having little benefit.

> ECS incurs massive overhead compared to basic arrays of structs

This is a weird take, an ECS can have its components listed as a basic array of structs as well. None of this is mutually exclusive.

I should have wrote array of “entity” structs.

The reason I say ESC incurs more overhead is because I find it involves a whole bunch of access patterns to add, remove, update, and query the data. Comparatively arrays of entities mostly just involves basic loops.

Still a weird take, as the ECS approach makes it much easier to do AoS vs SoA which is actually great for access/loop performance.

I'm sure there's examples where a non-ECS approach beats out an ECS approach. But to say that ECS incurs more overhead generally is just plain false.

ECS are obviously more efficient for traversing a subset of your entity data if that subset resides in one small component, simply because the total span of bytes accessed is lower and the cache hit rate is higher.

I would be more inclined to claim the opposite: that ECS systems are generally MORE performant than arrays of entities, but you can really only be wrong when making general claims like that.

> but still ECS incurs massive overhead compared to basic arrays of structs

I actually know of quite a few projects that use ECS as the foundation for a low level rendering library precisely because it lets you iterate over a bunch of plain arrays, but with more flexibility.

The overhead of an ECS depends on many things, but if you have lots of entities with similar components, the overhead per entity can be quite small.

A collection (e.g. an array or a hash map) that stores things. Maybe more than one collection like that, different for each type of entity: monsters, items, etc. (Separate code paths to handle these different types of things.)

Keeping indexes/keys for references, and loops over these collections can do a lot without any upfront complexity of an entity system.

No actually the ECS approach is more or less the exact opposite of (naive) OOP. In (naive) OOP you design objects for your domain, like an enemy, or a bullet, or an explosion. In ECS, you define abstract entities and compose data (and potentially behavior) on top of them, so there's no single "enemy" object, there's an entity that composes AI, geometry and sound effects to make it behave as an enemy.

In general, for large systems, this is a great way to achieve decoupling, where the naive OOP approach would get you stuck quickly.

One view on the OOP <=> ECS relationship is that ECS is an exploration of/recreation of/divergence from alternative "natural" OOP systems outside of the "dominant OOP strain" of C++ (and family) (re-)implemented on top of C++-style OOP.

There are hints (and needs) in ECS systems of post-hoc/runtime Prototypical inheritance rather than pre-hoc/design time Class based construction.

There are facets of ECS that resemble concepts like mixins and pattern matching and multi-dispatch and message passing rather than "pure" "C++ VTABLE" dispatch.

Some of these things arise more naturally in other branches of the OOP family tree: the Common Lisp Object System can do some of these things out of the box; Smalltalk and its descendants (even Objective-C) were easier to mold to ECS-like configurations; IO had interesting things to say about this style of OOP; even much-maligned JS' "strange" branch of Prototypical OOP has a bunch of low-level tools that make ECS "less of a need" in JS because there are ways to do them more "naturally".

Certainly, though, in C++ and closer-related derivatives (even Java and C#) ECS isn't as naturally a pattern, which is why it often has need for strong "frameworks" and why there are often multiple, competing ones to pick from.

Do you have any references you could give on this subject? I think I have a fair idea of all the object systems you listed (and a couple of others), but I understand very little about ECS. And every time I read about ECS I feel like it should be expressible as some flavour of OOP much as you say here, but I struggle to express that in a concrete manner.

In particular, keeping a single object’s state in several separate memory regions seems atypical (prototypes—or Self’s “traits objects”—are usually stateless even if they don’t have to be); and I can’t think of any way to map iteration over all objects that have parts of a specific kind, often mentioned in expositions of ECS, to a conventional OOP concept (seems relational if anything).