Event dispatcher instantiations and (re)bindings

I have an “score object” actor which is destroyed on collision with the player actor. Once that happens there are three things I want to happen:

  1. Player’s score should be increased (in the game state object)
  2. Player’s score on screen should be updated (UMG HUD)
  3. A new “score object” actor should be spawned (by the level object)

I want to use events for the communication between the objects to accomplish these things, but I’m unsure of how the binding works.

My initial idea looked something like:
The “score object” actor creates an “ScoredEvent” event dispatcher (since it is the score object which will be doing the signalling).
The game state has an event dispatcher (it will be using it to signal the UMG HUD (update the score on screen)).
The Level and game state listens for ScoredEvent. Once they have received it:

  • The level will spawn a new score object.
  • The game state will add points to the user’s total score, and then fire off an event to the UMG HUD so that it updates the on-screen score.

Once a player collides with the actor, the “score object” actor its OnBeginOverlap will fire off the initial ScoredEvent.

However, I’m starting to realize that I was thinking of event dispatchers the wrong way. Because the score object is destroyed and recreated each time the listeners would need to rebind each time, right? (In C++ terms, I was thinking that the event dispatchers were a class-property rather than an object property for some reason…).

There’s a straight-forward solution to this: Don’t recreate the score object each time, but just move it around. However, I may want to add more score objects at a later time, so this isn’t a feasible solution.

So my current thinking is that the score object actor makes a regular function call to the level object which then is responsible for dispatching the events instead. That way all the dispatchers will be persistent for as long as the level is running.

Am understanding how event dispatchers are used correctly? I.e. they aren’t meant for objects which are created, deleted, recreated, etc (since a mechanism would be needed to rebind each time an object)?

Dispacher it used when you dont know how many actors can affect, or for many actor.

A score is hold in gamemode. It importat you read about unreal game framework before start a game.

I used to store the score in the game mode, but then I read the unreal game framework documentation which stated the game state’s role is (among other things) to keep track of score: https://docs.unrealengine.com/latest/INT/Gameplay/Framework/GameState/. So I moved the score to the game state.

Depends, if you are going to keep track of score for just that particular level and it’s single player, then Game Mode is where is should be. If you need it to persists outside the level, use Game Instance. If you need this replicated, then you’ll have to use Game State instead of Game Mode.

I doubt I can do a better job than Zak with his stream: https://www.youtube.com/watch?v=EM_HYqQdToE

BUT, if you still need help even after that video I will be more than glad to stream/do a tut for you.

I love Zak; all the official videos are great, but there’s a special place in my heart for Zak. :slight_smile:

That video had exactly the information I was looking for, including caveats with regards to communicating with the Level. Many thanks!