This of course means you will need a reference to the ScoreBoard…not a bad thing.
Thanks. I was wondering if this was normal.
Model B
Makes sense. I’ll go the event driven route rather than the event tick route.
IMHO EventDispatchers, while good design, might be a bit overkill for this situation
That’s how I felt too. But I’m really posting here for the learning experience rather than just trying to “get it done”. So I appreciate all the feedback you all have given.
EventDispatchers…there are benefits… if you had multiple consumers (so multiple places that needed to reflect the change), you would only have to make one call and have all pieces attach to the event.
Yeah, that makes perfect sense. So my project is already using Event Dispatchers for that exact purpose, where I have it being called in multiple places across the project. In this case, it’s really a one off. So it sounds like the choice is up to me to choose whether or not to do it the “right” way or take a temporary shortcut.
The example setup you showed is not what I think @BRGDemianLopez meant. Essentially your GameState should have an event which you then call…let’s say QuarterUpdated. Your scoreboard would then bind to that…maybe on begin play. Then you would just call the event, no need to reference the ScoreBoard.
Thanks for pointing this out. I didn’t understand that. So when you say “have an event” are you saying to create the event dispatcher in the BP_GameState? Where as in my screenshot above I created the event dispatcher in BP_Scoreboard… So I did it backwards, is that right?