Communication between systems

[OverShifted]

This is more of a design-pattern question.
I've read that direct communication between systems should be avoided (eg with event buffers, ...).
Now, assume that I have a game, that (at least) has two entities. A player, which has a HealthComponent attached to it, and a UI text, with a UITextComponent attached to it.

struct HealthComponent {
    float health;
};

struct UITextComponent {
    std::string text;
    // Maybe also font, color, etc.
};

I wanna sync these two components on those two entities. How can I do this without any kind of event buffer, but also without needing to lock one of these component's pools (in case my game is multithreaded), and without accessing any entity, other than the one my system is currently iterating?

[skypjack]

Well, the constraints exclude almost all possibilities. 😅
If the two components are on different entities and you don't want to access any entity other than the one currently iterated, I mean... 🤷‍♂️

[OverShifted]

That's the point! Another entity's data (components) might be far away from the current position of the iterator (assuming we are trying to access the same component type that we are iterating over, which is not the case in my example). so accessing it can trigger cache misses.

[skypjack]

Cache misses aren't a problem on themselves. Thousands and thousands of cache misses can turn into an issue. However, you can't avoid cache misses altogether. This sounds a lot like premature optimization. Is it?

[OverShifted]

Well... You are right. Assume this discussion is solved. (is there any way to close it like an issue?)

[skypjack]

Oh, no, you don't really close a discussion actually. 🙂
You can accept an answer to guide future readers or just let it be and that's it.
I can delete it if you like but I'm not opposed to having this around. As you prefer. 🤷‍♂️

[OverShifted]

Is it a good idea to split our game logic into "pure systems" and "impure systems"?
Whereas pure systems start by locking some pools and are guaranteed to only access those pools + their own internal state.
It also makes scheduling them easier in a thread pool or a similar parallel executor.

[skypjack]

If you know what resources a system wants to access, you can use a dependency solver to compute the best scheduling graph. The flow class does exactly this.
It's not a matter of pure or impure systems though. It's about resource usage and therefore optimal scheduling.

[OverShifted]

But sometimes we are not sure about resource usage.
The HealthSystem only modifies UITextComponent when the player is eg shot or healed. One solution is always assuming that we access UITextComponent, but it can be inefficient. Another approach is to only lock UITextComponent's pool when we really need it, which might block one of our threads.

I've also recently thought of non-blocking mutex locks with fibers and atomics.
I think it is a good idea to combine this, with the second approach mentioned above.
But isn't it against decoupling? Because a system (HealthSystem) is accessing another system's (maybe UITextRenderer?) data, which it was not iterating over.

Also, do you know how other people have dealt with this situation? I saw that Unity has special types of systems that react to events (like the "player health changed" event). But I'm not sure whether or not it is invoked immediately after an event has been triggered, or events are buffered somewhere.

[skypjack]

But sometimes we are not sure about resource usage.

I wouldn't really care about it. You define the best scheduling for the maximum overload. If a system returns immediately, it's not going to hurt your performance anyway.

But I'm not sure whether or not it is invoked immediately after an event has been triggered, or events are buffered somewhere.

Immediate execution ruins a little your mt and scheduling policy overall. Moreover, it's suffers from bursts, back and forth and similar. You don't really want something like that in the vast majority of cases, although there are situation in which you do need to react (almost) immediately.

[OverShifted]

Thank you! I got a better insight into the problem.