ECS is like any other framework. It is a tool or system, for organizing your efforts. Be very liberal with using it in its intended scope. Be judicious when its at the edge of its scope. Be very skeptical when its outside of its scope.
On either end of the spectrum, there's much less flexibility. The "SQL side" is optimizing things for bulk operations[0] and flexibility coming from composition[1]. The "data-oriented side" is optimizing for performance, and it so happens that stuffing data that's processed together into arrays you can just scan in a cache-friendly way, also yields a component-like division of data.
Both those approaches are quite inflexible. They do kind of meet in the middle, as they yield similar data organization, but I'm increasingly convinced this is a surface-level, entirely incidental similarity. Philosophically, the two extremes of "ECS" are entirely unlike.
--
[0] - Again, AFAIR, ECS originally came from MMO world, where they do use relational databases for storing game state.
[1] - Also reason to use databases if you're making an MMO, as relational tables are known quantity, while serializing polymorphic object graphs is plain annoying.
What's the problem here? You write a system that queries these 3 components and then call regular functions. In bevy (a rust ECS framework) it would look sth like this:
fn complex_system(
query: Query<(&Component1, &Component2, &Component3)>,
) {
for (c1, c2, c3) in query.iter() {
if condition(c1) {
doSomethingTo(c2);
} else {
doSomethingTo(c3);
}
}
}
fn complex_system2(
query: Query<&Component2, With<ConditionFullfiled>>,
) {
for c2 in query.iter() {
doSomethingTo(c2);
}
}
fn complex_system3(
query: Query<&Component3, Without<ConditionFullfiled>>,
) {
for c3 in query.iter() {
doSomethingTo(c3);
}
}
Yes, in that design, my questions aren't hard - but then, this design doesn't give you all the touted performance benefits, since in a data-oriented ECS, you're supposed to iterate over arrays of values directly (Rust may be doing some magic here I don't understand, though).
> Could be improved with systems that query based on values of components and indexing could be added, of course, but I haven't seen that kind of ECS yet).
I tried to implement exactly that the other day, including with conditions on values; my overall approach to that was that each Query/Condition had its own array of entities, and all the Query/Condition array of entities were updated on operations like adding/removing components, so the checks are done only when their outcome could changed - which is less frequent than "for every entity, every frame".
It is at that point I realized I'm just reinventing database indices and materialized views, and papering them over with Lisp macros to remove boilerplate - which led me to ditch that ECS implementation, and go for "let's just move all game state data to in-memory SQLite database, and see how it works".
Like "If player seen this kind of a monster already and there's at least 4 people in the room and someone there has this kind of weapon equipped - enter this branch in dialog and progress the quest".
Traditional solution seems to be hardcoded special cases for all conditions which probably has better performance but sucks so much when you're implementing quests and dialogs. You tend to avoid writing quests that require new kinds of data so you end up with fedex quests and murder quests and that's it :/.
How well did this SQLite idea worked out for you?
I wish I knew the solution to this exact problem. IMO this is the central issue that stops pure ECS from being useful.
I spell that out to highlight the part about ECS being a very ill-defined programming pattern - three parallel replies, the different points on the spectrum :).
Beyond that, thanks - I'm relieved to know I'm not the only one with this problem.
You can absolutely access multiple components in a system, for some reason you think a component and a system must have a one to one relationship, when really it’s many to many.
The only caveat is that you have to think carefully about the order that some of your systems are executing in the game loop, since you want to make sure component data has been updated appropriately for later systems to act on.
ECS is really the best way to make games. It lends itself well to rapid iteration and experimentation of new game concepts.
A little bit of nuance would go a long way.
Even in games where ECS is a good match, having to implement a boss with ECS is wasteful in terms of dev time and performance: You have to create components and matching systems unique to the boss, where with a traditional approach you just have to create a single Boss class.
You could create a database table called "Boss," that contains all the Boss components. Then for each system, you create a function that operates on a Boss.
Having a one off actor is really limiting. You can create several boss components and build entire permutations of bosses just by mixing and matching them up, without writing specialized code. Designers can put together the entities without developer input.
The biggest such question is: how the hell do you handle "cross-cutting concerns" in an ECS architecture, especially in the data-oriented programming version, where "cross-cutting concerns" are basically any kind of logic ("system") that needs to access more than one component of an entity at the time, especially if it does so conditionally? Like e.g.:
- Physics, rendering, animation, and game logic all need to access some subset of the same position, orientation, dimensions, velocity, acceleration, mass, tensor of inertia, etc.
- Any kind of logic that goes like "IF something(component 1) THEN doSomethingTo(component 2) ELSE doSomethingTo(component 3)".
How are you supposed to preserve data locality in such cases? Is it even theoretically possible?
I may have some fundamental misunderstanding about the definitions here[3], but I haven't found any clear answer to the questions above, whether theoretical or practical. Back when I last looked, couple years ago, I couldn't find any non-toy game written ECS-first and with source available to study. Maybe this has changed now.
--
[0] - Which, as far I recall, was the original idea behind the pattern. It's also a very interesting one in general - if you squint, a lot of code all of us write for our projects is just half-baked attempts at setting up specific indexes and hand-rolling queries to a bunch of vectors, hashmaps, or (gasp) object graphs.
[1] - AKA "data-oriented programming", in this case mostly preferring "Structs of Arrays" over "Arrays of Structs".
[2] - One of them was literally just "let's store all game state in an in-memory SQLite database, because guess what, it's actually fast enough to be queried at 60 FPS!".
[3] - In my defense, most of the guides, tutorials and articles I read back in the day were themselves confused between "SQL approach" and "SoA approach" (see [0]), or worse, mixed in "whatever abomination Unity passed as ECS back then" and even something semi-related from .NET world. It took me a lot of time to understand that everyone's using their own blend of all those ideas, and this left me unsure about what one's really supposed to do.