WEBVTT

1
00:00:27.390 --> 00:00:31.020
Network connection structure and communication processing structure

2
00:00:32.180 --> 00:00:35.960
Let’s start by learning about the network structure in the Unreal Engine

3
00:00:36.780 --> 00:00:39.740
First, let’s discuss the network connection structure

4
00:00:39.740 --> 00:00:43.580
The network connection structure can be represented in two main forms

5
00:00:43.580 --> 00:00:48.360
The first form is the local multiplayer setup

6
00:00:48.360 --> 00:00:50.660
where multiple inputs are connected to a single PC, as shown in the diagram above

7
00:00:50.660 --> 00:00:53.660
When you go to places like arcades, there are arcade game machines, right?

8
00:00:53.660 --> 00:00:55.660
Or console gaming systems

9
00:00:55.660 --> 00:00:59.840
In such setups, multiple users can play together using keyboards, joysticks, or other input controllers

10
00:00:59.840 --> 00:01:03.820
connected to a single gaming console or arcade machine

11
00:01:03.820 --> 00:01:06.720
However, there are times when you want to play games online

12
00:01:06.720 --> 00:01:08.620
with other users

13
00:01:08.620 --> 00:01:12.900
Commonly seen in genres like battle royale or MMORPGs

14
00:01:12.900 --> 00:01:16.700
For example, games like StarCraft, League of Legends, and Lineage

15
00:01:16.700 --> 00:01:18.240
fall into this category

16
00:01:18.240 --> 00:01:20.700
In Unreal Engine, as shown in the diagram below

17
00:01:20.700 --> 00:01:24.960
it provides a server-client model for online game modes

18
00:01:24.960 --> 00:01:26.210
It represents a service structure

19
00:01:26.210 --> 00:01:30.020
where multiple clients are connected to a single server

20
00:01:30.020 --> 00:01:33.200
Let’s now explore different types of game servers

21
00:01:33.200 --> 00:01:36.100
In online gaming, the type of server varies

22
00:01:36.100 --> 00:01:38.020
depending on the service being provided

23
00:01:38.020 --> 00:01:41.180
For example, there are games like LoL or StarCraft

24
00:01:41.180 --> 00:01:44.600
where a small number of players enjoy the game together

25
00:01:44.600 --> 00:01:46.280
There are also games like Lost Ark or Lineage

26
00:01:46.280 --> 00:01:49.660
where a large number of players play together

27
00:01:49.660 --> 00:01:52.810
These can be categorized into listen servers and dedicated servers

28
00:01:52.810 --> 00:01:54.880
based on the types of server used

29
00:01:54.880 --> 00:01:56.580
A dedicated server

30
00:01:56.580 --> 00:02:01.200
as shown in the diagram above is

31
00:02:01.200 --> 00:02:03.650
a structure where multiple users connect to a single server

32
00:02:03.650 --> 00:02:05.740
to synchronize data for gameplay, ensuring consistency

33
00:02:05.740 --> 00:02:09.520
This is a structure commonly used for online game servers as we commonly know them

34
00:02:09.520 --> 00:02:11.540
This dedicated server structure involves

35
00:02:11.540 --> 00:02:15.640
clients connecting to a server that is installed remotely

36
00:02:15.640 --> 00:02:17.900
Since it only handles server-side logic

37
00:02:17.900 --> 00:02:22.140
there’s no burden of rendering anything on the screen

38
00:02:22.140 --> 00:02:24.190
Therefore, it can allocate PC resources

39
00:02:24.190 --> 00:02:27.240
entirely to logic and communication processing

40
00:02:27.240 --> 00:02:29.700
ensuring reliable data management

41
00:02:29.700 --> 00:02:32.900
It’s a structure where it’s impossible for another client

42
00:02:32.900 --> 00:02:33.880
to manipulate data in the middle

43
00:02:33.880 --> 00:02:37.740
However, there are drawbacks, such as increased hosting costs

44
00:02:37.741 --> 00:02:39.600
due to the need for remote installation

45
00:02:39.600 --> 00:02:43.300
Also, downloading and installing the Unreal Engine source code for production can be time-consuming

46
00:02:43.300 --> 00:02:44.960
often taking more than 10 hours

47
00:02:44.960 --> 00:02:48.840
which can be inconvenient during learning

48
00:02:48.840 --> 00:02:50.290
Next, a listen server can be seen in games

49
00:02:50.290 --> 00:02:53.520
like LoL or StarCraft’s Battlenet structure

50
00:02:53.520 --> 00:02:54.620
As you can see in the diagram

51
00:02:54.620 --> 00:02:58.280
there’s a central server coexisting with clients

52
00:02:58.280 --> 00:03:01.280
In a listen server setup

53
00:03:01.280 --> 00:03:03.599
both the server and clients physically coexist on the same PC

54
00:03:03.599 --> 00:03:07.249
And since server logic and rendering are handled together

55
00:03:07.249 --> 00:03:08.599
it can impose speed constraints

56
00:03:08.599 --> 00:03:11.399
Also, because the server doubles as a client

57
00:03:11.399 --> 00:03:14.840
there’s a drawback where that client can manipulate data

58
00:03:14.840 --> 00:03:17.599
which can lead to reduced data reliability

59
00:03:17.600 --> 00:03:19.779
However, it offers the advantage of no hosting costs

60
00:03:19.779 --> 00:03:21.629
allowing multiple users to play together

61
00:03:21.629 --> 00:03:25.040
on a local network

62
00:03:25.040 --> 00:03:28.259
Let’s now explore the communication processing structure

63
00:03:29.420 --> 00:03:32.220
in the Unreal Engine’s network architecture

64
00:03:33.200 --> 00:03:37.460
There are various methods available

65
00:03:37.460 --> 00:03:39.760
beyond automatic synchronization of data

66
00:03:39.760 --> 00:03:41.400
for characters in Unreal Engine

67
00:03:41.400 --> 00:03:45.640
These methods are collectively referred to as Actor Replication

68
00:03:49.640 --> 00:03:51.460
Alright, let’s first discuss these methods

69
00:03:51.460 --> 00:03:56.760
Clients simply send their intentions to the server in this method

70
00:03:56.760 --> 00:04:01.400
The client’s intention refers to the actions based on user inputs they receive

71
00:04:01.400 --> 00:04:03.999
It includes actions such as pressing buttons, clicking with the mouse

72
00:04:04.000 --> 00:04:06.959
or other types of input generated by the user

73
00:04:06.960 --> 00:04:10.979
Then, the logic here refers to creating the flow of the game

74
00:04:10.979 --> 00:04:15.760
rather than handling the input itself

75
00:04:15.760 --> 00:04:17.410
Creating the game’s flow is

76
00:04:17.410 --> 00:04:19.000
typically not done on the client side

77
00:04:19.001 --> 00:04:20.460
Because if the client handles this

78
00:04:20.460 --> 00:04:23.720
all client’s data needs to be synchronized

79
00:04:23.720 --> 00:04:25.370
which becomes challenging

80
00:04:25.370 --> 00:04:29.559
if each client manages it independently

81
00:04:29.560 --> 00:04:32.659
Therefore, clients typically do not handle this themselves

82
00:04:32.659 --> 00:04:36.609
Instead, they request the server to process their intentions or logic

83
00:04:36.609 --> 00:04:38.360
like saying, “I want to do this; please handle this logic”

84
00:04:39.880 --> 00:04:43.960
In this case, clients send requests to the server in the form of RPCs

85
00:04:43.960 --> 00:04:45.960
The server then receives these requests

86
00:04:45.960 --> 00:04:48.039
and executes the game logic based on them

87
00:04:48.040 --> 00:04:50.759
understanding what the client wants to achieve

88
00:04:50.760 --> 00:04:53.220
After executing the game logic

89
00:04:53.220 --> 00:04:56.099
the server needs to send the resulting data

90
00:04:56.099 --> 00:04:59.199
back to the clients

91
00:04:59.199 --> 00:05:03.720
There are broadly two main methods to send this data to the clients

92
00:05:03.720 --> 00:05:08.420
One method is using NetMulticast, and the other is using Client functions

93
00:05:10.039 --> 00:05:12.139
Users receive that data

94
00:05:12.139 --> 00:05:14.919
and it’s replicated as discussed - essentially duplicated

95
00:05:14.920 --> 00:05:18.299
Users don’t generate data themselves; they request it from the server

96
00:05:18.300 --> 00:05:21.799
Once the server creates the data

97
00:05:21.799 --> 00:05:26.119
it replicates it to the clients

98
00:05:26.120 --> 00:05:28.639
This replication structure has two main methods

99
00:05:28.640 --> 00:05:31.079
one is using RPC

100
00:05:31.079 --> 00:05:34.880
and the other is using Property Replication

101
00:05:34.881 --> 00:05:38.731
In addition to simple data replication

102
00:05:38.731 --> 00:05:40.300
clients can also perform other actions

103
00:05:40.300 --> 00:05:42.699
besides that

104
00:05:44.180 --> 00:05:47.320
Users typically can’t handle game logic themselves

105
00:05:47.321 --> 00:05:49.440
but there are certain cases

106
00:05:49.440 --> 00:05:50.740
where clients need to handle

107
00:05:50.740 --> 00:05:52.739
specific aspects

108
00:05:54.060 --> 00:05:55.960
We shoot a gun

109
00:05:56.839 --> 00:05:58.139
“bang”

110
00:05:58.139 --> 00:06:01.240
Then the effect would appear like this

111
00:06:01.241 --> 00:06:03.841
The actual visual processing like this

112
00:06:03.841 --> 00:06:05.280
can’t be handled by the server

113
00:06:05.280 --> 00:06:08.730
The server simply receives inputs like

114
00:06:08.730 --> 00:06:11.199
“I pulled the trigger”

115
00:06:11.200 --> 00:06:14.659
Then the server will use that input

116
00:06:14.659 --> 00:06:18.199
to send back the result, like who got shot

117
00:06:18.199 --> 00:06:21.049
Then users receive that result

118
00:06:21.049 --> 00:06:23.060
and handle the visual processing accordingly

119
00:06:26.790 --> 00:06:28.840
Do you understand?

120
00:06:28.840 --> 00:06:31.850
Rendering something on the screen, in this form

121
00:06:31.850 --> 00:06:33.950
is something that the server can’t do

122
00:06:33.950 --> 00:06:37.000
it must be done entirely on the client side

123
00:06:37.000 --> 00:06:40.540
Effects are a prime example of visual processing

124
00:06:40.540 --> 00:06:44.120
that’s solely handled on the user’s side, not on the server

125
00:06:46.180 --> 00:06:50.480
Effects such as fire effects, flowing water, or splintering shards when hit

126
00:06:50.480 --> 00:06:53.680
are handled by the client

127
00:06:53.680 --> 00:06:55.600
not the server

128
00:06:55.600 --> 00:06:57.950
The server informs the client where impacts occur

129
00:06:57.950 --> 00:07:02.040
and then the client displays effects accordingly

130
00:07:02.041 --> 00:07:05.480
Another example is user interfaces (UI) that are also managed by the client

131
00:07:05.480 --> 00:07:10.200
These UI elements can’t be managed or processed by the server

132
00:07:10.201 --> 00:07:15.840
The server only sends data like “What is your current HP?”

133
00:07:15.840 --> 00:07:16.590
Right?

134
00:07:16.590 --> 00:07:20.040
The client is responsible for receiving this data

135
00:07:20.041 --> 00:07:21.041
and displaying it on the screen

136
00:07:22.520 --> 00:07:26.500
We’ve covered the communication processing structure to this point

137
00:07:27.400 --> 00:07:31.080
Let’s explore the network game framework

138
00:07:32.160 --> 00:07:34.239
this time

139
00:07:34.240 --> 00:07:36.300
The structure of a network game framework

140
00:07:37.920 --> 00:07:40.020
isn’t fundamentally different

141
00:07:40.020 --> 00:07:42.800
but typically includes classes and components tailored for multiplayer functionality

142
00:07:42.800 --> 00:07:44.900
unlike the single-client focus we’re used to

143
00:07:44.901 --> 00:07:48.280
There are classes that make the game framework function

144
00:07:48.280 --> 00:07:51.030
and depending on how these classes operate

145
00:07:51.030 --> 00:07:54.519
we can view the network structures differently

146
00:07:54.520 --> 00:07:58.359
On the client side, you didn't really need to use Game Mode, Game State, Player State

147
00:07:58.359 --> 00:08:01.100
and similar components much

148
00:08:02.000 --> 00:08:03.259
Let's start by

149
00:08:05.340 --> 00:08:06.890
discussing the lifecycle of these classes

150
00:08:06.890 --> 00:08:10.080
like Game State, Game Mode, and Player State

151
00:08:10.080 --> 00:08:12.280
and explain

152
00:08:12.280 --> 00:08:15.079
how they are created

153
00:08:15.080 --> 00:08:17.019
and operate

154
00:08:17.020 --> 00:08:19.619
When you press the play button

155
00:08:19.619 --> 00:08:22.320
or run the editor

156
00:08:22.321 --> 00:08:26.140
the game starts running

157
00:08:26.140 --> 00:08:29.200
When the game starts

158
00:08:29.201 --> 00:08:34.180
Unreal Engine needs to create a world

159
00:08:34.180 --> 00:08:39.119
This world is the virtual environment where you play and explore

160
00:08:39.120 --> 00:08:40.959
So, a world gets created

161
00:08:40.960 --> 00:08:45.219
But for that world to be created, the game needs to be in play mode, right?

162
00:08:45.219 --> 00:08:50.119
So

163
00:08:50.119 --> 00:08:50.980
when you first press

164
00:08:51.760 --> 00:08:53.160
the play button

165
00:08:54.420 --> 00:08:55.660
a Game Instance object

166
00:08:56.500 --> 00:08:59.620
is created

167
00:08:59.620 --> 00:09:01.170
The Game Instance can be seen as the manager

168
00:09:01.170 --> 00:09:05.799
that oversees the entire game

169
00:09:05.800 --> 00:09:10.159
It can be viewed as the entity that manages the start and end of the game altogether

170
00:09:10.159 --> 00:09:14.040
In terms of its lifecycle

171
00:09:14.041 --> 00:09:17.041
it begins by being instantiated

172
00:09:17.041 --> 00:09:20.080
as the Game Instance when the game starts

173
00:09:20.080 --> 00:09:23.020
So, now that the game has started

174
00:09:23.020 --> 00:09:25.020
the Game Instance's role includes

175
00:09:25.020 --> 00:09:28.819
creating the necessary virtual world

176
00:09:28.819 --> 00:09:31.159
or world inside it

177
00:09:34.600 --> 00:09:36.950
Remember "Get World" to retrieve the world?

178
00:09:36.950 --> 00:09:39.240
The Game Instance will proceed to create a world

179
00:09:39.240 --> 00:09:42.140
Once the virtual space is created

180
00:09:42.140 --> 00:09:44.720
necessary resources will be loaded into this space

181
00:09:44.720 --> 00:09:49.160
This includes creating all the Actors

182
00:09:49.160 --> 00:09:54.380
 that are needed and even spawning players

183
00:09:54.380 --> 00:09:56.639
within this environment

184
00:09:56.640 --> 00:09:59.780
During this process, as the Game Instance creates the world

185
00:09:59.780 --> 00:10:03.179
it also loads and instantiates the Game Mode class

186
00:10:03.179 --> 00:10:09.079
to determine what kind of data and rules will govern this world

187
00:10:09.080 --> 00:10:10.080
This creates an instance of the Game Mode class

188
00:10:12.919 --> 00:10:17.399
So, the Game Mode is created to

189
00:10:17.400 --> 00:10:22.659
define the fundamental rules of the game, as listed here

190
00:10:22.659 --> 00:10:26.259
So, we ran the game, created the game itself

191
00:10:26.259 --> 00:10:27.440
and even set up a virtual space

192
00:10:27.441 --> 00:10:30.640
So, within this game, who are the participants

193
00:10:30.641 --> 00:10:33.860
and according to which rules does the game end?

194
00:10:33.860 --> 00:10:37.510
The manager responsible for these overall aspects

195
00:10:37.510 --> 00:10:39.359
can be considered the game mode

196
00:10:39.360 --> 00:10:42.999
This game mode even handles the login process

197
00:10:43.000 --> 00:10:44.700
The player logs in

198
00:10:44.700 --> 00:10:48.139
Then, the game mode also controls

199
00:10:48.139 --> 00:10:50.839
whether or not to allow the player to participate in the game

200
00:10:50.840 --> 00:10:53.939
So, if I don't want to let this user participate

201
00:10:53.939 --> 00:10:58.160
the game mode will send an error message saying, "You can't join"

202
00:10:58.161 --> 00:11:00.880
Then, the user cannot enter the room

203
00:11:00.880 --> 00:11:05.520
When the user requests to enter the room and logs in

204
00:11:05.521 --> 00:11:07.721
the game mode gives the okay

205
00:11:07.721 --> 00:11:10.080
 allowing the user to join

206
00:11:10.080 --> 00:11:13.220
From that moment, the user participates in the game

207
00:11:13.220 --> 00:11:16.240
The participating client is then spawned

208
00:11:18.360 --> 00:11:20.440
and will enter the game

209
00:11:20.440 --> 00:11:23.720
Then, what this participant becomes is

210
00:11:23.720 --> 00:11:25.380
the PlayerController

211
00:11:26.800 --> 00:11:30.880
So, this PlayerController represents you or me in the actual reality

212
00:11:30.880 --> 00:11:34.840
acting as the intermediary between the user and the game

213
00:11:34.841 --> 00:11:38.040
The PlayerController acts as an intermediary

214
00:11:38.041 --> 00:11:42.320
representing actual users like you and me

215
00:11:42.320 --> 00:11:44.720
and to move around and perform actions in the virtual space

216
00:11:44.720 --> 00:11:47.080
this typically requires a Pawn

217
00:11:47.080 --> 00:11:48.360
That's precisely what a Pawn is

218
00:11:50.120 --> 00:11:53.820
The PlayerController possesses

219
00:11:53.820 --> 00:11:55.240
the Pawn

220
00:11:55.240 --> 00:12:01.039
Possess might sound different but typically 'Pawn' is a term used in chess

221
00:12:01.040 --> 00:12:04.799
What does it mean to have a piece here in chess?

222
00:12:04.800 --> 00:12:09.719
We have a pawn like this, and we want to move it

223
00:12:09.719 --> 00:12:12.219
We can capture it and control it

224
00:12:12.219 --> 00:12:13.469
We'll be able to control it

225
00:12:13.469 --> 00:12:15.999
forwards and backwards

226
00:12:15.999 --> 00:12:18.499
So, what do we call

227
00:12:18.499 --> 00:12:20.700
the act of the user capturing this pawn?

228
00:12:20.700 --> 00:12:22.460
We call it 'possessing' the pawn

229
00:12:23.180 --> 00:12:26.130
So, what about if there are multiple Pawns? What does the PlayerController do?

230
00:12:26.130 --> 00:12:26.920
You can switch

231
00:12:26.920 --> 00:12:29.720
possession of these Pawns

232
00:12:31.220 --> 00:12:32.760
allowing continuous control

233
00:12:34.239 --> 00:12:39.000
Managing the overall rules of the game is actually quite high-risk

234
00:12:40.820 --> 00:12:42.070
when you think about it

235
00:12:42.070 --> 00:12:44.380
It's because they wield considerable authority

236
00:12:44.380 --> 00:12:45.380
What kind of authority?

237
00:12:46.820 --> 00:12:50.919
It's a structure that allows them to end the game and even determine the outcome

238
00:12:50.920 --> 00:12:54.259
Who? It's the game mode itself

239
00:12:54.259 --> 00:12:58.209
Now, in the context of networked games, whether it's a dedicated server or a listen server

240
00:12:58.209 --> 00:12:59.599
there's always a server

241
00:12:59.600 --> 00:13:00.919
and there are clients

242
00:13:00.920 --> 00:13:03.279
Even though clients are connected like this

243
00:13:03.279 --> 00:13:05.979
 physically

244
00:13:05.979 --> 00:13:09.719
they're separate entities logically

245
00:13:09.720 --> 00:13:12.299
This is how it's set up

246
00:13:12.299 --> 00:13:16.099
So, the server and clients are

247
00:13:16.099 --> 00:13:18.039
communicating bidirectionally like this

248
00:13:18.040 --> 00:13:22.459
and each of them has their own game mode

249
00:13:22.459 --> 00:13:25.809
If each client has its own game mode

250
00:13:25.809 --> 00:13:27.880
what might happen?

251
00:13:27.881 --> 00:13:30.680
They might each independently determine the game's outcome

252
00:13:30.680 --> 00:13:35.719
They could manipulate the outcome, so that wouldn't work

253
00:13:35.720 --> 00:13:38.179
They could also kick players out at will

254
00:13:38.180 --> 00:13:40.979
This would lead to excessive abuse of authority

255
00:13:40.979 --> 00:13:46.400
So, giving such authority to all clients would obviously not be feasible

256
00:13:46.400 --> 00:13:49.340
Only the server can have the game mode

257
00:13:50.380 --> 00:13:54.780
Clients follow rules

258
00:13:54.780 --> 00:13:57.200
determined by the game mode

259
00:13:58.100 --> 00:14:00.900
Where does the game mode exist?

260
00:14:00.900 --> 00:14:05.359
It exists only on the server
It's dependent on and tied to the server

261
00:14:05.360 --> 00:14:08.159
Clients cannot

262
00:14:08.159 --> 00:14:09.509
directly access the game mode

263
00:14:09.509 --> 00:14:11.359
So, you bring the game mode

264
00:14:11.359 --> 00:14:12.880
 but if the game mode exists

265
00:14:12.880 --> 00:14:14.500
it's on the server

266
00:14:14.500 --> 00:14:17.950
And within the game mode class, you carry out various tasks

267
00:14:17.950 --> 00:14:20.839
This structure operates exclusively on the server

268
00:14:22.420 --> 00:14:24.620
That could lead to issues like this

269
00:14:24.620 --> 00:14:26.820
We start the game, right?

270
00:14:26.820 --> 00:14:31.220
We start, then we'll do things like end the game and stuff like that

271
00:14:31.220 --> 00:14:32.220
After these parts

272
00:14:33.680 --> 00:14:37.180
they operate as teams

273
00:14:37.181 --> 00:14:39.381
This one also exists like this, so it's a team

274
00:14:39.381 --> 00:14:41.940
So, if I want to know about information

275
00:14:41.940 --> 00:14:45.659
regarding teams performing scores or missions

276
00:14:45.659 --> 00:14:51.179
Meaning, I want to know how the overall state of the game progresses

277
00:14:51.179 --> 00:14:54.320
If the server manages all the rules

278
00:14:54.321 --> 00:14:58.520
the client simply receives and processes the corresponding actions

279
00:14:58.520 --> 00:15:02.320
Since only the server knows the current state of the game

280
00:15:02.320 --> 00:15:04.239
it would be challenging for clients

281
00:15:04.240 --> 00:15:06.199
to handle those aspects

282
00:15:06.199 --> 00:15:11.080
So, an instance called GameState is created

283
00:15:12.000 --> 00:15:15.400
This game instance, as described here

284
00:15:15.400 --> 00:15:17.880
monitors the overall state of the game

285
00:15:17.881 --> 00:15:20.460
Here, if the game needs to be played

286
00:15:20.461 --> 00:15:25.380
for 10 minutes

287
00:15:25.380 --> 00:15:29.619
you would need to know how much time has passed in the current game session

288
00:15:29.620 --> 00:15:33.339
Since you can't directly get these things from the game mode, how do you do it?

289
00:15:33.339 --> 00:15:36.919
You do it through GameState

290
00:15:36.920 --> 00:15:41.039
So, next, each client may encounter these kinds of inconveniences

291
00:15:41.039 --> 00:15:44.599
Okay, you understand about each team in the game's state

292
00:15:44.599 --> 00:15:47.399
but what about their HP values?

293
00:15:47.399 --> 00:15:53.400
Or what about when they send me a private message in chat

294
00:15:53.401 --> 00:15:57.820
or how many kills they currently have?

295
00:15:57.820 --> 00:16:01.399
How can we handle these kinds of things?

296
00:16:02.359 --> 00:16:08.580
GameState clearly refers to the overall state of the game, not the individual states of each player

297
00:16:08.581 --> 00:16:11.440
So, we put PlayerState separately

298
00:16:11.441 --> 00:16:16.720
So, we store information here to control

299
00:16:16.720 --> 00:16:19.839
and manage each player's state separately

300
00:16:19.840 --> 00:16:22.299
You understand that the game mode exists only on the server

301
00:16:22.300 --> 00:16:25.209
So, the game state

302
00:16:25.209 --> 00:16:28.959
should exist on all clients

303
00:16:28.959 --> 00:16:31.220
so that they can know each team's score

304
00:16:31.221 --> 00:16:35.271
current status, how much time has passed in the game

305
00:16:35.271 --> 00:16:36.280
and so on

306
00:16:36.280 --> 00:16:39.180
So, each client in the game world

307
00:16:39.180 --> 00:16:42.520
can have access to the game state

308
00:16:42.521 --> 00:16:44.221
They would each have one

309
00:16:44.221 --> 00:16:46.621
The server needs to know the game state

310
00:16:46.621 --> 00:16:47.840
to handle things like how much time has passed

311
00:16:47.840 --> 00:16:50.390
and whether to end the game

312
00:16:50.390 --> 00:16:53.599
The game mode can use this information to make decisions

313
00:16:53.599 --> 00:16:58.000
So, the game state exists on both the server and the clients

314
00:16:58.000 --> 00:17:00.350
I mentioned that the game mode exists only on the server

315
00:17:00.350 --> 00:17:05.180
However, the game state exists simultaneously on both the server and the clients

316
00:17:05.181 --> 00:17:07.081
What about the player state?

317
00:17:07.081 --> 00:17:10.760
The player state should contain information for all clients

318
00:17:10.760 --> 00:17:15.359
So, they will all be visible on this screen

319
00:17:15.359 --> 00:17:20.059
Here, this is labeled as client

320
00:17:21.620 --> 00:17:25.819
but let's call this C1, and we'll call this one C2 and this one C3

321
00:17:25.819 --> 00:17:30.599
In the C1 screen, C2 and C3 will be visible together, right?

322
00:17:30.600 --> 00:17:33.900
To display their HP and kill counts

323
00:17:33.900 --> 00:17:35.459
we need to know their information

324
00:17:35.459 --> 00:17:39.009
In other words

325
00:17:39.009 --> 00:17:42.719
the player state will naturally be held by all clients

326
00:17:42.720 --> 00:17:44.420
Alright, let's look at the PlayerController

327
00:17:44.420 --> 00:17:45.279
It is stated that in the Pawn's possession

328
00:17:45.279 --> 00:17:46.929
the Possess function plays a role in conveying the user's intent

329
00:17:46.929 --> 00:17:49.159
according to their intentions

330
00:17:49.160 --> 00:17:52.310
In other words, as I mentioned, when there is a specific character

331
00:17:52.310 --> 00:17:54.239
the PlayerController is what allows the user to Possess the character

332
00:17:54.239 --> 00:17:59.440
and convey their intentions

333
00:17:59.440 --> 00:18:03.290
When the game starts, it was mentioned that a game instance is created

334
00:18:03.290 --> 00:18:07.280
and a world is created within it

335
00:18:07.281 --> 00:18:10.100
A virtual space, the world, is created

336
00:18:10.100 --> 00:18:13.050
Then, within this

337
00:18:13.050 --> 00:18:15.520
we create the necessary game mode and various other things

338
00:18:15.520 --> 00:18:18.770
Actors will all be placed within this

339
00:18:19.570 --> 00:18:21.920
Actors are placed inside the world space

340
00:18:21.920 --> 00:18:23.880
Anything outside this world space is not considered an Actor

341
00:18:23.880 --> 00:18:28.830
In this context, the game instance is not considered an Actor

342
00:18:28.830 --> 00:18:30.640
So, it would be like this

343
00:18:30.640 --> 00:18:33.540
If there's an entity visible on this screen that represents the player

344
00:18:33.540 --> 00:18:35.440
what do we call this entity?

345
00:18:35.440 --> 00:18:37.479
We call it Pawn

346
00:18:37.479 --> 00:18:39.740
We call that entity

347
00:18:42.020 --> 00:18:43.020
a Pawn

348
00:18:43.860 --> 00:18:47.110
But these Pawns, they'll be placed inside here

349
00:18:47.110 --> 00:18:49.559
and let's consider that there are multiple Pawns

350
00:18:49.560 --> 00:18:54.099
So, do they all receive control from every user, or not?

351
00:18:54.099 --> 00:18:57.760
They can receive control from just one use

352
00:18:57.761 --> 00:19:00.880
What did we call the entity that can control this Pawn?

353
00:19:00.880 --> 00:19:04.940
It's called the PlayerController, which acts as the user's intermediary

354
00:19:09.220 --> 00:19:12.240
We have this PlayerController

355
00:19:12.240 --> 00:19:16.399
This PlayerController possesses the Pawn to control it

356
00:19:17.720 --> 00:19:22.259
Alright, let's look at user C1

357
00:19:22.259 --> 00:19:24.809
This is me, user C1

358
00:19:24.809 --> 00:19:26.860
Over there, we have user C2

359
00:19:27.820 --> 00:19:29.070
C2

360
00:19:29.070 --> 00:19:31.800
Let's just focus on these two for now

361
00:19:31.800 --> 00:19:37.000
Then, how many PlayerControllers are there on this C1 screen?

362
00:19:37.001 --> 00:19:40.740
If there are multiple PlayerControllers, who will be in control?

363
00:19:40.740 --> 00:19:44.959
It's quite ambiguous. In my case, PlayerController naturally corresponds to me

364
00:19:44.960 --> 00:19:47.239
on a one-to-one basis

365
00:19:47.240 --> 00:19:51.979
By "me," I mean either you or me, referring to actual people

366
00:19:51.979 --> 00:19:56.000
The PlayerController serves as the entity

367
00:19:56.001 --> 00:19:58.501
that connects you and me to this virtual space

368
00:19:58.501 --> 00:19:59.340
So

369
00:19:59.340 --> 00:20:02.690
when I want to exert influence on this Pawn

370
00:20:02.690 --> 00:20:05.959
 through inputs or other means

371
00:20:05.960 --> 00:20:07.360
the entity that represents me is the PlayerController

372
00:20:07.360 --> 00:20:11.779
and there's only one of it

373
00:20:11.779 --> 00:20:15.880
In the client context

374
00:20:15.880 --> 00:20:18.080
there is only one PlayerController

375
00:20:18.080 --> 00:20:20.430
There is only one, without exception

376
00:20:20.430 --> 00:20:22.119
Then, it is the one

377
00:20:22.120 --> 00:20:25.839
that is remote, right?

378
00:20:25.840 --> 00:20:28.599
That PlayerController over there will control it

379
00:20:28.599 --> 00:20:31.960
I shouldn't have control over what belongs to others

380
00:20:31.960 --> 00:20:35.840
In the remote context, this would be C2, then

381
00:20:37.859 --> 00:20:41.579
C2 user would be there, and C1 user would be here

382
00:20:42.920 --> 00:20:45.320
Right here

383
00:20:45.320 --> 00:20:48.080
there will only be a PlayerController for C2 user

384
00:20:48.080 --> 00:20:51.860
This PlayerController is what represents you

385
00:20:51.880 --> 00:20:54.030
It's what mediates between you and it

386
00:20:54.030 --> 00:20:56.540
This PlayerController is what connects them

387
00:20:56.900 --> 00:20:59.900
There's only one here and one over there as well

388
00:20:59.900 --> 00:21:03.680
It's the server, and then there are clients

389
00:21:05.300 --> 00:21:10.720
Alright, each client has one PlayerController like this

390
00:21:10.720 --> 00:21:14.120
Usually, they have it indexed as zero

391
00:21:14.121 --> 00:21:18.220
Then how about from the server's perspective?

392
00:21:18.221 --> 00:21:20.660
It should be able to communicate with them too, right?

393
00:21:20.660 --> 00:21:23.839
It should be able to communicate with both of them

394
00:21:23.839 --> 00:21:26.889
Clients only need to handle their own, right?

395
00:21:26.889 --> 00:21:29.319
So, I have a PlayerController here

396
00:21:29.320 --> 00:21:34.099
If I want to control it and send inputs like this and that

397
00:21:34.100 --> 00:21:36.059
based on our communication structure as we discussed

398
00:21:36.059 --> 00:21:41.040
when I send inputs, the server receives the corresponding logic

399
00:21:41.040 --> 00:21:46.839
processes it, and responds accordingly

400
00:21:46.840 --> 00:21:51.099
So, to communicate between them

401
00:21:51.099 --> 00:21:54.760
we need a structure that involves the PlayerController

402
00:21:54.761 --> 00:21:57.560
 corresponding to each of them

403
00:21:57.560 --> 00:22:00.360
That way each one can control the other

404
00:22:00.360 --> 00:22:02.519
A structure is created for them to communicate with each other

405
00:22:02.520 --> 00:22:04.120
Here, a PlayerController

406
00:22:04.120 --> 00:22:06.759
corresponding to this one is also created

407
00:22:08.419 --> 00:22:12.560
So, if we call this one P0 here, then let's arbitrarily label this one as P1

408
00:22:12.561 --> 00:22:15.311
 and we'll call this one P2

409
00:22:15.311 --> 00:22:17.280
But they represent the same entity; only the names are different

410
00:22:17.280 --> 00:22:20.980
So, when this one makes a request to the server

411
00:22:20.980 --> 00:22:23.640
it processes it accordingly

412
00:22:23.641 --> 00:22:25.260
 involving the relevant subsystems

413
00:22:25.260 --> 00:22:28.010
The dedicated handlers for each client are precisely the PlayerControllers

414
00:22:28.010 --> 00:22:31.179
and the server also has corresponding content for each of them

415
00:22:34.779 --> 00:22:36.879
We can label

416
00:22:36.879 --> 00:22:39.901
what game framework classes exist together

417
00:22:39.901 --> 00:22:41.601
 between the server and clients

418
00:22:43.761 --> 00:22:47.979
So, what exists only on the server side is the game mode

419
00:22:47.979 --> 00:22:50.479
This game mode defines the rules of the game

420
00:22:50.479 --> 00:22:52.040
 so it's very important, and it resides on the server

421
00:22:52.041 --> 00:22:54.100
You can just think of it as the server itself

422
00:22:54.100 --> 00:22:57.641
Then, what must exist both on the server and all clients are the GameState

423
00:22:57.641 --> 00:23:01.641
followed by PlayerState, and Pawns

424
00:23:01.641 --> 00:23:04.361
How about PlayerController?

425
00:23:04.362 --> 00:23:07.761
Clients have their own PlayerController, right? What about the server?

426
00:23:07.761 --> 00:23:08.911
Everyone has it

427
00:23:08.911 --> 00:23:11.080
so what exists only on the server and client

428
00:23:11.081 --> 00:23:14.120
is called PlayerController

429
00:23:14.121 --> 00:23:17.840
All clients have the same thing like this

430
00:23:17.840 --> 00:23:21.159
and PlayerController isn't something that all controllers have

431
00:23:21.160 --> 00:23:24.299
Each one has their own, that's how it's differentiated

432
00:23:24.299 --> 00:23:28.279
Next, HUD and UMG exist only on the client side

433
00:23:28.279 --> 00:23:31.940
On the local client, do they exist on the server? They don't

434
00:23:32.813 --> 00:23:35.393
Player Controller and Connection

435
00:23:36.999 --> 00:23:40.449
Okay, let's now delve into PlayerController

436
00:23:40.449 --> 00:23:43.840
and Connection

437
00:23:43.841 --> 00:23:46.060
I've also talked about the communication structure before

438
00:23:46.060 --> 00:23:48.310
I mentioned that this structure involves clients making requests to the server

439
00:23:48.310 --> 00:23:50.820
the server executing the corresponding logic

440
00:23:50.821 --> 00:23:53.400
and then sending the results back to the clients

441
00:23:53.401 --> 00:23:56.581
PlayerController plays a very important role

442
00:23:57.720 --> 00:24:02.960
PlayerController doesn't exist

443
00:24:02.961 --> 00:24:04.820
on all clients and servers

444
00:24:04.820 --> 00:24:08.819
The server has all the PlayerControllers

445
00:24:08.821 --> 00:24:11.701
The server has all PlayerControllers 1, 2, and 3

446
00:24:11.701 --> 00:24:16.679
The client only has its own PlayerController

447
00:24:16.680 --> 00:24:19.579
They only have their own respective ones

448
00:24:20.619 --> 00:24:22.919
So, when they communicate with each other

449
00:24:22.919 --> 00:24:26.079
on the server side

450
00:24:26.080 --> 00:24:27.530
if they make a call to all clients

451
00:24:27.530 --> 00:24:31.779
Where do you place the ARS phone call?

452
00:24:31.779 --> 00:24:34.679
When I make a call

453
00:24:34.679 --> 00:24:38.159
someone at the reception will answer

454
00:24:38.160 --> 00:24:41.519
Then someone specific will be designated to answer the call

455
00:24:41.519 --> 00:24:45.940
That someone is the dedicated staff member directly assigned to connect with me

456
00:24:45.941 --> 00:24:48.620
Here, PlayerController corresponds to that role

457
00:24:48.620 --> 00:24:51.620
So, we have PlayerController on the client side

458
00:24:51.620 --> 00:24:53.170
 and PlayerController on the server side

459
00:24:53.170 --> 00:24:55.620
both representing the same entity in this context

460
00:24:55.620 --> 00:24:59.700
The server has the corresponding PlayerController for this

461
00:24:59.700 --> 00:25:03.480
and it also has PlayerControllers corresponding to all clients

462
00:25:03.481 --> 00:25:05.780
while each client only has its own

463
00:25:05.780 --> 00:25:08.930
This is the primary purpose of PlayerController

464
00:25:08.930 --> 00:25:11.040
in this network context

465
00:25:11.041 --> 00:25:12.341
Then what is a connection?

466
00:25:12.341 --> 00:25:15.340
 It directly pertains to communicating between the client and the server

467
00:25:15.340 --> 00:25:18.640
 using PlayerController

468
00:25:18.640 --> 00:25:19.520
This PlayerController

469
00:25:19.520 --> 00:25:21.919
internally holds an object

470
00:25:23.881 --> 00:25:27.201
called UNetConnection

471
00:25:28.481 --> 00:25:29.831
As the name suggests

472
00:25:29.831 --> 00:25:32.900
it handles tasks related to network connections

473
00:25:33.821 --> 00:25:35.471
The UNetConnection

474
00:25:35.471 --> 00:25:40.081
handles tasks related to TCP or UDP communication

475
00:25:40.081 --> 00:25:42.431
ensuring connections are established and facilitating the exchange of communication data between them

476
00:25:42.431 --> 00:25:44.640
It manages basic setup values necessary

477
00:25:44.640 --> 00:25:49.159
for sending and receiving communication data

478
00:25:49.160 --> 00:25:52.319
That's how it works

479
00:25:52.319 --> 00:25:53.419
Users exist

480
00:25:53.419 --> 00:25:57.419
and when there's a server, they connect to communicate with each other

481
00:25:57.419 --> 00:26:00.360
Internally, think of it like socket communication

482
00:26:00.361 --> 00:26:01.511
Once connected

483
00:26:01.511 --> 00:26:06.400
a channel is established between them to exchange data

484
00:26:06.400 --> 00:26:09.439
Like this, a channel is created

485
00:26:09.439 --> 00:26:10.789
It's created like this

486
00:26:10.789 --> 00:26:13.440
We commonly refer to this channel as a stream

487
00:26:15.061 --> 00:26:16.999
We call it a stream

488
00:26:16.999 --> 00:26:18.649
Through this stream or channel

489
00:26:18.649 --> 00:26:22.520
 data flows back and forth between them

490
00:26:22.520 --> 00:26:26.270
Creating and managing this flow of data, sending and receiving

491
00:26:26.270 --> 00:26:29.600
is handled by the UNetDriver below

492
00:26:29.601 --> 00:26:34.120
So, handling the sending and receiving of data is done by UNetDriver

493
00:26:34.120 --> 00:26:38.120
while tasks like connecting clients and servers are handled by

494
00:26:38.120 --> 00:26:41.559
its underlying operations managed by UNetConnection

495
00:26:41.560 --> 00:26:44.310
When the connection is established

496
00:26:44.310 --> 00:26:46.980
the channel is created, and within this stream

497
00:26:46.980 --> 00:26:48.080
data is exchanged back and forth

498
00:26:48.080 --> 00:26:52.060
much like saying 'hello' to each other

499
00:26:52.060 --> 00:26:55.410
When they say "hello" to each other like this

500
00:26:55.410 --> 00:26:58.760
they respond with "yes, hello"

501
00:26:58.760 --> 00:27:00.260
By doing so

502
00:27:00.260 --> 00:27:02.360
they establish these as communication protocols

503
00:27:02.360 --> 00:27:04.279
We commonly refer to this as a protocol

504
00:27:05.601 --> 00:27:06.851
We call it a protocol

505
00:27:06.851 --> 00:27:09.381
This protocol is a communication agreement

506
00:27:09.381 --> 00:27:12.531
We call the rules for how we talk like this, 'I'll say this'

507
00:27:12.531 --> 00:27:14.279
'Oh, then I'll take it like this'

508
00:27:14.280 --> 00:27:18.079
making up the rules for conversation, a protocol

509
00:27:18.079 --> 00:27:22.629
So, UNetDriver creates the data processing flow

510
00:27:22.629 --> 00:27:25.140
based on this protocol

511
00:27:25.140 --> 00:27:28.090
Then, what do we call these flowing data units?

512
00:27:28.090 --> 00:27:29.580
We call them packets

513
00:27:31.719 --> 00:27:33.769
It's called a packet

514
00:27:33.769 --> 00:27:37.520
You can think of a packet as a unit of bundled data

515
00:27:37.521 --> 00:27:40.060
So, when bundled like this

516
00:27:40.061 --> 00:27:44.900
how does UNetDriver handle these packets?

517
00:27:44.900 --> 00:27:48.480
It groups them further into sets of eight packets

518
00:27:48.481 --> 00:27:50.920
It bundles the packets one more time

519
00:27:50.920 --> 00:27:56.200
When you handle data, you're dealing with bits, right?

520
00:27:56.201 --> 00:28:00.600
Bytes exist, and then there's Short, and ShortInt

521
00:28:00.600 --> 00:28:03.640
Then there are Int32, and so on, including 64-bit variants

522
00:28:03.640 --> 00:28:04.690
Those are divided into different sizes

523
00:28:04.690 --> 00:28:08.040
They increase gradually from the smallest

524
00:28:08.040 --> 00:28:11.119
Characters and similar types like char exist

525
00:28:11.120 --> 00:28:12.970
Creating data units

526
00:28:12.970 --> 00:28:15.339
progressively from smaller to larger sizes

527
00:28:15.339 --> 00:28:17.389
Similarly, in network communication

528
00:28:17.389 --> 00:28:19.139
data isn't just sent as individual minimal units

529
00:28:19.139 --> 00:28:20.939
but often in bundled units

530
00:28:20.939 --> 00:28:26.959
So, byte data is bundled into packets, forming several units of bundled data

531
00:28:26.959 --> 00:28:30.161
These packets are also grouped into several units of bundles

532
00:28:30.161 --> 00:28:31.821
We call those bunch

533
00:28:34.559 --> 00:28:37.709
In English, we say 'bunch'

534
00:28:37.709 --> 00:28:42.920
You can consider this 'bunch' as a unit of bundled data

535
00:28:42.921 --> 00:28:45.571
This 'bunch' data can be divided into several types

536
00:28:45.571 --> 00:28:46.980
to facilitate processing

537
00:28:46.980 --> 00:28:48.730
When sending data from the client

538
00:28:48.730 --> 00:28:51.480
UNetDriver bundles it into bunches

539
00:28:51.481 --> 00:28:53.031
If the server receives data

540
00:28:53.031 --> 00:28:56.940
and applies it without filtering

541
00:28:56.940 --> 00:28:59.990
problems like unchecked data

542
00:28:59.990 --> 00:29:01.399
could arise

543
00:29:01.399 --> 00:29:02.399
What problems?

544
00:29:02.399 --> 00:29:04.849
It's mainly an issue of processing speed

545
00:29:04.849 --> 00:29:07.920
They would have to analyze each one individually

546
00:29:07.920 --> 00:29:09.770
That's why in Unreal Engine

547
00:29:09.770 --> 00:29:15.181
they typically categorize this data into three specific types for handling

548
00:29:15.181 --> 00:29:17.261
They call this channels

549
00:29:19.999 --> 00:29:22.780
They call it channels

550
00:29:24.760 --> 00:29:26.910
namely control channels and then voice channels

551
00:29:26.910 --> 00:29:28.360
They categorize it as actor channels

552
00:29:28.360 --> 00:29:30.660
to enable voice communication

553
00:29:31.941 --> 00:29:33.821
Taking actor channels means

554
00:29:33.821 --> 00:29:35.671
categorizing data

555
00:29:35.671 --> 00:29:39.080
internally for tasks

556
00:29:39.081 --> 00:29:42.900
like controlling data or sending voice data

557
00:29:42.900 --> 00:29:46.599
and handling things like character movement

558
00:29:46.600 --> 00:29:47.450
Doing classification work and decide

559
00:29:47.450 --> 00:29:49.350
"So, you're dealing with Actor data"

560
00:29:49.350 --> 00:29:53.439
"and you're using the Actor channel to flow through the processing"

561
00:29:53.440 --> 00:29:57.659
so, you push only that Actor channel here to proceed with the work

562
00:29:57.659 --> 00:29:59.559
Alright, that's how it goes

563
00:29:59.559 --> 00:30:03.439
This is configured in the PlayerController

564
00:30:03.440 --> 00:30:06.600
In this case, these are all class names

565
00:30:06.600 --> 00:30:11.359
After that, it's structured with UNetDriver followed by UNetConnection

566
00:30:13.541 --> 00:30:18.281
Alright, let's talk about the Owner that has the connection this time

567
00:30:18.281 --> 00:30:21.560
Okay, as you can see in the picture

568
00:30:22.401 --> 00:30:27.181
both the client and the server coexist together like this on the screen

569
00:30:27.181 --> 00:30:30.631
But I mentioned that

570
00:30:30.631 --> 00:30:32.359
we can communicate using PlayerController

571
00:30:32.359 --> 00:30:34.360
If you look here, you can see the PlayerController

572
00:30:34.360 --> 00:30:36.960
The PlayerController internally uses UNetConnection

573
00:30:36.960 --> 00:30:40.760
for data communication

574
00:30:40.760 --> 00:30:47.359
So, it means that we can communicate through PlayerController

575
00:30:47.359 --> 00:30:51.159
In other words, when a game instance is created in the world

576
00:30:51.159 --> 00:30:55.239
and the world is created, these characters are inside it

577
00:30:55.239 --> 00:30:56.339
With this setup

578
00:30:56.339 --> 00:31:02.239
we aim to establish communication between the server and the clients

579
00:31:02.259 --> 00:31:05.540
We're trying to establish communication between the server and clients like this

580
00:31:05.541 --> 00:31:09.320
and PlayerController is necessary for this

581
00:31:09.321 --> 00:31:11.871
Because PlayerController exists on both the server and clients

582
00:31:11.871 --> 00:31:13.780
they can communicate using it

583
00:31:13.780 --> 00:31:15.730
Currently, as seen in the diagram

584
00:31:15.730 --> 00:31:18.640
communication is structured using PlayerController

585
00:31:18.641 --> 00:31:22.141
Alright, so in this case

586
00:31:22.141 --> 00:31:24.280
the PlayerController here directly possesses a Pawn

587
00:31:24.280 --> 00:31:26.830
Then, how is this Pawn structured internally?

588
00:31:26.830 --> 00:31:30.830
It's structured so that they communicate with each other

589
00:31:30.830 --> 00:31:31.940
using the UNetConnection object within the PlayerController

590
00:31:33.401 --> 00:31:36.001
So, the idea is that they communicate

591
00:31:36.001 --> 00:31:40.041
through the PlayerController that owns themselves

592
00:31:40.041 --> 00:31:43.640
Then, it happens automatically

593
00:31:43.640 --> 00:31:47.140
Well, then, there could be issues like this

594
00:31:47.140 --> 00:31:49.500
Let's say we have a gun here

595
00:31:51.840 --> 00:31:54.740
The user grabs and moves the gun like this

596
00:31:55.961 --> 00:31:58.001
So, what happens next?

597
00:31:58.880 --> 00:32:00.580
The gun

598
00:32:00.580 --> 00:32:02.380
should also appear to be moved in this direction

599
00:32:02.380 --> 00:32:04.599
on other clients' screens

600
00:32:04.600 --> 00:32:07.099
To ensure synchronization, the server needs to receive data

601
00:32:07.099 --> 00:32:10.049
 indicating that the gun has been moved

602
00:32:10.049 --> 00:32:12.960
and then inform others accordingly

603
00:32:12.961 --> 00:32:16.660
However, there can be a problem here
What problem?

604
00:32:16.660 --> 00:32:20.239
Someone owns the Playercontroller

605
00:32:20.240 --> 00:32:24.199
They directly possesses a Pawn

606
00:32:24.199 --> 00:32:26.899
However, in the case of this gun

607
00:32:26.899 --> 00:32:28.261
the PlayerController doesn't directly possess it

608
00:32:28.261 --> 00:32:29.661
Right now, it's not being possessed

609
00:32:29.661 --> 00:32:35.800
In chess, "possess" means you can only capture one piece at a time

610
00:32:35.800 --> 00:32:39.860
We're grabbing and moving this one piece

611
00:32:39.861 --> 00:32:41.880
We can't grab this gun

612
00:32:41.880 --> 00:32:46.780
Right now, I'm grabbing and moving just this one PlayerController Pawn

613
00:32:46.780 --> 00:32:49.060
in this structure

614
00:32:49.081 --> 00:32:51.481
But suddenly grabbing and moving any other Actor here

615
00:32:51.481 --> 00:32:53.101
 wouldn't work

616
00:32:54.160 --> 00:32:56.160
So, furthermore

617
00:32:56.160 --> 00:32:57.560
because it's not a Pawn

618
00:32:57.560 --> 00:33:00.039
the PlayerController also can't possess it

619
00:33:00.039 --> 00:33:05.080
It's just like a regular terrain feature, similar to a chessboard piece

620
00:33:05.081 --> 00:33:08.160
The PlayerController cannot possess it

621
00:33:08.160 --> 00:33:12.599
Possessing is only possible for characters of the Pawn type, such as character classes

622
00:33:12.601 --> 00:33:14.221
Only this object can move

623
00:33:15.459 --> 00:33:17.760
That means it cannot do it, for regular Actors

624
00:33:17.761 --> 00:33:19.161
So, in this case

625
00:33:19.161 --> 00:33:20.061
how can we ensure that

626
00:33:20.061 --> 00:33:22.811
when it moves like this

627
00:33:22.811 --> 00:33:25.400
it synchronizes identically on other clients?

628
00:33:25.400 --> 00:33:29.479
That's where the concept of ownership comes into play

629
00:33:31.080 --> 00:33:32.930
Alright, if you set the Owner

630
00:33:32.930 --> 00:33:37.380
between this Actor and this Pawn

631
00:33:37.380 --> 00:33:38.119
 what happens?

632
00:33:38.119 --> 00:33:41.581
Through this Owner, you can directly communicate

633
00:33:41.581 --> 00:33:45.441
with the server contents from the right

634
00:33:46.301 --> 00:33:48.901
Alright, you've set the Owner to be the Pawn

635
00:33:48.901 --> 00:33:53.080
So, because this Pawn is possessed by the PlayerController

636
00:33:53.081 --> 00:33:56.960
 it creates a structure where they can communicate with each other

637
00:33:56.960 --> 00:34:00.200
If this doesn't exist, what happens if the Owner isn't set?

638
00:34:00.200 --> 00:34:02.650
The Actor wouldn't be able to communicate

639
00:34:02.650 --> 00:34:06.050
So, it can be done through the Owner

640
00:34:06.050 --> 00:34:07.439
But what's the issue?

641
00:34:07.439 --> 00:34:11.259
If the Owner is here instead of there

642
00:34:13.001 --> 00:34:15.441
did you set the Owner on the client?

643
00:34:15.441 --> 00:34:17.541
The server wouldn't know

644
00:34:17.541 --> 00:34:19.640
So, communication wouldn't be possible

645
00:34:19.641 --> 00:34:23.041
So, the Owner setting must be done on the server

646
00:34:23.041 --> 00:34:25.991
so that the server can communicate

647
00:34:25.991 --> 00:34:29.799
and coordinate all these settings based on the owner

648
00:34:29.799 --> 00:34:32.599
Alright, let's move this part

649
00:34:32.599 --> 00:34:36.821
to the NetTPSCharacter header file for testing purposes

650
00:34:36.821 --> 00:34:38.461
I'd like to see

651
00:34:39.840 --> 00:34:42.490
how this Owner with the connection behaves

652
00:34:42.490 --> 00:34:45.960
by printing a log message at the bottom

653
00:34:45.961 --> 00:34:49.440
In the public section

654
00:34:49.440 --> 00:34:53.300
let's print out

655
00:34:55.421 --> 00:34:57.281
the network-related members to see

656
00:34:57.281 --> 00:34:59.081
First, to continue printing

657
00:34:59.081 --> 00:35:03.280
let's add the Tick function in the Lifecycle Functions

658
00:35:03.280 --> 00:35:08.499
Add the virtual void Tick function for printing

659
00:35:10.739 --> 00:35:15.960
Place the virtual void Tick function like this

660
00:35:18.671 --> 00:35:22.501
and then I'll create a function below for printing network logs

661
00:35:22.520 --> 00:35:27.680
I will name it printNetRog as void

662
00:35:27.681 --> 00:35:29.760
So, shall we create two functions?

663
00:35:29.760 --> 00:35:32.400
Let's implement Tick first

664
00:35:34.239 --> 00:35:38.339
Then, let's implement

665
00:35:38.339 --> 00:35:40.500
the printNetRog function right below

666
00:35:42.559 --> 00:35:47.879
The two functions are registered in NetTPSCharacter.cpp, right?

667
00:35:49.359 --> 00:35:55.899
And in the Tick function, be sure to call super.tick first

668
00:35:58.239 --> 00:36:02.589
And to ensure that this Tick function continues to be called

669
00:36:02.589 --> 00:36:04.919
 Tick needs to be operational

670
00:36:04.919 --> 00:36:09.359
By default, this is turned off in the constructor of NetTPSCharacter

671
00:36:09.360 --> 00:36:13.599
So I'll set this to true to turn it on

672
00:36:13.599 --> 00:36:15.799
Let's put this up to the constructor function

673
00:36:15.799 --> 00:36:18.899
I'll add it right at the top of NetTPSCharacter

674
00:36:20.421 --> 00:36:26.321
Here, I'll set the property bCanEverTick

675
00:36:26.321 --> 00:36:30.080
from PrimaryActorTick to true

676
00:36:30.080 --> 00:36:33.559
Setting bCanEverTick to true ensures that the Tick function will continue to be called

677
00:36:34.661 --> 00:36:38.461
And now let's move back to Tick

678
00:36:38.461 --> 00:36:45.840
Here, I'll just put the code to call the printNetRog function

679
00:36:45.840 --> 00:36:51.400
Then Tick will continuously output some log values

680
00:36:51.401 --> 00:36:57.000
Here, I'll add the content

681
00:36:57.000 --> 00:36:59.400
so that I can continuously output this network log

682
00:36:59.400 --> 00:37:01.999
to the console debug log window

683
00:37:02.000 --> 00:37:03.950
I'll first print

684
00:37:03.950 --> 00:37:07.279
the connection-related information here

685
00:37:07.279 --> 00:37:09.929
Let's see

686
00:37:09.929 --> 00:37:12.680
how well the current output of the user's connection is working

687
00:37:12.680 --> 00:37:19.580
I'll set it as const FString.connectionString for the string

688
00:37:19.580 --> 00:37:21.559
GetNetConnection

689
00:37:21.559 --> 00:37:25.309
If you look at it

690
00:37:25.309 --> 00:37:28.280
GetNetConnection returns a UNetConnection object

691
00:37:28.280 --> 00:37:31.530
if that value exist

692
00:37:31.530 --> 00:37:34.320
If it's not a null pointer, what would we do if it exists?

693
00:37:34.320 --> 00:37:38.499
I'll put ValidConnection in the text

694
00:37:39.840 --> 00:37:41.140
That means I have the connection

695
00:37:41.140 --> 00:37:44.760
Otherwise, I'll use the ternary operator

696
00:37:46.481 --> 00:37:50.081
to put InvalidConnection

697
00:37:51.140 --> 00:37:55.999
So what happens if data comes

698
00:37:55.999 --> 00:37:57.449
through the GetNetConnection function?

699
00:37:57.449 --> 00:37:58.599
We want to output ValidConnection if it exists

700
00:37:58.599 --> 00:37:59.799
 and if not

701
00:37:59.799 --> 00:38:03.520
output InvalidConnection

702
00:38:03.520 --> 00:38:08.560
and let's print this conStr value below

703
00:38:08.560 --> 00:38:14.800
We'll use the drawDebugString function to output the debug string

704
00:38:14.800 --> 00:38:20.400
getWorld and then the position is printed at the actor's location

705
00:38:20.400 --> 00:38:27.280
Print the string conStr at this player's position

706
00:38:28.040 --> 00:38:30.799
Put 'actor, baseActor are null' at the end

707
00:38:32.599 --> 00:38:36.420
And let's set the color to white

708
00:38:38.520 --> 00:38:41.119
for FColor

709
00:38:43.079 --> 00:38:47.720
And let's set the value at the end to 0

710
00:38:49.920 --> 00:38:55.759
Then let's put true, and the value as 1

711
00:38:58.239 --> 00:39:01.520
Now let's build it

712
00:39:03.800 --> 00:39:08.520
I want to display the screen with conStr value set to white

713
00:39:14.199 --> 00:39:15.940
It's built now

714
00:39:19.180 --> 00:39:21.079
Let's move to the Unreal Editor

715
00:39:23.040 --> 00:39:25.140
Let's delete

716
00:39:25.140 --> 00:39:27.101
the test object we placed here

717
00:39:27.101 --> 00:39:28.921
for testing purposes

718
00:39:32.719 --> 00:39:33.519
Alright, done

719
00:39:35.501 --> 00:39:37.781
Alright, go ahead and press the play button

720
00:39:37.801 --> 00:39:39.621
How is it then?

721
00:39:39.621 --> 00:39:42.071
The "InvalidConnection" message is being displayed

722
00:39:42.071 --> 00:39:44.479
on the user's screen right now

723
00:39:44.520 --> 00:39:45.720
Do you see it?

724
00:39:45.720 --> 00:39:49.660
I see 'InvalidConnection' printed here in front of me

725
00:39:51.640 --> 00:39:55.490
Why does it say 'InvalidConnection' on mine right now?

726
00:39:55.490 --> 00:39:56.520
Is the connection not there?

727
00:39:56.521 --> 00:40:00.880
That's because it's a dedicated listen server

728
00:40:00.880 --> 00:40:03.030
A listen server means the server and client

729
00:40:03.030 --> 00:40:05.220
are physically in the same space

730
00:40:05.220 --> 00:40:08.800
Logically they are separate, right?

731
00:40:08.800 --> 00:40:12.319
But physically being in the same space, how does that work?

732
00:40:12.320 --> 00:40:15.619
There's no real need to have a connection object

733
00:40:15.620 --> 00:40:18.619
internally, it's just itself, right? The connection doesn't really matter

734
00:40:18.619 --> 00:40:22.800
So this means there's no actual connection itself

735
00:40:22.801 --> 00:40:24.801
There's no meaning to being connected with oneself

736
00:40:24.801 --> 00:40:26.920
It's about connecting with other users

737
00:40:26.920 --> 00:40:30.470
So, in this form created by the server

738
00:40:30.470 --> 00:40:32.640
does it currently need a connection or not? It does not

739
00:40:32.640 --> 00:40:34.340
Since it's both

740
00:40:35.581 --> 00:40:37.001
the server and the client itself

741
00:40:38.521 --> 00:40:40.321
there's no need for a connection here

742
00:40:40.341 --> 00:40:42.521
Alright, next let's add another play button

743
00:40:42.521 --> 00:40:46.121
I'll add an 'Add Client' button at the top

744
00:40:46.121 --> 00:40:47.359
Where is it located? It's right here

745
00:40:47.359 --> 00:40:50.009
By pressing this button

746
00:40:50.009 --> 00:40:52.280
you'll be able to add the button located here

747
00:40:54.220 --> 00:40:55.420
It's right here

748
00:40:55.420 --> 00:40:59.980
Let's click this button

749
00:40:59.981 --> 00:41:01.931
So now a popup should appear, right?

750
00:41:01.931 --> 00:41:03.520
So then another player will appear

751
00:41:03.520 --> 00:41:08.580
Right now, you can see this newly added one, and it's my player

752
00:41:08.581 --> 00:41:12.060
And in this client window, it says 'Client'

753
00:41:12.060 --> 00:41:14.960
In the client window, this is currently the main character of the client

754
00:41:14.960 --> 00:41:17.099
and it's a character on the server

755
00:41:17.099 --> 00:41:18.449
Alright, let's see

756
00:41:18.449 --> 00:41:21.160
Your own character here is valid, indicating it's yours

757
00:41:23.361 --> 00:41:25.641
The character on the server is invalid

758
00:41:25.641 --> 00:41:28.441
and the newly added one needs a valid connection

759
00:41:28.441 --> 00:41:30.000
 for communication between them

760
00:41:30.881 --> 00:41:33.631
In reverse, when you look at it from this side

761
00:41:33.631 --> 00:41:35.161
your own character shows a valid connection

762
00:41:35.161 --> 00:41:36.461
while the server's character shows

763
00:41:36.461 --> 00:41:39.380
 an invalid connection

764
00:41:39.380 --> 00:41:41.880
Let's print out the current owner states of these characters

765
00:41:41.880 --> 00:41:44.020
to see how they're assigned

766
00:41:45.301 --> 00:41:46.651
Alright, print

767
00:41:46.651 --> 00:41:49.561
Here, let's add it

768
00:41:50.740 --> 00:41:53.260
inside the NetLog function

769
00:41:53.260 --> 00:41:58.620
This time, let's name const FString as ownerName

770
00:41:58.620 --> 00:42:03.979
If there is GetOwner in ownerName

771
00:42:06.201 --> 00:42:11.621
if there is owner, I will put the name in GetOwner

772
00:42:11.621 --> 00:42:16.140
Use GetName to put the name in

773
00:42:16.140 --> 00:42:17.890
If not

774
00:42:17.890 --> 00:42:24.620
I will display that owner does not exist in TEXT like this

775
00:42:24.981 --> 00:42:29.081
If owner exists, put the name of owner into ownerName

776
00:42:29.082 --> 00:42:32.308
If owner does not exist, place 'owner does not exist' like this

777
00:42:36.419 --> 00:42:37.419
Alright

778
00:42:37.419 --> 00:42:40.019
Then, I'll combine these two sentences

779
00:42:40.019 --> 00:42:42.220
and make it into one sentence

780
00:42:42.221 --> 00:42:47.480
n const FString, insert logStr

781
00:42:47.480 --> 00:42:53.459
and FString printf, and here TEXT

782
00:42:53.459 --> 00:43:00.959
connection with

783
00:43:00.959 --> 00:43:07.020
%s newline for line break

784
00:43:07.020 --> 00:43:12.020
Then, append conStr at the end

785
00:43:12.020 --> 00:43:16.480
Next, insert

786
00:43:18.221 --> 00:43:20.021
ownerName

787
00:43:20.021 --> 00:43:23.121
By doing this, create logStr using printf

788
00:43:23.121 --> 00:43:28.139
and then use logStr

789
00:43:28.139 --> 00:43:30.200
 instead of conStr in draw debug string

790
00:43:32.460 --> 00:43:36.859
Alright, then the two variables

791
00:43:36.859 --> 00:43:42.500
conStr and ownerName, that we want to output will both be included

792
00:43:44.339 --> 00:43:50.419
If you want to print this to the console

793
00:43:50.420 --> 00:43:52.599
you can do it using UE_LOG

794
00:43:52.599 --> 00:43:54.849
For now, to visually see it on the screen

795
00:43:54.849 --> 00:43:58.320
we will use draw debug string to output it

796
00:43:59.779 --> 00:44:00.880
Built it

797
00:44:06.139 --> 00:44:08.580
Shall we go back to the Unreal Editor and try playing it again this time?

798
00:44:10.501 --> 00:44:12.180
So, how is it on the server now?

799
00:44:12.180 --> 00:44:14.180
Player controller 1, player controller 0

800
00:44:14.180 --> 00:44:15.259
all of this gets printed out, right?

801
00:44:15.260 --> 00:44:17.910
But it doesn't work on the client

802
00:44:17.910 --> 00:44:20.019
Why is that?

803
00:44:20.019 --> 00:44:23.319
Because the server has

804
00:44:23.319 --> 00:44:25.480
all the player controllers of all the clients

805
00:44:25.480 --> 00:44:27.380
so it can print them out

806
00:44:28.961 --> 00:44:31.301
Role and Authority

807
00:44:33.420 --> 00:44:37.059
Now, let's learn about role and authority

808
00:44:37.059 --> 00:44:42.139
Role means role, and this refers to authority

809
00:44:42.961 --> 00:44:47.561
It's the networking structure

810
00:44:47.561 --> 00:44:51.300
 provided by Unreal Engine that facilitates communication between server and client types

811
00:44:51.301 --> 00:44:56.020
It's the structure where the server and clients communicate together

812
00:44:56.020 --> 00:45:01.580
So, why does this concept of role, or role-playing, become important?

813
00:45:01.580 --> 00:45:03.280
 It's because of this aspect

814
00:45:03.280 --> 00:45:07.779
In a listen server, it can act both as a server and as a client

815
00:45:07.780 --> 00:45:11.039
So, this becomes very important for us

816
00:45:11.039 --> 00:45:14.289
This entity is currently a client

817
00:45:14.789 --> 00:45:17.700
but because it's also together with the server

818
00:45:17.700 --> 00:45:20.800
these clients can physically be together

819
00:45:20.800 --> 00:45:22.940
with multiple clients at the same time

820
00:45:22.940 --> 00:45:25.690
However, logically, how is it?

821
00:45:25.690 --> 00:45:30.341
It's in a dropped state

822
00:45:30.342 --> 00:45:33.142
However, physically, since they are together

823
00:45:33.142 --> 00:45:34.781
there's a need to distinguish between them

824
00:45:34.781 --> 00:45:38.019
Since they are together in one place in the code

825
00:45:38.019 --> 00:45:40.119
we need to distinguish this part

826
00:45:40.119 --> 00:45:44.019
So, currently, whether my role is the server

827
00:45:44.019 --> 00:45:46.219
or whether it's here together in this way

828
00:45:46.219 --> 00:45:48.769
because it's a listen server

829
00:45:48.769 --> 00:45:52.899
there's a need to distinguish

830
00:45:52.900 --> 00:45:55.499
whether I'm currently serving as the server or not

831
00:45:55.500 --> 00:45:58.599
Because if I'm the server, I should be fulfilling the server's role

832
00:45:58.599 --> 00:46:01.179
If I only have client permissions

833
00:46:01.180 --> 00:46:04.280
then I shouldn't be taking on server roles

834
00:46:04.280 --> 00:46:06.759
recklessly, right?

835
00:46:06.759 --> 00:46:11.300
That's why having this concept of roles is necessary

836
00:46:11.300 --> 00:46:15.059
There are three types or forms of roles

837
00:46:15.059 --> 00:46:19.520
Let's distinguish between authority and proxy roles

838
00:46:20.821 --> 00:46:25.341
'Proxy' generally refers to a representative, substitute, or delegate

839
00:46:26.501 --> 00:46:30.260
It's not done directly, you could also say it's a replication

840
00:46:30.261 --> 00:46:32.011
Let's just say it's a replica or a duplicate

841
00:46:32.011 --> 00:46:33.520
Let's just interpret it as a proxy

842
00:46:33.520 --> 00:46:34.770
Then, how is it?

843
00:46:34.770 --> 00:46:39.969
Authority is the server itself, so it's the entity directly generating the data

844
00:46:39.969 --> 00:46:44.619
It's the entity that directly creates or generates the data

845
00:46:44.619 --> 00:46:45.661
How about clients?

846
00:46:45.662 --> 00:46:47.361
They are not the ones creating or generating data

847
00:46:47.361 --> 00:46:50.859
Clients request data from the server and simply replicate or duplicate it

848
00:46:50.860 --> 00:46:53.919
That's exactly what we call a proxy

849
00:46:53.919 --> 00:46:58.059
So, the two below immediately become clients

850
00:46:58.059 --> 00:47:00.119
The one above becomes the server

851
00:47:01.481 --> 00:47:02.481
Right?

852
00:47:04.801 --> 00:47:07.301
Let's take a look at

853
00:47:07.301 --> 00:47:10.701
how these roles are

854
00:47:10.701 --> 00:47:12.300
currently structured

855
00:47:14.361 --> 00:47:19.821
Shall we switch over to Visual Studio and navigate to the print log function?

856
00:47:19.821 --> 00:47:22.619
Let's print out the roles we need right here

857
00:47:23.619 --> 00:47:27.419
We can use roles extensively throughout various parts

858
00:47:27.419 --> 00:47:29.720
so let's create a macro

859
00:47:31.021 --> 00:47:33.361
to print out these values

860
00:47:34.319 --> 00:47:38.499
Alright, in the Solution Explorer, on the right

861
00:47:38.499 --> 00:47:42.749
under 'nettps,' besides 'private,' you should see header files in 'public

862
00:47:42.749 --> 00:47:44.980
You have the nettps header file, right?

863
00:47:44.980 --> 00:47:46.630
Let's open it up

864
00:47:48.080 --> 00:47:51.000
Let's open that file up

865
00:47:51.980 --> 00:47:56.239
I'm going to create a macro here

866
00:47:57.381 --> 00:47:59.441
to print out the roles

867
00:47:59.441 --> 00:48:04.879
So, I'll use #define

868
00:48:06.060 --> 00:48:08.610
and I'll consider two things: local role and remote role

869
00:48:08.610 --> 00:48:12.499
This concept of roles can be seen in two different modes

870
00:48:12.499 --> 00:48:14.219
like this

871
00:48:18.619 --> 00:48:25.820
Alright, on the screen, there are clients like this, and there are several of them

872
00:48:25.820 --> 00:48:28.120
The 'local role' refers to

873
00:48:28.120 --> 00:48:30.700
how this entity appears on my screen right now

874
00:48:30.700 --> 00:48:31.800
As I look closely

875
00:48:31.800 --> 00:48:35.350
oh, you're asking

876
00:48:35.350 --> 00:48:37.299
what role you are within my local screen view, right? In that case, you're the authority

877
00:48:37.299 --> 00:48:38.249
So, what is it then?

878
00:48:38.249 --> 00:48:41.680
You can realize that I'm currently the server

879
00:48:41.681 --> 00:48:44.400
We can tell that it's a server

880
00:48:44.420 --> 00:48:49.099
And also, I'll check again

881
00:48:50.821 --> 00:48:53.471
This one's local role is

882
00:48:53.471 --> 00:48:54.701
autonomous proxy

883
00:48:54.701 --> 00:48:55.951
So, what can I do?

884
00:48:55.951 --> 00:48:58.179
I can receive input

885
00:48:58.180 --> 00:49:02.119
I'm a client, not a server, I'm a client

886
00:49:02.119 --> 00:49:05.540
And I can receive input. That's how you can find out

887
00:49:05.541 --> 00:49:07.740
You can do it like this

888
00:49:07.740 --> 00:49:09.840
So, since I can receive input

889
00:49:09.840 --> 00:49:12.140
I can then send data to the server

890
00:49:12.140 --> 00:49:15.039
 and make requests like that

891
00:49:15.039 --> 00:49:18.380
Then, when I analyzed my local role here

892
00:49:18.381 --> 00:49:21.281
I found out that I'm simulating

893
00:49:21.281 --> 00:49:24.581
So, can I receive user input?

894
00:49:24.581 --> 00:49:25.940
No, I can't

895
00:49:25.941 --> 00:49:27.841
I shouldn't handle those kinds of things

896
00:49:27.841 --> 00:49:29.920
This differentiation is necessary because of reasons like this

897
00:49:29.920 --> 00:49:32.779
So, why is remote role necessary?

898
00:49:32.779 --> 00:49:34.779
When I looked at Remote Role

899
00:49:34.779 --> 00:49:35.779
 I found out

900
00:49:35.779 --> 00:49:38.860
it's simply a simulated proxy

901
00:49:38.860 --> 00:49:42.639
Or rather, it's autonomous; the authority

902
00:49:42.640 --> 00:49:46.779
So you're the authority
Then, what does that mean?

903
00:49:46.779 --> 00:49:51.700
It means that on the remote side, you're in the server role, right?

904
00:49:54.300 --> 00:49:59.239
In server mode, when you look at the others, 'simulated' usually appears, right?

905
00:49:59.240 --> 00:50:00.890
let's see it like this

906
00:50:00.890 --> 00:50:02.819
 In server-client mode, when it's like this

907
00:50:02.819 --> 00:50:06.540
 I'm here as an autonomous proxy

908
00:50:06.541 --> 00:50:09.480
So, what should I show to this one here?

909
00:50:09.480 --> 00:50:13.459
Locally, I currently appear as an autonomous proxy to myself

910
00:50:13.460 --> 00:50:15.360
but how would I appear to this one?

911
00:50:15.360 --> 00:50:18.259
Since this entity is created by the server itself

912
00:50:18.259 --> 00:50:19.609
it has authority

913
00:50:19.609 --> 00:50:24.299
So, from this entity's perspective, its local role is authority

914
00:50:24.299 --> 00:50:25.549
I'm the server, right?

915
00:50:25.549 --> 00:50:27.499
So, it's authority

916
00:50:27.499 --> 00:50:30.699
However, what is it on the remote side?

917
00:50:30.700 --> 00:50:34.799
It would become an autonomous proxy on the client side

918
00:50:34.799 --> 00:50:38.620
You can see it divided into these two modes like this

919
00:50:38.621 --> 00:50:41.000
Local Role

920
00:50:41.000 --> 00:50:44.800
and then Remote Role

921
00:50:44.800 --> 00:50:46.840
We can view it divided into local and remote roles

922
00:50:48.321 --> 00:50:50.571
However, when you're actually working

923
00:50:50.571 --> 00:50:54.521
explicitly distinguishing between Local Role and Remote Role

924
00:50:54.521 --> 00:50:56.121
saying this is authority

925
00:50:56.121 --> 00:50:58.699
and this is autonomous proxy

926
00:50:58.700 --> 00:51:00.900
can sometimes be challenging to manage

927
00:51:00.900 --> 00:51:02.819
So, there's a function

928
00:51:02.819 --> 00:51:08.300
that provides whether I'm the server

929
00:51:08.301 --> 00:51:10.101
or controlling it locally

930
00:51:10.101 --> 00:51:11.920
We'll look into those things a bit later

931
00:51:11.920 --> 00:51:15.520
First, let's check the current status of the Local Role

932
00:51:15.520 --> 00:51:17.039
and Remote Role

933
00:51:18.259 --> 00:51:21.309
When we get there

934
00:51:21.309 --> 00:51:22.359
 I'll try to check the Local Role

935
00:51:22.359 --> 00:51:24.741
Here, leave a space

936
00:51:24.741 --> 00:51:27.721
and then open parentheses

937
00:51:29.139 --> 00:51:32.839
(UEnum GetValueAsString)

938
00:51:32.839 --> 00:51:34.559
Through this function

939
00:51:36.881 --> 00:51:40.841
you can get a value called ENetRole

940
00:51:42.421 --> 00:51:49.559
Next, you can simply call GetLocalRole on this actor

941
00:51:51.019 --> 00:51:55.019
In other words, you can get GetLocalRole here and use it directly

942
00:51:55.019 --> 00:51:58.019
This means you can also print it this way

943
00:51:58.019 --> 00:52:00.869
Right now, we're trying to print this

944
00:52:00.869 --> 00:52:03.781
 in NetTPSCharacter here

945
00:52:03.781 --> 00:52:06.041
This means we can print it like this

946
00:52:08.620 --> 00:52:12.339
const FString

947
00:52:12.420 --> 00:52:15.299
So here, if it's a role like

948
00:52:16.860 --> 00:52:22.220
Local Role, you can attach it like this

949
00:52:22.220 --> 00:52:25.820
If you go there, you'll see that it returns the role

950
00:52:25.820 --> 00:52:28.199
What role is it currently set to?

951
00:52:30.141 --> 00:52:35.221
GetLocalRole is currently set like this

952
00:52:35.221 --> 00:52:38.071
It's currently designed to fetch

953
00:52:38.071 --> 00:52:40.459
and return the role I'm assigned in the network

954
00:52:40.460 --> 00:52:42.960
We're trying to convert that value, which is an Enum

955
00:52:42.960 --> 00:52:45.619
into a string so we can print it

956
00:52:45.619 --> 00:52:47.419
But since we keep using these terms frequently

957
00:52:47.419 --> 00:52:48.660
it ends up being used in various places

958
00:52:48.660 --> 00:52:51.680
I'm trying to make a macro out of this

959
00:52:53.761 --> 00:52:58.881
Now, coming back to nettps.h, I've set it up like this

960
00:52:58.881 --> 00:53:00.281
Next, let's change it to remote role

961
00:53:00.281 --> 00:53:04.060
instead of local role this time

962
00:53:06.379 --> 00:53:08.229
Here, instead of GetLocalRole

963
00:53:08.229 --> 00:53:12.219
 you should put GetRemoteRole

964
00:53:13.379 --> 00:53:17.779
In the NetTPSCharacter.cpp file

965
00:53:17.779 --> 00:53:21.620
you're going to add this content to DrawDebugString in PrintNetLog

966
00:53:21.620 --> 00:53:23.920
So, you'll place logString

967
00:53:23.920 --> 00:53:25.639
 followed by ownerName

968
00:53:27.341 --> 00:53:30.491
and a newline character

969
00:53:30.491 --> 00:53:32.581
You'll add a newline here

970
00:53:32.581 --> 00:53:36.019
and print both the local role and remote role

971
00:53:36.019 --> 00:53:37.800
You'll place local role

972
00:53:40.719 --> 00:53:42.319
%s here

973
00:53:42.319 --> 00:53:44.669
followed by a newline

974
00:53:44.669 --> 00:53:49.860
and then remote role %s

975
00:53:49.860 --> 00:53:54.620
Then you can add Local Role

976
00:53:56.980 --> 00:54:02.000
followed by remote role at the end

977
00:54:04.139 --> 00:54:06.889
So now, Local Role and Remote Role should appear in red

978
00:54:06.889 --> 00:54:08.639
You need to include it

979
00:54:08.639 --> 00:54:09.659
So, at the top

980
00:54:12.939 --> 00:54:16.039
 include nettps.h

981
00:54:16.039 --> 00:54:20.259
with a #include directive here

982
00:54:21.939 --> 00:54:24.589
I'll go ahead and add #include

983
00:54:24.589 --> 00:54:28.000
"nettps.h" at the top of NetTPSCharacter.cpp

984
00:54:31.880 --> 00:54:35.659
Let's go check to make sure everything is working properly, and then I'll build it

985
00:54:42.261 --> 00:54:45.521
Let's go ahead and try playing to see how it works

986
00:54:45.521 --> 00:54:50.620
So currently, it shows 'Connection: Invalid Connection' here

987
00:54:50.621 --> 00:54:53.221
and Player Controller 0 is set as the owner

988
00:54:53.221 --> 00:54:55.621
Local Role is set to 'Role: Authority'

989
00:54:55.621 --> 00:54:58.420
and Remote Role is 'Role: Autonomous Proxy'

990
00:55:00.421 --> 00:55:03.761
Since it's a client, it acts as both server and client

991
00:55:03.761 --> 00:55:07.311
So, on the server side, it's a server, so what about the Local Role?

992
00:55:07.311 --> 00:55:08.420
It's set as 'Authority'

993
00:55:08.421 --> 00:55:09.771
and since it's also a client

994
00:55:09.771 --> 00:55:11.880
because it can receive input

995
00:55:11.880 --> 00:55:14.980
Remote Role is set to 'Autonomous Proxy'

996
00:55:14.980 --> 00:55:16.979
Alright, let's run one more test

997
00:55:20.781 --> 00:55:23.731
Alright, now for clients

998
00:55:23.731 --> 00:55:26.579
it shows the connection and owner

999
00:55:26.579 --> 00:55:28.379
Next, what about the Local Role?

1000
00:55:28.380 --> 00:55:31.799
Since this is the server, it's a server window here

1001
00:55:31.799 --> 00:55:37.100
So, here it shows that the Local Role is set to 'Authority'

1002
00:55:37.101 --> 00:55:39.601
And the Remote Role is set to 'Autonomous'

1003
00:55:39.601 --> 00:55:40.580
It's a client

1004
00:55:40.580 --> 00:55:42.880
Let's go over to this client window and take a look

1005
00:55:42.880 --> 00:55:44.460
In the client window

1006
00:55:44.461 --> 00:55:46.511
the connection is currently valid

1007
00:55:46.511 --> 00:55:49.060
The Local Role is set to 'Autonomous Proxy'

1008
00:55:49.060 --> 00:55:49.610
Right?

1009
00:55:49.610 --> 00:55:52.119
So, this means it can receive user input

1010
00:55:52.119 --> 00:55:57.019
The Remote Role, for the server-side, becomes 'Authority', correct?

1011
00:55:57.019 --> 00:55:58.579
The two roles are reversed

1012
00:55:58.580 --> 00:56:03.439
On the server side, it's 'Authority', and on the remote side

1013
00:56:03.439 --> 00:56:04.639
it's 'Autonomous'

1014
00:56:04.639 --> 00:56:06.439
Alright, from the client's perspective

1015
00:56:06.439 --> 00:56:11.070
its own local role is 'Autonomous Proxy'

1016
00:56:11.070 --> 00:56:12.020
What can we do?

1017
00:56:12.020 --> 00:56:14.440
It means it can handle user input processing

1018
00:56:14.440 --> 00:56:18.740
It means it can make requests to the server, like saying, "Hey, do this for me"

1019
00:56:18.741 --> 00:56:20.741
It means it can request the server to perform certain actions

1020
00:56:20.741 --> 00:56:23.200
although the logic itself must be implemented locally

1021
00:56:23.200 --> 00:56:24.500
Where does the logic execute?

1022
00:56:24.500 --> 00:56:25.860
It runs on this server

1023
00:56:25.860 --> 00:56:31.459
and Remote Role indicates it's the server

1024
00:56:32.381 --> 00:56:35.161
Alright, let's take a look at the server-side experience

1025
00:56:35.161 --> 00:56:38.979
Let's switch to the client window to see how it looks when it's acting as a server

1026
00:56:41.100 --> 00:56:42.599
Here

1027
00:56:46.361 --> 00:56:48.111
this character is the server character

1028
00:56:48.111 --> 00:56:50.141
What is the Local Role set to for the server character?

1029
00:56:50.141 --> 00:56:51.719
It's set to simulate physics

1030
00:56:51.719 --> 00:56:55.119
So, on the server

1031
00:56:55.119 --> 00:56:58.040
this character is set to simulate physics

1032
00:56:58.041 --> 00:57:00.420
meaning when the server-side character moves or performs actions

1033
00:57:00.421 --> 00:57:02.920
 the clients can simulate data related to it

1034
00:57:02.920 --> 00:57:06.060
Of course, the Local Role can only be set to simulate physics

1035
00:57:06.061 --> 00:57:07.761
When the character moves on the server

1036
00:57:07.761 --> 00:57:11.000
since it's not me, I just replicate this data

1037
00:57:11.000 --> 00:57:15.259
So, it's simulated physics

1038
00:57:15.259 --> 00:57:17.209
and since it's on the server

1039
00:57:17.209 --> 00:57:19.459
it means

1040
00:57:19.459 --> 00:57:20.580
the server is currently handling this

1041
00:57:21.941 --> 00:57:23.441
Do you understand?

1042
00:57:23.441 --> 00:57:27.501
So, I've analyzed

1043
00:57:27.501 --> 00:57:29.540
how each character's role is determined

1044
00:57:29.540 --> 00:57:34.700
when created on both the server and client screens

1045
00:57:34.701 --> 00:57:37.151
It's done

1046
00:57:37.151 --> 00:57:38.551
And as I mentioned

1047
00:57:38.551 --> 00:57:43.739
in development, the current role itself isn't usually critically important

1048
00:57:43.740 --> 00:57:45.159
Why?

1049
00:57:45.160 --> 00:57:49.460
We're mainly concerned with

1050
00:57:49.460 --> 00:57:51.079
whether it's the server or if I can receive input locally

1051
00:57:51.079 --> 00:57:53.729
So, I can receive input

1052
00:57:53.729 --> 00:57:56.879
and then I can request the server to process this data as needed

1053
00:57:56.879 --> 00:57:58.039
That's what matters

1054
00:57:58.039 --> 00:57:59.939
Actually, being an Autonomous Proxy

1055
00:57:59.939 --> 00:58:01.799
these things might not matter much

1056
00:58:03.101 --> 00:58:06.101
So, there are functions that provide these checks

1057
00:58:06.101 --> 00:58:08.981
such as HasAuthority

1058
00:58:08.981 --> 00:58:11.500
and IsLocallyControlled

1059
00:58:13.101 --> 00:58:15.751
So, if you look

1060
00:58:15.751 --> 00:58:17.001
there's a function like NetTPSCharacter

1061
00:58:17.001 --> 00:58:20.440
I'm going to delete this function right away, HasAuthority

1062
00:58:21.961 --> 00:58:23.511
This function exists

1063
00:58:23.511 --> 00:58:24.900
 It provides itself

1064
00:58:24.900 --> 00:58:26.800
If you look into HasAuthority

1065
00:58:26.800 --> 00:58:28.150
it basically means 'do you have authority'

1066
00:58:28.150 --> 00:58:30.620
 in other words, 'are you the server?' It's the same thing

1067
00:58:30.621 --> 00:58:33.271
Let's take a look

1068
00:58:33.271 --> 00:58:35.280
Let's go see how it's implemented

1069
00:58:35.280 --> 00:58:38.339
How is HasAuthority implemented internally?

1070
00:58:38.340 --> 00:58:41.799
What is the Local Role set to?

1071
00:58:41.799 --> 00:58:45.199
Is it authority? In other words, is it the server? That's what it's asking

1072
00:58:45.199 --> 00:58:49.361
If the local role itself is set to authority, then it means it's the server

1073
00:58:50.980 --> 00:58:55.890
So HasAuthority essentially asks 'are you the server?'

1074
00:58:55.890 --> 00:58:58.440
 It analyzes the role itself to determine

1075
00:58:58.440 --> 00:59:00.760
whether it's the server or not

1076
00:59:00.760 --> 00:59:03.610
If we're talking about a real implementation of HasAuthority in development

1077
00:59:03.610 --> 00:59:05.380
then yes, it typically means "if it's the server"

1078
00:59:05.381 --> 00:59:10.760
Next, I want to send the input from the user

1079
00:59:10.760 --> 00:59:12.860
saying they shot a gun

1080
00:59:12.860 --> 00:59:14.939
to the server

1081
00:59:14.940 --> 00:59:17.519
so that the server can handle that game logic

1082
00:59:17.519 --> 00:59:22.100
In that case, how would I know

1083
00:59:22.101 --> 00:59:23.351
whether I can shoot the gun or not?

1084
00:59:23.351 --> 00:59:27.020
So, I need to know whether I am the Autonomous Proxy

1085
00:59:27.020 --> 00:59:33.860
There's a function called IsLocallyControlled that helps with those things

1086
00:59:33.861 --> 00:59:35.561
Since this is a Pawn

1087
00:59:35.561 --> 00:59:38.160
it operates with the IsLocallyControlled function from the Pawn

1088
00:59:38.160 --> 00:59:40.460
If it's a player controller

1089
00:59:40.460 --> 00:59:42.380
then there's a function called IsLocalController

1090
00:59:42.381 --> 00:59:44.881
Let's  go ahead and try using it to learn more about how that function works

1091
00:59:44.881 --> 00:59:46.200
Let's go ahead and take a look first

1092
00:59:46.200 --> 00:59:51.260
When you see IsLocallyControlled

1093
00:59:51.261 --> 00:59:52.261
it means checking how it's implemented inside

1094
00:59:52.261 --> 00:59:57.340
When you have a controller, you use IsLocalController

1095
00:59:57.340 --> 01:00:01.100
So, on the client side

1096
01:00:01.101 --> 01:00:03.160
how many player controllers are there?

1097
01:00:03.161 --> 01:00:05.161
I mentioned there's only one

1098
01:00:05.161 --> 01:00:06.960
There will be only one, then

1099
01:00:06.960 --> 01:00:11.669
So, since there's only one, why bother checking if I'm local?

1100
01:00:11.669 --> 01:00:16.419
Because the server also has the same client player controller

1101
01:00:16.419 --> 01:00:20.680
 it needs to check whether it's local or not, because it could be either the server or a client

1102
01:00:20.680 --> 01:00:21.580
How?

1103
01:00:21.580 --> 01:00:22.430
So, since there's a controller

1104
01:00:22.430 --> 01:00:24.980
it means there's a player controller

1105
01:00:24.980 --> 01:00:27.740
that can handle input

1106
01:00:27.741 --> 01:00:30.740
That's why it checks again here

1107
01:00:30.740 --> 01:00:33.059
because you could be both a client and potentially a server, depending on the context

1108
01:00:33.059 --> 01:00:38.339
If you go into IsLocalController, you can see how it's implemented

1109
01:00:39.299 --> 01:00:41.049
There's NetMode

1110
01:00:41.049 --> 01:00:45.419
as you scroll down, you'll come across sections like this

1111
01:00:45.419 --> 01:00:48.119
If NetMode indicates that it's currently running on the client

1112
01:00:48.119 --> 01:00:49.469
what is the Local Role set to?

1113
01:00:49.469 --> 01:00:51.579
AutonomousProxy

1114
01:00:51.580 --> 01:00:52.830
It's the client window

1115
01:00:52.830 --> 01:00:55.939
NetMode indicates that it's running in the client window

1116
01:00:55.939 --> 01:00:58.389
And what is the Local Role?

1117
01:00:58.389 --> 01:00:59.940
AutonomousProxy

1118
01:00:59.940 --> 01:01:01.040
So, what does that mean?

1119
01:01:01.040 --> 01:01:05.780
It means the user can receive input and request actions from the server

1120
01:01:05.781 --> 01:01:11.160
So, what exactly does IsLocalController refer to or do?

1121
01:01:11.160 --> 01:01:14.980
It means checking whether it's currently controlling locally

1122
01:01:14.981 --> 01:01:19.040
It checks whether on the client side, it's controlling itself
Am I able to receive input?

1123
01:01:19.040 --> 01:01:21.020
That's what this is about

1124
01:01:22.301 --> 01:01:27.301
So, here "AutonomousProxy" is not the case on the remote side

1125
01:01:27.301 --> 01:01:29.051
But here it says it has Authority

1126
01:01:29.051 --> 01:01:33.880
So, even in the case of a listen server where the client and server are together

1127
01:01:33.880 --> 01:01:37.659
how does it work when the client is controlling itself?

1128
01:01:37.661 --> 01:01:39.121
 It should still be able to receive input

1129
01:01:40.319 --> 01:01:44.939
So, here it's true, and the rest are false

1130
01:01:44.939 --> 01:01:46.539
AutonomousProxy

1131
01:01:46.539 --> 01:01:48.739
In cases where the client can receive input

1132
01:01:48.739 --> 01:01:50.500
it returns true like this

1133
01:01:50.501 --> 01:01:55.380
So, you don't need to manually distinguish between Authority, AutonomousProxy

1134
01:01:55.380 --> 01:01:58.939
and such things like that

1135
01:01:58.940 --> 01:02:03.479
You can use functions like HasAuthority, IsLocalController, or IsLocallyControlled

1136
01:02:03.479 --> 01:02:06.880
to differentiate between these roles

1137
01:02:07.980 --> 01:02:14.599
Alright, we were able to cover roles and understanding Authority through this discussion

1138
01:02:15.699 --> 01:02:18.199
In our class, we proceed with creating network games

1139
01:02:18.199 --> 01:02:21.900
using a listen server

1140
01:02:21.900 --> 01:02:25.141
Let's summarize the concepts we’ve covered in this lesson

1141
01:02:25.141 --> 01:02:26.921
Network connection structure and communication processing structure

1142
01:02:26.922 --> 01:02:28.741
Network Connection Structures
Comparing the connection structure between users on a single PC (Standalone) and the Server-Client model types

1143
01:02:28.742 --> 01:02:30.321
Communication Processing Structure
Communication between clients and servers

1144
01:02:30.322 --> 01:02:32.003
Client-side processing logic and server-side processing logic
Two methods of sending logic execution results to users, NetMulticast RPC and Client RPC

1145
01:02:32.003 --> 01:02:34.202
Player Controller and Connection
The structure where Player Controller handles communication between clients and servers

1146
01:02:34.202 --> 01:02:36.561
Player Controller
It possesses an object called UNetConnection

1147
01:02:36.561 --> 01:02:39.041
For a general Actor that exists identically on both the client and server, communication is possible through its owner
The working structure of how an Actor communicates through its owner

1148
01:02:39.041 --> 01:02:41.561
Role and Authority
In a listen server setup, where the server includes clients, it's necessary to differentiate between the server and clients within the running environment

1149
01:02:41.561 --> 01:02:43.721
Types of Roles
There are Authority, AutonomousProxy, and SimulatedProxy roles, with Authority representing the server

1150
01:02:43.721 --> 01:02:45.943
Proxy: A replica of an actor that exists on the server
AutonomousProxy: Refers to a proxy through which a user can send control inputs to the server

1151
01:02:45.943 --> 01:02:47.083
SimulatedProxy: Performs the role of simply replicating values from the server

1152
01:02:47.083 --> 01:02:48.083
The End