文章目录
- 前言
- 网络构架
- 不能信任客户端，所有重要信息通过服务端验证
- Listen Server与Dedicate Server
- 作为客户端的我们，操控的是什么角色
- 框架图
- 网络信息传递的主要方式
前言
最近在跟着一个教程做类csgo的游戏。
做到shift静步的时候，可以发现，当player在服务端运行的时候，动画是非常流程地，而在客户端运行的时候，会明显卡顿。
了解到，这个问题的出现是和网络同步有关的，为了解决这个问题，特此来学习UE4网络部分的内容。
内容参考自b站up主的彻底掌握UE4网络系列视频，讲得非常好。
网络构架
我们知道，网络信息交换的方式不止一种，有服务端-客户端方式，也有P2P方式。
在UE4中，使用的是服务端-客户端的方式，通常都是一个服务器，和一个或者多个客户端连接，以此方式进行通信。
在这种方式下，有几个需要特殊注意的点。
不能信任客户端，所有重要信息通过服务端验证
因为考虑到玩家作弊之类的问题，所以一个客户端上完成的行为、修改的信息，不能直接传递给其他客户端，需要经过服务端验证，验证"合法"以后，再发送给各个客户端。
这也就是为什么采用一个服务端，多客户端的形式来进行通信。
Listen Server与Dedicate Server
在服务端-客户端形式下通信，还可以细分为Listen Server和Dedicate Server。
举一个很直观的例子来理解他们的区别。
相信大家都玩过CS1.6，或者是求生之路2这类游戏，通常都是一个玩家创建房间，然后其他玩家加入这个房间。有时候电脑有点问题，创建房间的玩家退出了，那么整个房间都会崩掉，其他人也没法继续游戏了，大家应该都遇到过这个问题吧？
这种类似于以一个玩家的主机作为服务端、客户端并存，其他玩家作为客户端的方式，就是Listen Server
而这种形式，当然也会存在问题，作为主机的玩家，他的游戏延迟相比其他玩家就会非常地低，而且他的房间崩了，其他人也没法继续游戏了，这个是很影响玩家们的体验感和公平性的。
能解决这种问题的，就是Dedicate Server了。
Dedicate Server是有一个专有服务器来处理信息，所有玩家都是作为客户端来进行连接，这样，玩家之前都会存在延迟，不会谁谁谁的延迟特别低，当然因为网速问题肯定会有差距，但是从通信方式的层面上，是公平的。
(虽然LOL并非UE4开发)大家在打LOL的时候，某个玩家断开连接，其他玩家还是可以继续游戏的，对吧？我想大概就是这样。
作为客户端的我们，操控的是什么角色
我们知道，在我们客户端，有一个我们的角色，在服务端，我们也有一个角色，那么我们操控的是哪个角色呢？
这个问题也困扰了我很久。
安宁老师举了一个很清晰的例子。
比如你在玩FPS游戏，当你开枪射击的时候，遵循我们前面说的不能信任客户端，所有重要信息通过服务端验证的原则，玩家当然是要发送数据给服务端进行检测，比如看看你有没有开无限子弹啊什么的。
当数据验证通过的时候，你打出来了伤害什么的，才会反馈给各个客户端。
但是这样的话，你的客户端会等着服务端返回了，再作下一步操作么？即便网络再快，和服务端之间的通信带来的延迟也会让玩家清晰地感觉到。
所以，当玩家开枪的时候，自己本地的客户端，是会通过模拟，来播放之后的动画，使得玩家能正常体验游戏，但是你是不是真的能对这场游戏本身产生影响，打出伤害、产生物品…这些都要经过服务器验证，才能得到最终的结果。
框架图
从安宁老师的ppt看到的图，我们可以得到如下信息。
GameMode游戏模式是仅仅存在于服务端的。
GameState游戏状态、所有Pawn玩家角色、所有PlayerState玩家状态这些，在服务端、客户端都存在。
但是隶属于每个玩家的控制器Controller，只存在于对应玩家的客户端和服务端中，一个客户端当然没法拿到另一个客户端的玩家控制器。
最后，UI界面是独立出来的，每个端都有一个，且各不相同。
网络信息传递的主要方式
有两种，一种是Replication、Rep_Notify，它的信息方向只能是服务端到客户端。
另一种是RPC，它的方向是任意的，服务端到客户端或者是客户端到服务端都是可以的。
接下来我会继续去深入学习。
