This post is meant to shed some light on how things are structured, so that you can get a better understanding on how things work and what exists where.
Network in Unreal
So when you're moving your character, the one that actually moves it is the server. You can specifically see this if you have a bad connection with the server, where you'll feel the character unresponsive and your character position will be corrected, warping it to where it actually is in the server.
This also means that clients never talk to each other directly. If you want to send a chat message to the players on your team, what you're actually be doing is sending a message to the server saying that you want to send a message to your team, and the server will be the one relaying it.
When developing a game that you want to work in multi-player, I advise you to always keep this in the back of your head, never just "do something", tell the server to do it (exception being client only things, that should just be "visual stuff", nothing that actually influences the game).
Framework & Network
- Server Only - an object only exists on the server
- Server & Clients - an object is known to everybody, so if the server changes it all the clients will get the update
- Server & Owning Client - an object only exists in the server and the client that owns it
- Owning Client Only - an object only exists in the client that owns it
So if Game Mode held how much time a round of the game took, the Game State can be seen as the class that would keep track of the time remaining.
There can be multiple Pawns in the game, however the Player Controller can only possess one at a time.
For convenience, UE has a Character (ACharacter), which comes from Pawn, and adds a "network movement component", which handles the movement of the Character. Like I mentioned above, the server is the one that moves things, not the client, so it is because of that "special" character movement component that we're able to just say locally to move the character, but in fact that abstracts for us the fact that the data is being sent to the server to act upon it.
Most people associate the Player Controller with the representation of the player, which is wrong. The Player Controller can be seen as the "player high level input".
Basically when the player possesses a Pawn, this is the class that will control it. The reason that I call it high level input and not just input, is because you CAN have the input in the Pawn; in fact, I recommend you do your input in the Pawn, because in a lot of cases you possess pawns with completely different input and behaviour (e.g. a human and a car), so it is much easier to handle the input in the Pawn it refers to, than globally handle all input in the Player Controller.
By the way, the way input works, it will first be passed to the Player Controller, and if it doesn't get used up by it, it falls through to the Pawn. So you can have different levels of input, for example handling menus in the Player Controller, and then the movement of the Character itself on it.
Something that a lot of people stumble upon is how to get their Player Controller. Although it isn't easier to find, there's a rule that states that when you call UGameplayStatics::GetPlayerController( 0 ) it always returns your Player Controller.
So if you're running a server, GetPlayerController( 0 ) returns the Player Controller of the server. If you're running a client, GetPlayerController( 0 ) returns the Player Controller of that client (remember that clients only know their Player Controller, so they can't access any other).
If you're running a dedicated server (i.e. pure server without a local client), then GetPlayerController( 0 ) will return the first client.
As of 4.7.6, UE still has some issues when spawning the HUD at the start, so what I advise for now is that before you spawn any UMG widgets, add a delay (e.g. 0.2s) to let UE properly initialise stuff before the widgets are created.