If you’re using AI as well, you can add a “Sense” and instantiate two stimuli, one for each team. Then, you assign the enemy sense so that each side senses the other side as an enemy.
The blueprints don’t have all the team functions like the C++ side of things has. So, instead of using the incomplete function sets, it’s generally recommended to create your own methods for tracking these things.
In multiplayer, with humans, create a wrapper, “PlayerParentActor”, and create multiple subcomponents that deal with gameplay. One of these components should contain a struct variable that tracks which team they are on. This part is for their need to know. Don’t let the game trust the player’s data, in multiplayer-- once your components are made, you can use a more global blueprint that the server or “AuthorityPlayer” will use to do all of the gameplay tasks. Add these new components, that track the player’s data, to the “trusted” blueprint so that the server is the authority on who is on whose team without players being able to get away with manipulating the data on their end. These component instances, one for each player, should be referenced as an array so you can easily add a new instance to the array.
If you’re only having two types of teams, it’s easy to make things called, “Team1”, and, “Team2”, but it’s best to just modularize things.
So, on the “trusted” blueprint, you can create components that have to do with general team information; color, “Attack”/“Defense”, name, array of members, etc. Then, add another set of components that inherit from this team information component and make them more specific to the “Attack” and “Defense” team information, if they differ. If not, then just create an instance for each team, adding them to the array on the “trusted” blueprint. From there, add the instances of the players’ information to the array in the instance of their respected team. Your gameplay blueprint can then automatically track who is on whose team by which instance of the team information they belong to.