4 ms·
> Any kind of logic that goes like "IF something(component 1) THEN doSomethingTo(component 2) ELSE doSomethingTo(component 3)" What's the problem here? You wri
by ajuc 3y ago
> Any kind of logic that goes like "IF something(component 1) THEN doSomethingTo(component 2) ELSE doSomethingTo(component 3)"
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);
}
}
}
I think there's no need to deconstruct everything into smallest possible systems, this level of granularity is ok. You could also make the condition into something that can be selected by the query and remove the if.
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);
}
}
But that's only possible if you can make the condition be simply existence of some component in given entity. 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).
- TeMPOraL 3y agoYou seem to be coming from the "it's more like SQL" end of the spectrum. 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".
- ajuc 3y agoEven before hearing about ECS I wanted some kind of in-game in-memory database for game objects (preferably with history) so I could write quests and dialogs conditions in general way. 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?