It’s not quite the end of our journey with message data. Items in the world also have some data assigned to them. They have a name which needs to be used when communicating about the item, a default call type, and they also have an associated audio clip per class. This is so that when we call quick chat on an item, your character will be able to respond with ‘Item Here, Armour Level 3’ or similar.

For this, we have a blueprint component that sits on each object you want to be able to interact with. This doesn’t do much other than contains the information required and passes it back to the appropriate functions when requested. It’s also used simply by its presence to denote that an object can be interacted with.



Now we know roughly now things are set up, I’ll walk through how the system works start to finish.

QuickChatTrigger_BPc (Player Controller Component)

Updating World Space Icons

World Space icons are stored on the QuickChatMessages components for the player that spawned them, allowing you to keep track of the owners of those items. The Trigger object ticks these objects to match their screen position to their world location.

Updating

Every 10th of a second (definable), we use a line check to see if you’re looking at an object with an interactable component. If not, we check to see if you’re looking in the direction of any of the world space components, using a dot product to determine which is closest. We have some minor fuzzy logic in here to avoid flip/flopping when at the edges of the lock on requirements.

Sending a Message Call

When you attempt to send a message call, the Quick Chat Trigger will determine whether or not you need to create a new message, or update an existing message. It will then RPC the server with one of two events. These both call the same Team Manager function, but with differing values.

TeamManager_BPc (GameState Component)

Registering/Changing Team

When players join the game or switch a team, the system will add them to an array of an array of pawns (multidimensional, using an array of pawns struct as the data type). Each index in the array is a team, with each of the pawns stored inside. The Team Manager removes or adds players to those array indices as necessary. This array is replicated, so clients can check who their teammates are.

Sending Message to Team

The main thing the Team Manager does is perform a single function; Send Message To Team. This acts as a link between the Trigger and the Message components. The function is called from the server on the trigger object, and is passed to the owners of each of the team pawns. This ensures it’s only replicated to the players that need the information.

UIDs

Whenever a message passes through the Team Manager that doesn’t already have a UID, we increment an integer and pass that to the message to use as its unique identifier. This is then used for determining on the client whether an incoming message is meant to create a new message, or update an existing one. We use integers rather than the GUID data type here as they’re significant smaller and GUIDs are overkill for the purpose (an int will max out at 2 billion messages passed, which shouldn’t happen in the course of a normal game).

PlayerState_BP

We also have a custom playerstate, storing the Name, Class and Team (integer) of the player. If you implement this into your own system, you’ll likely want to implement this functionality into your own player state and adjust the blueprints as necessary. This is purely used as the best place to store this information, it does not perform any logic itself other than getters and setters.

QuickChatMessages_BPc (Pawn Component)

The Chat Messages component is one of the major components of this system, and is used to create messages, icons and audio, and also store references to those components.