Welcome in multiplayer games.
The server should have authority over any significant changes to the game state.
If clients can change important factors, then this leaves a vulnerability that cheaters can exploit.
However, if clients must wait for confirmation from the server that their requested changes are valid,
then a noticeable delay would exist between the client performing an action.
And seeing the results to mitigate this problem.
Games make use of prediction.
Prediction is when the client goes ahead and makes a change.
Moving the character, opening a door, shooting a weapon and informs the server of that change.
When the server gets the information, it makes sure that it's a valid change.
The character hasn't moved into a wall or traveled across the map in a split second or opened a door
that it can't reach or shot a weapon that it doesn't own.
ET cetera.
And if the change is not valid, the server undoes those changes.
To have a playable experience.
Fast paced multiplayer games have to make use of prediction.
The goal of the gameplay ability system is to have gameplay logic and a gameplay ability and prediction
for that ability that just works.
What the developers didn't want was to have abilities filled with branches, like if authority do x,
else do predicted version of x.
Rather they wanted prediction that was more or less automatic.
Now it's important to note that not everything needs to be predicted.
Footstep sounds, for example, don't need to be predicted, but significant things like health changes,
Mana doing damage.
Things like this need to be predicted as the server should have some say in whether or not those changes
are valid.
Out of the box.
Gas automatically predicts ability activation triggered events gameplay effect application including
attribute modification but not execution calculations which we haven't made yet, but we'll get to those.
Gameplay tag modification as well as gameplay cue events whether they're from some predicted gameplay
ability or on their own and we'll get to gameplay cues soon enough.
Also predicted are montages as well as movement, thanks to the new character movement system in Unreal
Engine, but gas does not predict gameplay effect, removal or gameplay effect periodic effects.
These are some technical challenges that have not been overcome.
Prediction in gas is centered around the concept of a prediction key.
Prediction keys are based on prediction key A prediction key is simply a unique ID, and these are stored
in a central location on the client.
When the client performs a predictive action, it will send a prediction key up to the server and associate
its client side predictive actions and side effects with that key.
The server will receive that key and either accept it or reject it.
It will then associate any server side created side effects with that key and will respond to the client
informing it that the key has either been accepted or rejected.
An F prediction key sent from client to server will always make it to the server.
Now, in the past we've made the statement that replication only happens from server to client, but
that was referring to replicated variables.
In other words, variables marked with replicated or replicated using in their uproperty macro.
For these, yes, replication only happens from server to client, but here we're talking about sending
a prediction key up to the server and for this we often use the term replication for convenience.
So we say that that key is being replicated to the server and you'll see this trend a lot in gas.
And when a server sends the prediction key back, it will only go back to the client that sent it to
the server in the first place.
This replication down to clients is done in the prediction key net serialize function and all other
clients will simply receive an invalid key or a key with an ID of zero when that prediction key replicates.
We say that a gameplay ability in gas is a first class predictive action, meaning that whenever a client
predictively activates an ability, it explicitly tells the server and the server explicitly responds
whenever a client predictively activates an ability.
There now exists a window in which predictive actions can occur.
We refer to this window as a prediction window, and while this window is open, the client can perform
important actions that can change the game state such as use up attribute resources.
ET cetera.
Without asking the server for permission.
The ability system component has functions for communicating the activation of abilities between clients
and server.
We've already seen and used one of them tri activate ability.
Here's what happens when we call this function first.
The client calls tri activate ability and this results in the generation of a new prediction key.
Remember in our ability task target data under mouse when we call the function get activation prediction
key.
This is the key that that function retrieves that activation prediction key.
Now once tri activate ability is called, then a server RPC is called and that rpc is server tri activate
ability.
After calling this server RPC, the client continues on without waiting for any server confirmation
and goes ahead and calls activate ability with the generated prediction key which is now stamped onto
that abilities activation and its activation info.
While the client is busy doing things and generating side effects, all the side effects have this generated
prediction key associated with them.
Now we mentioned that the client calls a server RPC server tri activate ability.
Once the server receives this and this RPC is executed on the server.
The server then decides if this ability activation is valid.
Now, once the server makes this determination, it now knows whether or not this client activated ability
is a failure or a success.
And then it calls one of two client rpcs.
If the ability activation was a failure, the server calls client activate ability failed.
If it was a success, the server calls client activate ability succeeded.
The client receives the server's response and if it receives failure, it kills the ability and then
proceeds to undo all the side effects associated with the generated prediction key.
If it was a success, then those side effects are valid and don't need to be undone.
Now the ability system component has a member variable called replicated prediction key, and this is
set to the generated prediction key.
And as soon as it's set, it replicates.
Once it catches up to the client, the client can then respond accordingly, such as undoing side effects
and so on.
And this prediction key has its own rep notify.
It's called on rep Prediction key.
Now, we've been talking an awful lot about side effects.
So what are some examples of those?
Well, gameplay effects are side effects.
These are not first class predictive actions like abilities are because they're not explicitly asked
about gameplay effects are only applied on clients if there is a valid prediction key for the ability
applying them.
If the gameplay effect is predicted, then any of the following that the gameplay effect does are also
predicted.
Attribute modifications, gameplay tag modifications and gameplay cues.
When the active gameplay effect is created, it stores this prediction key on the server.
The active gameplay effect gets the same key and this active gameplay effect is replicated now on the
client side.
When it receives that replication, it can then check the key to see if it already has an active gameplay
effect with that same key.
Now if they match then we already know that any logic executed upon effect application has already been
done locally and doesn't need to be run again.
This helps to avoid duplicate on apply type effects that you can often run into when implementing your
own prediction.
This does mean, however, that the local container that stores all active gameplay effects will now
have two of the same effect, at least temporarily.
The ability system components replicated prediction key variable will be currently replicating down
to the client.
While all this is happening and when it finally arrives, any predicted effects can be removed.
And of course we have on rep prediction key to do anything that needs to happen once that prediction
key arrives.
At this point, I feel we have a good enough understanding of prediction in gas and why we need prediction
keys.
How deep you decide to dig into the gas code is up to you, but it's important to have at least a high
level understanding of what gas is doing behind the scenes for us.
For more information, please refer to gameplay prediction dot h where the comments therein explain
much of what we've gone over in this video and you can learn more about how prediction is handled there,
including prediction for gameplay attributes as well as some of the more advanced level challenges that
were faced when implementing the prediction system in gas.
So now that we have some understanding of gas prediction, we can now better understand the code we've
created in our custom gameplay task target data under mouse and we can now continue implementing interesting
things.
I'll see you soon.