Hacker News Reader

Comment by inigyou | Hacker News Reader

My experience with ECS is that you shouldn't use an "ECS system". You should just do ECS. Have an array of all your particles and then update all the positions according to the velocities. Don't use a framework where you do something like get_all_entities_with<Particle, Position, Velocity>(). Just have struct particles {vector<vec3> positions, velocities;}. Well, managing those parallel arrays gets pretty annoying, but you solve that with a parallel-array class template rather than a whole framework that promises to do everything. (You might not actually need parallel arrays anyway - AoS might work just fine here because you usually touch each field of each particle once per frame and exactly in order.)

View on HN

But why? This looks like the mother of all boilerplates. And for what purpose?

Also: just having stuff in an array or vector invites you to the ABA problem. You need a generation counter in there too, or else the array indice may get reused if something is deleted and another thing is reinserted at the same index. But that's yet another boilerplate that would easily be overlooked if you had to do everything manually.

Also: you seem to be saying this with C++ in mind. Do you think that applies to bevy_ecs too?

Modern Bevy has relationships to make sure that if an entity has a component that refers to another, it doesn't become dangling. It works a bit like foreign keys in databases. I think this makes ecs much more usable

(as an aside, there is a whole host of analogies between ecs and relational databases. entity archetypes are tables, entities are rows, components are columns, and systems are queries). Nobody tells people to just write their database from scratch though)

> You need a generation counter in there too, or else the array indice may get reused if something is deleted and another thing is reinserted at the same index.

It's really sounding like you're pretending not to know what your program does, which is one of the core OOP ideas that DOD refutes. In OOP you have an array of Shape and you pretend not to know which shapes your program implements, so the only way to draw them is to call ->draw() on each one. And you pretend you don't know anything about the lifetime of a shape so you use smart pointers everywhere to extend it as long as needed. In DOD you assert that you do know what shapes are available and what their lifetimes are.

I certainly don't know "what my program does" if it's a game where, at every frame of the simulation, thousands of entities might or might not be created, deleted and recycled depending on player inputs.

Can you describe a superior replacement for generation counters?

If you don't know what your program does, DOD asserts that you are a bad programmer and you should first figure out what your program does before continuing.

Sounds like you're writing a game engine, not a game?

You don't seem to grasp that handling individual entity state has a cost that has to be minimized and amortized.

A generation counter offers a good deal in many common cases: for the fixed small cost of incrementing the generation counter when an entity ID is assigned a trivial test, also fixed cost, can disambiguate successively recycled entities that share the same number and tell which one is current.

This adds up to work proportional to the number of distinct entities plus, assuming obsolete references are eliminated, work proportional to the number of references to entities, which is clearly very good. Do you recommend a different way to solve the same problem? There is at least one obvious one.

This is such a good explanation of OOP vs DOD

> This looks like the mother of all boilerplates. And for what purpose?

Isn't most programming? Isn't struct Particle {vec3 position, velocity;} also the mother of all boilerplates?

As I recall the reason for managing blocks of data this way was memory cache efficiency.

The problem is that there are a lot of subtleties to an ECS that these frameworks solve, and they perform better than a naive approach too. Your solution of a particles struct doesn’t even support a fundamental feature of ECS’s which is runtime composition. It’s really a different solution altogether, which is fine but it’s not a replacement for an ECS.

Often you don't have runtime composition and don't need it. By prematurely generalizing you're venturing close to OOP territory.

“Prematurely generalizing” is now an OOP thing? Are we just using OOP as a term for anything bad now?

Ooh here is a controversial one. DOD is premature optimization. Most programs don’t have enough data where the storage and access is a factor for performance. In fact it might be slower to use DOD.

I don't think that's all that controversial. DOD comes out of the field of video games where people were frustrated by only being able to process ten thousand things sixty times per second and wanted to process ten million things sixty times per second. While it's also been used to speed up things like the Zig compiler, it's definitely not necessary for all software.

One of the ideas in OOP that DOD is explicitly refuting is pretending not to know what your program does. You know which subtypes exist in your program and you shouldn't treat them generically as supertype instances except when that is actually optimal. On this axis, both ECS ideology and OOP ideology are opposite to DOD ideology. ECS happens to align with DOD in that it prefers big linear arrays, but it does not align in pretending not to know what combinations of arrays are used, which is similar to pretending not to know what subtypes of Shape exist.

No amount of ideology can fill L1 cache.

You don't always know what subtypes will exist, either at runtime or in future iterations of the program.

> Are we just using OOP as a term for anything bad now?

Different paradigms come with different pathological cases. I've had to deal with Scala programmers whose notion of FP is making everything generic on the Monad it abstracts over, even when it'll only ever be instantiated on the one effect system the team uses. Nonsensical levels of generality is one of the classic OOP pathologies, and is the reason why we have aberrations like the AbstractSingletonProxyFactoryBean[0].

0. https://docs.spring.io/spring-framework/docs/current/javadoc...

>"Nonsensical levels of generality is one of the classic OOP pathologies"

I think it has nothing to do with OOP which I find very convenient for some domains and not so much or even opposite for others. These "Nonsensical levels" of anything is a disease which is called Architecture Astronauts Syndrome and victims apply it to any paradigm

OOP can be convenient for prototyping a game because you can just write new stuff at high velocity like "yeah a cow is a pig but it's brown and drops leather, a skeleton is a zombie that shoots arrows, and a client is just a server with graphics". Figuring out the right decomposition right from the start can be harder.

It is usually possible to design a representation where cows and pigs are the same thing, either Animal class instances or equally unified other data structures, and their differences are data (e.g. weight, length, one of several colour patterns).

oh my god. I thought that class was just a joke, but it's real.

> My experience with ECS is that you shouldn't use an "ECS system"

Why? Flecs, for example, is pretty sick imo.

Because the people who made them got nerd trapped fucking around with ECS and never shipped a product

This is a reductive ad hominem, not a first principals examination.

No it’s not an ad hominem.

The first principles examination is you need an array of structs.

If your goal is to ship a product you would use this proven technique. It’s shipped more AAA and small games than any other.

The ECS is a hobby project which solves problems unrelated to your goal. (Making a cool ECS) And because it was not engineered with the goal of shipping you’re sitting on a pile of unknowns when you try to.

Proven technique is an Appeal to Authority. You have offered no real first principal evidence for your claims. Here's some evidence in favor of flecs:

I find value in its reflection and serialization system, as well as it's pipeline API.

Games require far more than a bunch of arrays. The simulation code itself is dwarfed by the UI, VFX, animation and scene layout code. The APIs in Flecs have a lot of value for these "not the core game" use cases.

Conversely, the amount of boilerplate you have to write to stand something up in Flecs is massive. And the use of macros in Flecs APIs tends to break editor auto complete. And the learning curve is very big. And the output code just looks very different from Orthodox C.

Getting nerd trapped fucking around with ECS is a real risk. The rabbit hole goes deep. But the library itself is valuable, powerful and well done.

This is my honest thoughts on ECS systems derived from first hand experience.

Great. Let me know when your product comes out.

Reply on news.ycombinator.com