Somewhat both. Events and delegates are 2 different things and each has their place. Delegates don’t replace events, but they offer an alternative and often better way of
1) Is that your recommended method of managing events, or are you just showing an example of delegates?
Abstract global event systems are bad.
Erm, close enough…
2) This pattern is also sometimes referred to as signals-and-slots, right?
Events, delegates, and signals and slots are 3 different things really, but some of that is just semantics and implementation.
Signals are basically events and slots are basically delegates. The main difference is that “signals and slots” refers to the whole send/handle events system whereas delegates are just the things that handle events.
It is certainly more widely useful in desktop applications which are event-driven. Nothing happens until you click a button or type into the keyboard.
3) Do you find it actually beneficial to use in games, or just desktop applications?
Games are different. It is definitely an error to make a global event system that tries to push your game into a heavily event-driven state. Events in games are better suited for handling script-related events, such as a player walking into a certain area of the map and triggering an in-game cinematic.
There are times and places for event-based systems in games, but outside of this example there are very few.
Likely a sign that you intuitively realize that event systems in games are not to be used the same way they are in event-based desktop applications.
Event processing is one of the areas I have difficulty implementing neatly.
Event systems are to be used sparingly in games and only after much planning and pondering.
A global event system is an anti-pattern as was already mentioned. Humans are like desktop applications and dogs are like games. Both can eat chocolate cake, but the dog will likely die from it.