Best place to add Squad logic within multiplayer teams?

Hi,

New here and fairly new to UE4 blueprints.

I’m using an FPS Multiplayer template as a base and I’m wanting to know what is the best/correct way to implement Squads within team. I want players to be able to create and select squads once they pick a team.

Currently I have a “Create Squad” button in my character selection widget (that displays at the start of the match) with an On Clicked event. Is it best to cast the Player and Team to the GameState Blueprint and create the Squad there? Then cast to PlayerState Blueprint to set the player Squad?

Create Squad Button Event in Widget (WIP):

Create Squad Event in GameState (WIP):

I’m guessing the Squad logic should in in the GameState because it’s something that will constantly change throughout the match…?

Thanks in advance.

1 Like

You need to research and better understand network replication in UE which is a fairly dense topic described extensively here:

However you can get quite a lot done with knowledge on just a few important parts of rep in ue. Run On Server and Multicast and replicated function styles that you change in the custom event settings at the replication setting.

Also basically only the player controller and the players possessed pawn can communicate client to server and the server really only by default replicates movement & physX if you checkmark replicated. So you have to use GameState and isServer and replicated variables to ensure the proper data is created by the server and then replicated to every PlayerController.

This pdf also is a nice and well organized summary of ue networking as well:

2 Likes

Amazing. Thanks. I’ll give the PDF a read to start.

The framework also includes a lot of replicated stuff like classes, weapons, team, abilities, etc. So I will try and use that as a reference. I just wanted to be sure I was heading in the right direction.

1 Like

Keep in mind that you should only replicate or make RPC’s when necessary. This is not only because of optimization but it also makes the logic easier to work with.

Also the PlayerState is owned by the players and can be used for making Server RPC’s.
Actors owned by something the player owns will also be owned so you can move logic into new Actors to separate the logic to keep it organized.

2 Likes

Hey, I got a gem Youtuber for you. Taught me so much and made me confident about at least some of the parts of the complex networking iceberg. The compendium is very useful as well, but this guy’s videos are straight to the point and quick.

Best of luck.

1 Like

First, let me say thanks for all the answers.

Second, let me say sorry for the delayed thanks. I got sucked in building squad, then into placeable objects and other bits.

@Jason_Hoku your suggestion to read the Compendium was great. It took some time, but gave me a much better understand of Multiplayer and how things relate to each other.

Can anyone point me in the direction of how to give Squads variables such as score, type, name. At the moment my squads are just any array of ints that is updated each time a squad is created/removed.

Thanks again.

First things first, it’s good that you figured out that GameState is a good place to manage teams. Still as the guy there suggested, the compendium is a MUST, because you are doing things incorrectly there (doing server-authority stuff on client).

Now to your question, what you need is something called struct, which has the properties you mentioned. Let’s call the struct FMyTeamInfo. Now inside your GameState you can have an array of type FMyTeamInfo, that contains all the teams. Note that the array has to be replicated in order for clients to access its data.

And for the future, you have multiple choices when it comes to “the best place/class to manage teams”. For examle, you can use subsystems, pretty much like Lyra does. You can also have an actor component that is attached to the GameState that encapsulates the team logic, so it doesn’t clutter your GameState class. The options are endless really, though they revolve around having that struct property that represents a team in an actor that is always relevant so you can always pull that data, and GameState is a such good candidate.