Is sending a message and waiting for subsequent affected systems to generate events an anti-pattern?

I know that messaging between systems is not best practice, but please bear with me. Say you have a message a that is queried by system A, which creates a message b that is queried by system B, which creates a message c that can be queried by C or D. The propagation of this message can be illustrated as:

A → B → C
→ D

Upon receipt of each message in a system, an event confirming it is generated. For example, System A would generate event a, B b, and C or D c.

I have MonoBehaviors and a custom event system that simulates an event-waiting feature. A behavior tree node can wait for a sequence of events to occur in any order after firing off a message. For example behavior node X can wait for events a and c after firing off message a.

I’m doing this because I need a way for behavior tree nodes to verify that downstream changes have taken place before they complete. Since the way that my Monobehavior behavior tree nodes interact with ECS is asynchronous, I’m forced to basically do a hacky async-and-poll pattern. Is this worth implementing?

How is this different from the job dependency chain?

It involves MonoBehaviors. Some MonoBehavior scripts create message entities that kick off a series of jobs. These jobs generate events that the MonoBehaviors listen to to make sure that changes have occurred down the road

If I understand correctly, when you fire an event A from MonoBehavior and waiting for a response on a MB side, why not also fire an event listener entity with instructions on how and when it should be sent back to MB. Then systems can process all the events asynchronously and when the systems see that the event should be sent back to MB they just do it at a sync point. Unless the event should be caught at some point by MB and altered before it goes on through the systems…


I made a diagram illustration how this system works. To answer your question, the messages are asynchronous, but the Monobehaviour that fires off the messages sort of “poll” its Entity counterpart to check the status of all related events

You might consider using Data Flow Graph for this. I don’t know enough about the internals of your systems to know if it is truly the right choice. But if you haven’t looked at it, it is worth doing.

Wow this blew my mind. The majority of my ECS systems have been resembling a data flow graph. I’m so sad that it’s probably too late or too early to make the switch. Either my systems are already too set in stone, or DFG is still under development with next to no documentation

The documentation is in the samples. It is very good.

Could you provide the path in the DOTSSample project? I cannot find the documentation

Not DOTS Samples, the package samples.

3 Likes