Comment by dustbunny
1 day ago
The real key pillar to this world view is putting the data first in your design of the algorithm.
So if your working on a physics engine and your optimizing collision detection, you think about the data in -> data out of the problem you are solving as the primary driver of how the code should be written.
You start with defining the data, and build from there.
Different types of applications all have different shapes of data so would have differently shaped optimal code. Eg) a physics engine would use some kind of spatial hash thing which can be optimized differently based on if stuff can be added/removed while it's running. A 3d renderer operates on big buffers of matrices and vertex data. A game is usually composed of some long lived things and a lot of short lived things.
The key message in Mike Acton's talk was:
"If you have different data, you have a different problem."
While ECS systems are not a panacea that solves all problems in a perfect data oriented way, they are generally more malleable than Object Oriented hierarchies. This means it's generally more feasible to write "near optimal" code in an ECS framework than in a mature Object Oriented code base.
But the key message isn't "use X framework", it's "start by defining the data".
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.)
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.
3 replies →
As I recall the reason for managing blocks of data this way was memory cache efficiency.
> 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?
> 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
2 replies →
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.
8 replies →
This is basically how I've always designed things, and I really feel like it's the best approach. Pick the right way to model data, and the algorithms will flow naturally from it. The cognitive load of reading "data" code rather than "algorithm" code is a lot lower in my opinion; reading through a bunch of declarative types like struct definitions isn't nearly as much work as reading through functions that operate on them, and moreover, it's a lot easier to spot any potential bugs in them because you don't need to maintain very much "state" in order to understand them. Maybe this is why I've generally found ECS conceptually pretty easy to wrap my head around (which is of course separate from whether it's easy to use or not, as that depends a lot more on both what the framework exposes and how a team chooses to use it).
> ECS
“Entity Component System”, for those like me who didn’t immediately think of it.
I feel like DoD is one of those things that only makes sense after you already believe in it. There's a sort of KISS epiphany that you have to go through which I don't think the commonly available info on DoD helps you to reach. It doesn't help that everything about it tends to get hung up on overly-specific C++ optimization advice.
While the idea is itself not without merit the problem is when people design these data oriented systems without abstractions and in fact it's often difficult to find good abstractions around the data the problem comes when the system, the data and functionality needs to change. There will be problems.
So while it's great to think about the data flow it's also important to think about the abstractions around it,.ie the (system) interfaces that let the system evolve without having to propagate changes everywhere while reaping the benefits of data orientation.
This is what ECS frameworks like Flecs can help with. They provide the tools and abstractions so you can write heavily modular code in this model. If you don't need the generic modularity, flecs will not feel like your gaining anything for the boilerplate you gotta write and the stuff you gotta learn, but if your making something huge that needs work for years, learning flecs is probably worth it.