Skip to main content

Terminology

Player Character

The class APawn is the 'Actor' that the Player actually controls. Most of the time it's a human character, but it could also be a cat, plane, ship, block, etc. The Player can only possess one Pawn at a time, but can easily switch between Pawns by un-possessing and re-possessing them.

The Pawn is mostly replicated to all Clients.

The Pawn's child class ACharacter is often used by us instead, because it comes with an already networked MovementComponent, which handles replicating the Input, Position, Rotation, etc. of a Player's Character.


Player Controller

The class APlayerController might be the most interesting and complicated Class. It's the center for a lot of Client related logic, since this is the first Class that the Client actually 'owns'.

The PlayerController can be seen as the 'Input' of the Player. It is also the link of the Player to the Server. This further means that every Client has one PlayerController.

A Client's PlayerController only exists on himself AND the Server, but other Clients don't know about other PlayerControllers. Every Client only knows about his own! The result of that is that the Server has a reference of all Client PlayerControllers.


Game Mode

info

NOTE: With 4.14, the GameMode Class got split into GameModeBase and GameMode. GameModeBase has less features, because some games just might not need the full feature list of the old GameMode Class. We do however, most of the time, use GameMode instead of GameModeBase!

The class AGameMode is used to define the RULES of your game. This includes the used classes, like APawn, APlayerController, APlayerState and more. It is only available on the Server. Clients don't have an object of the GameMode and will only get a nullptr when trying to retrieve it.

Example:

GameModes might be known through common modes as Deathmatch, Team Deathmatch or Capture the Flag. This means, that a GameMode can define things like:

• Do we have Teams or does everyone play for their own score?
• What are the winning conditions? How many kills does someone/a team need?
• How are the points achieved? Killing someone? Stealing a flag?
• What Characters will be used? What weapons are allowed? Only pistols?


Game State

info

NOTE: With 4.14, the GameState Class got split into AGameStateBase and AGameState. GameStateBase has less features, because some games just might not need the full feature list of the old GameState Class. We do however, most of the time, use GameState instead of GameStateBase!

The class AGameState is probably the most important class for shared information between Server and Clients. The GameState is used to keep track of the current State of the Game. This includes, for Multiplayer important, a List of connected Players (APlayerState).

The GameState is replicated to all Clients. So everyone can access it. This makes the GameState to one of the most centered classes for Multiplayer Games.

While the GameMode would tell how much kills are needed to win, the GameState would keep track of the current amount of kills of each Player and/or Team!

What information you store here is completely up to you. It could be an array of scores or an array of a custom struct that you use to keep track of groups and guilds.


Player State

The class APlayerState is the most important class for a specific Player in terms of shared information. It is meant to hold current state about the Player. Each Player has their own PlayerState. The PlayerState is however also replicated to everyone and can be used to retrieve and display data on other Clients. An easy way to access all PlayerStates, that are currently in the Game, is the PlayerArray inside of the GameState Class.

Example information that you might want to store here:

PropertyDescription
PlayerNameCurrent Name of the connected Player
ScoreCurrent Score of the connected Player
PingCurrent Ping of the connected Player
GuildIDA Guild's ID, in which the Player might be

Or other replicated information that other Players might need to know about


Widgets (UMG)

Widgets are used in Epic Games' "new" UI System, called Unreal Motion Graphics. They inherit from Slate, which is a language used to create UI within C++ and also used for the Unreal Engine 4 Editor itself. Widgets are only available locally on Clients (Listen-Server). They are NOT replicated and you always need a separated, replicated Class to perform replicated actions through, for example, Button-Presses.


Components

Read more about components here. Components are a special type of Object that Actors can attach to themselves as sub-objects. Components are useful for sharing common behaviors, such as the ability to display a visual representation, play sounds.


Interfaces

Read more about interfaces here. Interface classes are useful for ensuring that a set of (potentially) unrelated classes implement a common set of functions. This is very useful in cases where some game functionality may be shared by large, complex classes, that are otherwise dissimilar.