一、Replication

1. 在虚幻引擎中，在客户端与服务器间同步数据和调用程序的过程被称为复制Replication。

• 参考链接：https://dev.epicgames.com/documentation/zh-cn/unreal-engine/networking-and-multiplayer-in-unreal-engine?application_version=5.2

2. 服务器作为游戏主机，保留一个真实授权的游戏状态。换句话说，服务器是多人游戏实际发生的地方。客户端会远程控制其在服务器上各自拥有的Pawn，发送过程调用以使其执行游戏操作。但服务器不会将视觉效果直接流送至客户端显示器。服务器会将游戏状态信息复制到各客户端，告知应存在的Actor、此类Actor的行为，以及不同变量应拥有的值。然后各客户端使用此信息，对服务器上正在发生的情况进行高度模拟。
3. 在网络游戏中，此类交互发生在多个不同场景：服务器上的场景、玩家1客户端的场景、玩家2客户端的场景，以及参与会话的其他所有客户端的额外场景。每台不同机器上的各场景均有各自的Pawn、武器及发射物的副本。服务器是游戏真正运行的地方，但我们要让客户端的场景看似发生了相同事件。因此，需要选择性地向各客户端发送信息，以在服务器上创建场景的视觉代表。
4. 这一过程将在基础游戏交互（碰撞、移动、伤害）、美化效果（视觉效果和音效）和私人玩家信息（HUD更新）间进行划分。这三者各自与网络中的特定机器或机组关联。但是，此信息的复制过程并非完全自动，游戏编程时须指定要复制的信息和接收副本的机器。主要的难点在于选择应复制的信息及方式，以向所有玩家提供一致的游戏体验，同时需最小化信息复制量，尽可能减少网络带宽占用率。

二、基本网络概念

2.1 网络模式和服务器类型

1. 网络模式描述了计算机与网络多人游戏会话的关系。游戏实例可采用以下任意网络模式：
   ① 独立：游戏作为服务器运行，不接受远程客户端连接。参与游戏的玩家必须为本地玩家。此模式用于单人游戏和本地多人游戏。
   ② 客户端：游戏作为网络多人游戏会话中与服务器连接的客户端运行。
   ③ 聆听服务器：游戏作为主持网络多人游戏会话的服务器运行。其接受远程客户端中的连接，且直接在服务器上拥有本地玩家。此模式通常用于临时合作和竞技多人游戏。
   ④ 专属服务器：游戏作为主持网络多人游戏会话的服务器运行。其接受远程客户端中的连接，但无本地玩家，因此为了高效运行，其将废弃图形、音效、输入和其他面向玩家的功能。此模式常用于需要更固定、安全和大型多人功能的游戏。
2. 聆听服务器Listen Server

• 聆听服务器是一种玩家担任服务器角色的网络架构模式。在这种模式下，玩家既作为“服务器”来管理游戏状态，也作为“客户端”来参与游戏。通常适合于小型多人游戏，比如局域网LAN游戏或好友之间的私人对战。
• 特点：
  ① 聆听服务器上玩家的视角和行为会实时传输给其他客户端玩家，方便快速同步
  ② 如果担任服务器的玩家断开连接，整个游戏会终止，其他玩家也会被踢出游戏。
• 比如steam好友邀请远程同乐

3. 专属服务器Dedicated Server

• 专属服务器是独立运行的专用主机，不参与游戏，只负责管理所有玩家的连接、游戏状态以及物理同步等。它通常运行在云端或服务器托管平台上，适合大规模多人在线游戏（如MMORPG）。

• 特点：
  ① 专属服务器更稳定，玩家断开连接不会影响其他玩家。
  ② 独立服务器提供更高的性能和同步效率，适合大型多人游戏。

2.2 Actor复制

1. 复制是指在网络会话中的不同机器间复制游戏状态信息。若正确设置复制，将可同步不同机器的游戏实例。多数Actor默认不会启用复制，且将本地执行所有功能。在C++ Actor类中设置bReplicates变量，或将Actor蓝图的复制Replicates设置设为true，可启用给定类的Actor复制。

UPROPERTY(Replicated)
int32 Health;

2. 创建网络游戏时的常见复制功能：
   ① 创建和销毁
   ② 移动复制
   ③ 变量复制
   ④ 组件复制
   ⑤ 远程过程调用RPC
3. RPC是传输到网络游戏中特定机器的特殊函数。无论初始调用RPC的是哪台机器，其的实现仅在目标机器上运行。此类RPC可指定为服务器（仅在服务器上运行）、客户端（仅在Actor的拥有客户端上运行）或NetMulticast（在连接会话的所有机器上运行，包括服务器）。

举个例子：

UFUNCTION(Server, Reliable)
void Server_FireBullet();

• 当玩家在客户端按下射击按钮时，调用这个函数。由于这是一个Server RPC，客户端会请求服务器来执行这个函数。
• 在Server_FireBullet函数中，服务器可以生成一个子弹Actor，并设置bReplicates = true，使其在所有客户端中可见。

4. Actor、Pawn和角色的部分常用功能不会复制：
   ① 骨架网格体和静态网格体组件
   ② 材质
   ③ 动画蓝图
   ④ 粒子系统
   ⑤ 音效发射器
   ⑥ 物理对象

• 此类项目均在所有客户端上单独运行。但是，若复制驱动此类视觉元素的变量，则可确保所有客户端都具有相同信息，从而以大致相同的方式进行模拟。

注意： 必须根据游戏的需求明确指定要复制的变量和函数。

5. 基于条件的Actor复制：

• 有些Actor可能只需要在某些条件下才进行复制。例如，只有玩家在一定范围内时才进行同步，以减少网络带宽消耗。可以在Actor类中重写IsNetRelevantFor函数来控制Actor的复制条件。

6. 复制Actor的动态属性:

• 在某些情况下，Actor的状态需要在运行时更新，并且立即同步给所有玩家。这可以通过OnRep回调函数来实现，当某个属性发生变化时会触发这个回调。

举个例子：

UPROPERTY(ReplicatedUsing=OnRep_Shield)
int32 Shield;
UFUNCTION()
void OnRep_Shield();

• 假设游戏中角色的护盾值会在受到攻击时减少。可以设置OnRep_Shield来确保每次护盾值变化时，客户端都能执行自定义的逻辑，比如播放护盾破碎效果。
• 这样可以确保护盾值的变化会立即同步到所有客户端，并触发每个客户端的OnRep_Shield，以播放相应的动画或特效。

2.3 网络角色和授权

1. Actor的网络角色将决定网络游戏期间控制Actor的机器。授权Actor被认为可控制Actor的状态，并可将信息复制到网络多人游戏会话中的其他机器上。远程代理是该Actor在远程机器上的副本，其将接收授权Actor中的复制信息。其由Local Role和Remote Role变量进行追踪。
2. 网络角色Role：
   ① 无：Actor在网络游戏中无角色，不会复制。
   ② 权威Authority：具有完全控制权的机器，通常是服务器。服务器上的Actor通常会自动拥有“ROLE_Authority”角色。这意味着它可以决定Actor的行为和状态。
   ③ 模拟代理Simulated Proxy：Actor为远程代理，由另一台机器上的授权Actor完全控制。网络游戏中如拾取物、发射物或交互对象等多数Actor将在远程客户端上显示为模拟代理。

• 它们会根据服务器的状态来更新自己的状态。通常用于同步其他玩家的角色或其他非自主控制的物体。
  ④ 自主代理Autonomous Proxy：Actor为远程代理，能够本地执行部分功能，但会接收授权Actor中的矫正。自主代理通常为玩家直接控制的actor所保留，如pawn。

3. 虚幻引擎使用的默认模型是服务器授权，意味着服务器对游戏状态固定具有权限，而信息固定从服务器复制到客户端。服务器上的Actor应具有授权的本地角色，而其在远程客户端上的对应Actor应具有模拟或自主代理的本地角色。
4. 授权Ownership：

• 授权是指Actor的控制权分配，通常由服务器决定客户端能否操作某个Actor。以下是一些具体的授权方式和用例：
  ① 服务器授权：最常见的方式，服务器拥有最终决定权。在服务器授权下，客户端需要通过RPC请求服务器执行特定的操作，例如在多人射击游戏中，客户端请求服务器射击，服务器判断合法性并通知所有客户端。
  ② 客户端授权：有时用于较低风险的操作（如UI操作），或在需要降低延迟的操作（如本地预测）。客户端可以在不等待服务器确认的情况下执行操作，但最终状态仍由服务器决定并同步回来。

举个例子：

1. 服务器生成和控制子弹：

• 当玩家按下射击键时，客户端发送RPC（Remote Procedure Call）给服务器，请求生成子弹。
• 服务器根据请求验证（是否符合规则，是否可以射击）后生成子弹Actor，并将其角色设置为“ROLE_Authority”。
• 服务器将该Actor的状态同步到所有客户端，这些客户端会将子弹Actor的角色设为“Simulated Proxy”，从而仅模拟子弹的运动而无控制权。

2. 客户端控制自己的角色：

• 客户端上的玩家角色（Pawn）通常是“Autonomous Proxy”，这样客户端可以本地处理输入（如移动、旋转）。
• 服务器上该角色会是“Authority”，因此会接收客户端的运动请求并验证后进行更新，将最终状态同步到其他客户端。

3. 延迟和预测：

• 客户端可能会在射击或快速移动时看到延迟（服务器确认需要时间）。为了提升体验，UE引入客户端预测（Client Prediction），允许客户端暂时“预测”其状态，服务器随后验证并同步回准确位置。

2.4 客户端拥有权

1. 客户端拥有权Ownership：在网络游戏中，每个玩家在自己的客户端上控制一个Pawn（玩家的角色对象），这个Pawn是被该玩家的PlayerController所拥有的。拥有权意味着，只有拥有这个Actor的客户端才能控制它，比如接收输入并作出反应。这种设计主要为了避免多个客户端都试图控制同一个角色导致的冲突。
2. 纯客户端函数Pure Client-only Functions ： 是一类只在客户端上调用的函数，而不会被同步到服务器。例如，某些视觉效果或客户端专属的界面更新操作，这些不需要服务器参与。

举个例子：

• 假设一个游戏角色在受伤时播放一个特效，这个特效是纯客户端的。那么，只有拥有该角色的客户端才能触发这个效果。使用IsLocallyControlled判断当前角色是否在自己所拥有的客户端上，确保只有正确的客户端会播放这个特效。

3. Owner属性：UE中的Owner属性帮助我们将一个 Actor与另一个Actor（例如Pawn）关联起来，这样关联后，客户端可以确认该Actor属于谁。

举个例子：

• 如果将一个武器Actor的Owner设为某个Pawn，UE 就会把这个武器的操作权限分配给该Pawn的拥有者客户端。当玩家在客户端点击攻击时，客户端会判断这个武器是否被“本地控制”（即是否为玩家拥有的角色），然后在客户端上直接执行相应操作（比如显示武器开火的效果）。

4. IsLocallyControlled函数：是一个用于检查Actor是否在拥有该Actor的客户端上被控制的函数。这个函数可以帮助我们判断某个操作是否应仅在拥有权客户端上执行，避免让服务器或其他客户端误操作。

在拥有角色的客户端上，IsLocallyControlled()会返回 true，因此会播放视觉效果。在非拥有客户端上（即其他客户端的模拟代理），IsLocallyControlled()返回false，不会播放视觉效果。

2.5 相关性和优先级

1. 相关性用于决定是否需要在多人游戏期间复制Actor。复制期间将剔除被认为不相关的actor。此操作可节约带宽，以便相关Actor可更加高效地复制。若Actor未被玩家拥有，且不在玩家附近，将其被视为不相关，而不会进行复制。不相关Actor会存在于服务器上，且会影响授权游戏状态，但在玩家靠近前不会向客户端发送信息。覆盖IsNetRelevantFor函数以手动控制相关性，并可使用NetCullDistanceSquared属性决定成为相关Actor所需距离。
2. 有时在游戏单帧内，没有足够带宽供复制所有相关Actor。因此，Actor拥有优先级Priority 值，用于决定优先复制的Actor。

• Pawn和PlayerController的 NetPriority默认为3.0，从而使其成为游戏中最高优先级的Actor，而基础Actor的NetPriority为1.0。
• Actor在被复制前经历的时间越久（等待同步的时间越长），每次成功通过时所处的优先级便越高，以确保它不会长时间没有被同步更新。

三、变量复制

1. 在C++中使用对应UPROPERTY宏内的Replicated或 ReplicateUsing说明符，或在蓝图的细节面板中将它们指定为已复制，可将复制添加到变量和对象引用。授权Actor上复制变量的值变更时，其信息将自动从授权Actor发送到连接会话的远程代理。
2. RepNotify：是一种通知机制，可指定在Actor成功接收特定变量的复制信息时要调用RepNotify函数。

• RepNotify仅在变量更新时本地触发。触发gameplay逻辑响应授权Actor上的变量更改时，UE会自动调用指定的回调函数。这种机制不需要额外的网络调用，可减少开销。
• 在C++中使用变量的UPROPERTY宏的ReplicatedUsing说明符可访问此功能，或修改蓝图中变量的复制设置以使用RepNotify。
• 由于RepNotify可添加到需复制的变量中，而无需考虑其他gameplay功能，创建额外网络调用时刻节约大量带宽，因此RepNotify比RPC或复制函数更加好用。

举个例子：

UPROPERTY(ReplicatedUsing = OnRep_Health)
float Health;// 当Health变量更新时，自动调用该函数
UFUNCTION()
void OnRep_Health();

在上面的代码中，当Health从服务器同步到客户端并发生变化时，OnRep_Health()函数会被自动调用

3. 与RPC相比，RepNotify的优势：
   ① 节省带宽：RPC是在服务器和客户端之间手动调用的网络函数，频繁的 RPC 调用会增加带宽消耗。而 RepNotify仅在变量更新时触发，避免了不必要的网络通信。
   ② 简化逻辑：使用RepNotify后，变量更新和回调触发变得更加自动化，不需要开发者手动发送消息或调用函数，只需专注于编写回调逻辑。

四、远程过程调用(RPC)

1. 远程过程调用也称为复制函数。是一种用于在网络游戏中实现客户端和服务器之间通信的机制。RPC 允许我们从客户端调用服务器函数，或从服务器调用客户端函数，实现特定的游戏逻辑。
2. RPC的类型：
   ①Server：仅在主持游戏的服务器上调用。（客户端请求）
   ②Client：仅在拥有该函数所属Actor的客户端上调用。用于服务器向特定客户端发送消息。常用于同步特定客户端的视觉效果或更新特定客户端的数据。
   ③NetMulticast：在与服务器连接的所有客户端及服务器本身上调用（广播消息）。
3. 使用场景：
   ① Server RPC（客户端调用 -> 服务器执行），例如：玩家在客户端上点击攻击按钮并希望服务器处理攻击逻辑

UFUNCTION(Server, Reliable, WithValidation)
void Server_Attack();

② Client RPC（服务器调用 -> 特定客户端执行），例如：更新特定客户端的UI，比如显示得分或弹出特定的提示；播放客户端独有的视觉效果，比如显示伤害数字或特殊的效果。

UFUNCTION(Client, Reliable)
void Client_DisplayDamage(float Damage);

③ Multicast RPC（服务器调用 -> 所有客户端执行）,在多人游戏中，如果某个事件需要所有玩家都能看到。例如：全局事件广播，比如场景爆炸、所有玩家的状态更新；生成可见的效果或动画，比如大范围特效。

UFUNCTION(NetMulticast, Reliable)
void Multicast_ExplosionEffect();

4. 提供对应UFUNCTION宏中的Server、Client或 NetMulticast说明符，可在将C++函数指定为RPC。其代码将在代码实现中使用后缀 _Implementation。
5. 必须将RPC指定为可靠或不可靠。在蓝图中，函数和事件默认为不可靠。在C++中，必须将Reliable或 Unreliable说明符作为Server、Client或NetMulticast 函数，添加到RPC的UFUNCTION宏及其状态。

• 不可靠RPC 无法保证必会到达预定目的地，但其发送速度和频率高于可靠的RPC。其最适用于对gameplay而言不重要或经常调用的函数。例如，由于Actor移动每帧都可能变换，因此使用不可靠RPC复制该Actor移动。
• 可靠的RPC 保证到达预定目的地，并在成功接收之前一直保留在队列中。其最适合用于对gameplay很关键或者不经常调用的函数。相关例子包括碰撞事件、武器发射的开始或结束，或生成Actor。

6. 为了确保数据安全性和有效性，特别是防止作弊，Server RPC通常会设置“验证”机制，称为 WithValidation。服务器 RPC 的函数可以包含一个 _Validate()方法来检查请求是否合法，只有通过验证的请求才会被执行。
   WithValidation说明符表明除函数的实现外，还有可验证传入函数调用的数据的函数。此验证函数与其负责的函数使用同一签名，但其将返回布尔而非原本返回值。若返回true，则其允许执行RPC的Implementation；若返回false，则防止执行。

• 举个例子：在这里，当客户端调用Server_Attack() 时，服务器会先执行Server_Attack_Validate()。如果返回 true，才会继续执行Server_Attack_Implementation()中的具体逻辑。

UFUNCTION(Server, Reliable, WithValidation)
void Server_Attack();bool Server_Attack_Validate()
{// 在这里检查客户端请求是否合法，比如检测攻击范围return true;  // 合法则返回 true
}void Server_Attack_Implementation()
{// 合法后执行攻击逻辑
}