Centralized Event System with arbitrary number of parameters of arbitrary types

I'd say you're correct to have concerns about the code you've shown. Passing arguments through an params object[] will cause a memory allocation for the array, as well as for boxing any structs (including primitive types like numbers) and enums among the arguments. You'll then pay extra overhead to unbox them. Further, capturing these arguments in a lambda function and storing it as a delegate will allocate heap memory for that delegate.

All these allocations add execution time, and put pressure on the garbage collector. Not a lot for each call, but for a central messaging system like this, you'll likely be enqueuing and handling hundreds or thousands of events per frame, so all those little costs add up.

You'll also be paying some extra lookup costs for the dictionary - hashing the method info each time. We can skip that overhead too.

Fortunately, for something like an event system, its clients at either end pretty much always know the concrete types they want to work with:

• The code that fires an event knows what kind of event it's firing.

• The code that listens for an event knows what kind of event it's listening for.

So we can use strict typing at both ends. Then we just need a strategy to package up the data in between, so our central queue middle-man doesn't need to care about the details of the conversations it's facilitating. The curiously recurring template pattern can help us with this.

First, we can define a central queue that will hold all our events - of any type - in the order that they were issued, so we can handle them in the correct interleaved order, in case that matters for your use case.

Since the this part of the system isn't adding any information of its own, for its purposes it's just saying "Execute now" - no arguments. So a System.Action delegate suffices.

using System;
using System.Collections.Generic;

public static class EventQueue {
    static readonly Queue<Action> _queue;

    public static int Count { get => _queue.Count; }

    public static bool TryFireNextEvent() {
        if (_queue.Count == 0) return false;
        _queue.Dequeue().Invoke();
        return true;
    }

    public static void Enqueue(Action eventCall) { _queue.Enqueue(eventCall);  }
}

Then we'll define a template for events that need only a single argument.

Each one will maintain its own collection of listeners subscribed to that specific event type, and will stuff its arguments into a strictly typed queue, telling the central queue to let it know when to dump the next item from the queue to the listeners.

public abstract class Event<T> {
    static readonly Queue<T> _queue = new Queue<T>();

    static event Action<T> _listeners;

    static readonly System.Action _cachedDelegate = FireNextEvent;

    public static void Subscribe(Action<T> listener) { _listeners += listener; }
    public static void UnSubscribe(Action<T> listener) { _listeners -= listener; }

    public static void Enqueue(T eventData) {
        _queue.Enqueue(eventData);
        EventQueue.Enqueue(_cachedDelegate);
    }

    static void FireNextEvent() { _listeners?.Invoke(_queue.Dequeue()); }
}

We can repeat this pattern for events using two arguments, three, etc.

public abstract class Event<T1, T2> {
    static readonly Queue<(T1, T2)> _queue = new Queue<(T1, T2)>();

    static event Action<T1, T2> _listeners;

    static readonly System.Action _cachedDelegate = FireNextEvent;

    public static void Subscribe(Action<T1, T2> listener) { _listeners += listener; }
    public static void UnSubscribe(Action<T1, T2> listener) { _listeners -= listener; }

    public static void Enqueue(T1 first, T2 second) {
        _queue.Enqueue((first, second));
        EventQueue.Enqueue(_cachedDelegate);
    }

    static void FireNextEvent() {
        var (first, second) = _queue.Dequeue();
        _listeners?.Invoke(first, second);
    }
}

Now when we want to define a new concrete event type, it's a one-liner:

public class UnitDiedEvent : Event<UnitDiedEventData> {}

We can subscribe to the event like so:

UnitDiedEvent.Subscribe(MyListenerMethodOrDelegate);

And we can issue an event into the queue similarly:

UnitDiedEvent.Enqueue(deathData);

The only allocations here occur when the queue data structures need to expand. In the steady state, when your queue capacity is enough for the event volume, logging and handling events incurs no memory allocation, boxing, or dictionary lookups.

When we want to pump the queue of all events in order, we can just loop:

// Store the count before we start iterating, in case handling
// one event causes new events to be added to the queue.
int count = EventQueue.Count;
for (int i = 0; i < count; i++)
    EventQueue.TryFireNextEvent();

Of course, if you don't care about handling events in interleaved order, you can do away with the central EventQueue class and instead pump each concrete event type's queue at the appropriate place in your code - which gets rid of one indirection and helps improve your cache locality.