Thoughts on the Gameplay Message Subsystem?

Development Programming & Scripting
1

Anyone have much experience with this yet? i like the idea of it, how does it run compared to Delegates?

2

Sorry no idea (yet). However you just solved my biggest problem with unreal: communication with HUD/gui display. This is perfect for updating hud.

1 Like
3

agreed, i got sick of binding all my individual widgets.

i should add my own thoughts

  1. gotta be slower, its just looping over a map compared to EDs
  2. its a GameInstance subsystem so does it clear bindings between maps? or are we expected to cancel the task on destruct.
  3. only useful for global events? as opposed to local player or local target events (ie inventory changes)
  4. no default replication support although you can just MC it from somewhere
4

things i like though,

no dependencies unlike EDs.
wildcard payload support

1 Like
5

What i did so far for hud update, ie communication from game to widgets that display info.

  • i made middle man setup, middle man is usually hud blueprint
  • it has event that triiggers dispatcher (and uses gameplay tags to identify type of data. And it sends data as string (strings can be formatted to have floats, vectors names etc, so all hud display may need)
  • and all widgets just hook to that dispatcher

But now that GMS (i hate acronyms, you evil GASP users!) will simplify it all.

This stuff will allow me to decouple widgets from where they are placed. Which means creating drag and drop custom widgets without customizing their communication.

1 Like
6

Has this subsystem been renamed in later versions?

I’m not seeing it in the source, what version are you using?

1 Like
7

yeah its weird, its a lyra subsystem but doesnt show up independently in plugins. so i had to yoink it!

so its kinda official and kinda not?

1 Like
8

I used it quite a lot, and IMHO it’s the perfect decoupling tool. However it has the classic issues of a message provider / subscriber system: At some point you loose track of what sends and what receives the messages. But this can be worked around though.
Since it’s using gameplay tags you can search for tags references in blueprints and you’ll find what broadcast / listen the message in your codebase, that’s quite handy.
However each tag has to be associated with a specific message struct, and sometimes you end up mistaking a message for another. fortunately the system will tell you that given event received the wrong message, but that’s sometimes hard to find the exact wrong broadcast.

In terms of performance, it’s really not an issue. Sure, you iterate over a list of listeners and trigger their callback on each message. But I guess the system is really meant for low frequency messages, that occur once ever n seconds, and not every frame.
Also the system is synchronous, so as soon as you broadcast the message, the listeners’ callbacks are executed (order of listener is not guaranteed). So I’d say the system is as slow as the code you put in the callbacks, and the cost of iteration is dwarfed by whatever you put behind.

for the clearing bindings part. It has some destructor system. When an actor that has a listener is destroyed, the listener is destroyed. So you don’t have to do the clean up yourself. There is no “proactive” method to unbind events though, and there is even a TODO in the code to do so.

I didn’t use it in a multiplayer context though, and the system only broadcast on the local client. Not sure how you would multicast though, it would have to be implemented into the system and multicasting all messages may be expensive, and would break the synchronous nature of it. Though I’m not experienced enough on the multiplayer side to have a very relevant insight.
Seems like Lyra uses it server side or client side only, but no message goes from the server to the client.
They have a “Client Broadcast Message” node that seems to be duplicating a server message on a client through the player state.

1 Like
9

thanks for the in-depth answer.

i wonder if EPIC will do an official release for it.

10

I’m experimenting with multiplayer, and multicasting a “broadcast message” doesn’t seem to work. I’m calling the multicast from the GameMode and listen in a client side player controller.
Only the one on the server gets the message…
The only way I managed to get the message everywhere is by actually setting a rep_notify variable in the game state, then broadcast in the rep_notify method. When I set the variable from the gameMode, both client and server gets the message, however I use blueprints, the behaviour could be different in C++.
Not completely ideal but… it works.
Note that the big drawback is that you are limited by the replication frequency if you send several messages on the same frame, you’ll only receive the last one I guess

11

GameMode isnt replicated, GameState was correct.

yeah you wouldn’t use RepNotify for messages it would have to be an RPC

1 Like
12

Yep it works from game state indeed.