From what I'm understanding, you want to create a system where there are events and these events are only called when certain conditions are met, is that right?

As for the delegates thing, you can reference multiple methods using only one delegate as long as the methods have similar signatures.

    class Program
    {
        private delegate void testDeleg(int testInt);
        static void Main(string[] args)
        {
            testDeleg tDeleg = testMethod1; // create an instance of testDeleg delegate. Make sure to use the operator '=' when assigning a method to a delegate for the first time.
             tDeleg += testMethod2; // use += if you wish to add a reference to another method on the same delegate.

            tDeleg.Invoke(1);
            Console.ReadKey();
        }

        static void testMethod1(int i)
        {
            Console.WriteLine("testMethod1 and " + i);
        }

        static void testMethod2(int i)
        {
            Console.WriteLine("testMethod2 and " + i);
        }
    }

Beware that having a very large number of subscribers on an event/delegate can cause performance issues when adding or removing more handlers.  MulticastDelegate's internal "invocation list" is an array which is treated immutably like the internal char array in strings; this means that the entire invocation list is recreated every time one handler is added or removed.

If you have a significantly large number of handlers, it's better to use a List<DelegateType> instead (similar to how StringBuilder can improve performance when building large strings out of many small parts)

See: https://referencesource.microsoft.com/#mscorlib/system/multicastdelegate.cs,fcbf8bdc05d28aeb

One way to communicate is not to explicitly communicate at all.

Instead have a black-board like store where everybody can find the information it needs to make its decision. Everybody also updates its own part of the blackboard. Advantages are that it is simple, it is always consistent information (nobody has to store state about others locally). The disadvantage of that solution is that the blackboard is a central point of information. You can somewhat reduce that by splitting the blackboard into several sub-blackboards, but how well that works heavily depends on the application.

Have interested entities subscribe to the events they are interested in. You may want to dive into the Publish-Subscribe pattern: https://en.wikipedia.org/wiki/Publish–subscribe_pattern

23 hours ago, Wush said:

... I am still torn what arranges the handlers(I tried some form of matchmaker in a previous project), and might to have to write my own list class so whenever something is added to a list it throws an event. ...

System.Collections.ObjectModel.ObservableCollection<T> has this functionality if you want to use a built-in class.