# Global Event System

**URL:** <https://forums.unrealengine.com/t/global-event-system/458449>\
**Category:** Community & Industry Discussion\
**Tags:** unreal-engine, global, delegates, question\
**Created:** [November 15, 2019, 5:06am UTC](https://forums.unrealengine.com/t/global-event-system/458449 "2019-11-15T05:06:05Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![anonymous\_user\_f684bd01](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@anonymous\_user\_f684bd01](https://forums.unrealengine.com/u/anonymous_user_f684bd01)\
**Post date:** [November 15, 2019, 5:06am UTC](https://forums.unrealengine.com/t/global-event-system/458449/1 "2019-11-15T05:06:05Z")

</div>

So I was just watching this video: [Blueprint Communications | Live Training | Unreal Engine - YouTube](https://www.youtube.com/watch?v=EM_HYqQdToE) and this 4 minutes into the video where he is going over a simple primer it’s mentioned that UE4 has no way to globally broadcast something (like an event) and that this used to be the case back in UE2 but is no longer the case because it’s inefficient. My question is why is this considered inefficient? In a global event system, you can simply have subscribers to different events (which can easily be stored in an array) and then anytime an object publishes an event, all the subscribers to this specific event are notified. This doesn’t seem inefficient at all and it completely decouples all the objects in the game which in my view is a very good thing because you avoid spaghetti kinds of relationships between objects. In fact an entire game can be set up with this structure. Why is this considered a bad practice? Thank you!

---

<div class="post-metadata">

**Author:** ![Everynone](https://d1ap1mz92jnks1.cloudfront.net/user_avatar/forums.unrealengine.com/everynone/32/1135017_2.png) [@Everynone](https://forums.unrealengine.com/u/Everynone)\
**Post date:** [November 15, 2019, 7:59am UTC](https://forums.unrealengine.com/t/global-event-system/458449/2 "2019-11-15T07:59:28Z")

</div>

It’s very possible to broadcast.

> you can simply have subscribers to  
> different events

By doing exactly that. Objects can register and become listeners. Example:

> [@Event dispatcher between 2 blueprints](https://forums.unrealengine.com/t/event-dispatcher-between-2-blueprints/116301/3):
>
> Currently you do not have a problem with Dispatchers. You have a problem with passing object references - your missing pin. [HR][/HR] Since you have both objects in the Level Blueprint, you can use the LB as glue between them. Consider the following: Actor A has an Event Dispatcher happy to send the data to whoever is listening: [ActorA.PNG] Actor B has a Custom Event that is waiting for that data: [ActorB.PNG] Currently those 2 objects do not know about one another’s existence. But the Le…

> [@Event dispatcher between 2 blueprints](https://forums.unrealengine.com/t/event-dispatcher-between-2-blueprints/116301/10):
>
> Below is my second BP, I’m going to spawn a bunch of these and make all of them listen to a broadcast (event dispatcher) of an object that created them. All you need is a Custom Event (or a function). Do note the inputs list \*(bool & int) \*of the event - it’s going to be vital later on: And here is the Handler, it’s spawning 6 SpawnedThings and makes them listen to the SendData dispatcher: Every time you call SendData in this handler, all Spawned Things will get…

> which in my view is a very good thing  
> because you avoid spaghetti kinds of  
> relationships between objects. In fact  
> an entire game can be set up with this  
> structure. Why is this considered a  
> bad practice?

Preach! It’s great practice, imho. In my current project I have (almost) completely eliminated direct references to widgets and rely on delegates exclusively.

There is an upfront cost of it being harder to understand and wire up initially - perhaps that’s why it’s not a part of a primer video. You reap the rewards of having your code _despaghettised_ later on, though.

---

<div class="post-metadata">

**Author:** ![pezzott1](https://d1ap1mz92jnks1.cloudfront.net/user_avatar/forums.unrealengine.com/pezzott1/32/1215068_2.png) [@pezzott1](https://forums.unrealengine.com/u/pezzott1)\
**Post date:** [April 4, 2024, 11:53pm UTC](https://forums.unrealengine.com/t/global-event-system/458449/3 "2024-04-04T23:53:07Z")

</div>

> [@Everynone](#):
>
> Example

Link is dead. By any chance have another example to share?

---

<div class="post-metadata">

**Author:** ![Everynone](https://d1ap1mz92jnks1.cloudfront.net/user_avatar/forums.unrealengine.com/everynone/32/1135017_2.png) [@Everynone](https://forums.unrealengine.com/u/Everynone)\
**Post date:** [April 5, 2024, 5:07am UTC](https://forums.unrealengine.com/t/global-event-system/458449/4 "2024-04-05T05:07:52Z")

</div>

Fixed. There are still so many broken links everywhere…

---

<div class="post-metadata">

**Author:** ![pezzott1](https://d1ap1mz92jnks1.cloudfront.net/user_avatar/forums.unrealengine.com/pezzott1/32/1215068_2.png) [@pezzott1](https://forums.unrealengine.com/u/pezzott1)\
**Post date:** [April 5, 2024, 5:28am UTC](https://forums.unrealengine.com/t/global-event-system/458449/5 "2024-04-05T05:28:47Z")

</div>

Thank you!

I’m looking for any type of messaging subsystem until I make the time to check out what Lyra has to offer: [GameplayMessageSystem | Unreal Engine Community Wiki](https://unrealcommunity.wiki/gameplaymessagesystem-74b916). 🫠

---

<div class="post-metadata">

**Author:** ![Everynone](https://d1ap1mz92jnks1.cloudfront.net/user_avatar/forums.unrealengine.com/everynone/32/1135017_2.png) [@Everynone](https://forums.unrealengine.com/u/Everynone)\
**Post date:** [April 5, 2024, 6:08am UTC](https://forums.unrealengine.com/t/global-event-system/458449/6 "2024-04-05T06:08:38Z")

</div>

A messaging subsystem of broadcasters sending structs using gameplay tags as channels.

No delegates, you say? Intriguing. Got it, I hope. What a mouthful! It seems to trivialise what most poeple struggle with - comms.
