Welcome.
Now, so far, there have been a couple of times that we've thrown a couple terms around that have to
do with multiplayer.
So I think it's about time we start to discuss multiplayer and its relationship to the gas system.
Now, in a multiplayer game there exists a server and in most cases just one server.
And this server is an instance of the game running separately and independently from the other machines
that are also running their own version of the game.
We call those clients.
Now the server is different than the clients and we're going to discuss those differences in this video.
Now, in a multiplayer game, the server can take on a number of flavors.
For instance, there's the dedicated server.
A dedicated server has no human player and no rendering to a screen occurs.
It's just a computer running the game simulation now because there's no human player and no actual rendering
to a screen.
Don't let that fool you into thinking that things are not happening on the server machine, such as
players running around shooting each other in a shooter game casting spells in a magic game, leveling
up and gaining experience and things like that.
Those are all things that can and do happen on the server version of the game.
They just don't happen to be showing that by rendering images to a screen as the server doesn't need
to do that.
Now, aside from the dedicated server, there's another type of server model called the Listen server.
Now this differs from the dedicated server in that the listen server is a human player, or at least
it's a computer running a version of the game on which a human player is controlling a pawn or character.
We say that that human player is hosting the game.
Now the host has an advantage in the listen server model, and that advantage is that the host has no
lag.
Lag is the result of the time that it takes for data to travel across the network from the server to
clients and from the clients up to the server.
In a listen server, the host is the server and the server doesn't have to send data across the network
to itself, so there is no lag for the hosting player.
Now in Unreal Engine, we treat the server as the authoritative version of the game.
Things are happening on each machine.
Players run around, they change their positions and this happens on each and every version of the game
that's running.
But because of lag, your version of the character's location on your machine is going to be different
than your character's location on another player's machine and on the servers.
So we have to decide which machine is the correct version.
We consider the server to be the correct version of the game, and for this reason we do important things
on the server.
Now what are those important things?
We'll learn about those as we go along and program the game.
But it's important to know that the server is always considered the authoritative version of the game.
Now if we draw a dotted line between the server and the client, we can make some distinctions about
certain game classes.
The game mode exists only on the server.
If you attempt to access the game mode on one of the clients, you will get a null pointer.
That's because the game mode is responsible for things like rules of the game spawning players and restarting
the game, things like that.
And those are some of those important things we were talking about that should only be handled on the
server.
Now the player controllers for each player exist on the server, but they also exist on each client.
So the server has an authoritative server version of each player controller and each client has their
own local version.
But notice that Client zero only has player controller zero on its machine.
There is no player controller one or player Controller two.
All the other player's player controllers don't exist on Client zero.
It's only the server that has all of the player controllers in the game and can access them.
Now.
The player state is another story.
The player states.
For each player all exist on the server, but they also all exist on each client.
Client Zero has a version of player state zero, along with Player State one and Player State two.
So that's a distinction from the player controller class.
Now if that seems confusing, just think of it as a sort of similarity that the player state has with
the pause.
You see, the server has all three pawns in the game, but each client also has all three pawns in the
game, which makes sense.
If you're playing the game, you have to be able to see your pawn running around, but you also have
to see the pawn controlled by client one and the pawn controlled by client two.
It only makes sense that your machine has copies of all three pawns in the game.
Same with client one.
It needs to see your pawn as well as its own and client two's.
So all the pawns in the game exist on all machines.
The same goes for the player state.
Now the HUD and all associated widgets that get shown on the screen are sort of different than all the
other classes.
Each client has its own HUD class and it only exists on that client.
So if we're talking about a dedicated server, there is no HUD on the server.
If it's a listen server, then the only HUD that exists is the HUD for that local player playing the
game.
Each client only has its own HUD and any associated widgets that get shown to the screen for that player.
Client Zero does not have access to Client One's HUD.
It doesn't exist on Client Zero's machine.
So what does all this mean in relation to replication?
We set our player controller class to be replicated.
What does that mean?
And our player state was set to have a net update frequency of 100.
What does that mean?
Well, net update frequency just means that as changes are made on the server, every single net update,
the server sends data down to the client so they can be informed of that change.
A net update frequency of 100 means that those changes will be updated on clients 100 times a second,
as long as the server can manage that when data is transmitted from the server down to clients.
We call that replication, and here's how it works.
Let's say you have a variable on the pawn class.
Now it could be a float, an integer or any other type.
Now it exists in the pawn class, which means that each version of the pawn has that variable, the
version of the pawn on clients, the version of the pawn on the server.
They all have the variable.
Now, if the variable is designated to be a replicated variable, then if that variable's value changes
on the server, then the next net update that change will be sent down to all clients so that the client
version of that variable can be updated to the new value.
This act of sending that data down to clients is called replication.
Now what happens if we have a replicated variable and it gets changed on one of the clients?
Does that mean that the server will be informed of that change?
In other words, does replication work both ways?
The answer is no.
Replication only works one way from server to client, so if a variable is marked as replicated, it
should not be changed on clients because the server will not know about that change and neither will
any of the other clients.
Only the client who changed that variable will know about it and that variable will now be out of sync
with the server's version of that value.
And remember, the server is the correct version, so the variable on that client will now be considered
incorrect.
Now you might be thinking if replication only works one way, how would a client ever get data up to
the server?
Obviously that has to happen sometimes, right?
I mean, we make input with our keyboard and mouse or controller.
That input has to make its way to the server somehow.
Well, yes, it does in the form of replicated functions which we call RPC or remote procedure calls
and we'll learn about those later.
But the truth is this high level overview of replication is just about all you need to know about multiplayer
for this course.
You can learn all about it if you take my multiplayer shooter course, but there's a reason that that
course is not a prerequisite for this course, and that's because most of the multiplayer stuff is handled
under the hood.
For us in gas.
We will need to know a little bit about multiplayer, but for the most part, gas handles a lot of stuff
for us under the hood and we'll learn about that stuff that gas does for us so that we can appreciate
and let it work for us as we're building our game and all of the gameplay mechanics that we implement
in this course will work in multiplayer as well as single player.
So now that we know a little bit about how the classes work in relation to multiplayer, we'll.
Now move on and add our ability system component and attribute sets to our player state for our player
controlled character and to the character class for our enemies.
And we'll learn how to associate the ability, system component and attribute set with its owner and
we'll learn what that means in the videos to come.
I'll see you soon.