[SeanBoocock]

Speaking from experience, the hardest part about game development isn’t figuring out how to (efficiently) build something, it’s deciding what to build in the first place. The second hardest problem is getting everyone on board with the answer to that. The third is figuring out how to build the content 1000x to support that. Way, way down the list is the runtime performance for a gameplay system.

True ECS systems - and not frameworks that just have things called “entities” which own things called “components” - are hard to work with, almost by definition (ie you have to be very explicit about data layout and dependencies). They add a lot of friction upfront to solving the important and hard problem(s) while purporting to solve something that isn’t actually an issue in most cases (guess what, your N is likely < 10, modern cpus go brrr, etc). If you are working in a domain where you already know something about the performance and input size characteristics - particle systems are the go to example - then maybe ECS makes sense as a framework. Otherwise, I’d advocate for simpler oop approaches with heavy composition.

[arc619]

> just have things called “entities” which own things called “components” - are hard to work with, almost by definition (ie you have to be very explicit about data layout and dependencies).

My experience has been completely the opposite to this. In fact being explicit about data layout and dependencies is a hallmark of a OOP rather than ECS.

In compiled languages the dependencies in object hierarchies are fixed at compile time and can only support tree designs, so you have to plan ahead for all possible combinations to even build relationships with OOP, even with composition (because its static).

With ECS everything is decoupled so you can write a system that does X and it affects nothing else.

This leaves you free to design by isolated processes rather than by code structure, and entities naturally do whatever processes their data supports dynamically.

Makes iterating designs incredibly rapid and offers design options that are convoluted and fragile with OOP such as completely changing what an entity does at run time.

For instance you can move the keyboard input component from a player entity to a monster or even something as random as a building and it just works - you didn't have to design for it, you don't even need to change any code. Remove the health component, now the entity is invincible, remove the gravity component and now it can fly, add a homing component and now it seeks a target. All this is trivial and can be done at run time. Want flying flaming lampposts the player can control? Just combine the appropriate components. Need to drastically pivot the design? Vastly less work than OOP - sometimes just a case of changing the data in components or their combination in entities without touching systems. Don't need this flexibility? Still gives you a more modular and less coupled design.

As a nice bonus this flexibility comes with more cache friendly performance than static hierarchies to boot.

[SeanBoocock]

All of what you describe in terms of data driven entity composition is possible without a true ECS framework. That is what I was referring to and more or less what Unreal or Unity (base, not dots) offer.

ECS is one of the better examples of something that sounds good on paper but in practice, and crucially in production, doesn’t provide the sort of benefits that outweigh the friction it imposes.

There seems to be a myopia online around things like ECS, data oriented programming generally, writing games in C (as opposed to that horrible high level monstrosity C++…), optimization, etc. Those are all fine things in and of themselves (though I’ve never understood the opposition to C++ as anything other than nostalgia), but they are often discussed without being ground in the considerations of building a game. If you want to build a tech demo, great! However, the needs of building a game with hundreds of people, most of whom aren’t engineers, and to a quality/production level that even “simple” things become complicated, demand other things take precedence. I lead a team that facilitates a creative project, not to satisfy my technical desire to have optimal cache or thread utilization in every piece of code. The right tool is the one that gets you closer to the creative goal, and for gameplay code most of the time it probably looks like what Epic or Unity are shipping with their entity frameworks.

[danybittel]

And if N > 100000, you probably want to use the GPU, ie. a particle system.