I. Replication

Replication指的是 从服务端向客户端 传递数据和信息的行为。注意是单向的，不会从客户端传递信息和数据到服务端。

假设一个Actor被设置为Replicates， 当且仅当它被服务端生成 ，那么它会被所有客户端生成，并被Replicated。言外之意，即使是Replicates的Actor，如果在某个客户端生成，它也只会在本客户端生成，是 不会在其他客户端或者服务端生成 的，自然也谈不上Replication。

还有一种情况容易让人糊涂：假设在Pawn类中的Authority端生成一个Actor，并且把它存为变量，那么这个变量的Replicates属性和这个Actor本身的Replicates属性是什么关系？实际上，这里变量只是指向这个Actor的一个引用/指针，掌握住这点就好理解了。如果这个Actor没有Replicates，而让这个指针Replicates，那么它在客户端上就会指向一个NULL，这个并不会让引擎崩溃，但是没有任何意义。如果Actor Replicates，但是指针不是Replicated，那么在客户端这个Actor是存在的，但是指针没办法指向正确的对象。所以这种情况下需要Actor和变量都是Replicates(ed)才能达到正确的效果

另外，GameMode是不会Replicates的，它只存在于服务端，所以对它存储的变量设置Replicated没有任何意义。

那么再考虑一下，如果这个Actor在编辑阶段就被置于场景中呢，它在多人联网的情形下是什么状况？

我做了以下几个实验来逐步分析：

（以下实验如无特殊说明，均采用默认的第三人称场景，Play选项Number of Players选择2，New Editor Window(PIE)）

实验1：Actor不勾选Replicates，直接放置于场景中，初始一个随机速度运动

结果：客户端和服务端都各自以各自的速度运动，证明这两个物体在不同的instance上是独立的，互无关联的。

实验2：Actor勾选Replicates，但不勾选Replicate Movement，直接放置于场景中，初始一个随机速度运动

结果：和实验1一样。那么大家可能就会怀疑，这种情况下是不是和实验1是完全一样的？实际上和实验1有很大的区别，这个Actor有了Replication，也就可以进行属性的Replicates和RPC调用，而实验1里的Actor就不可能进行这些操作。

实验3：Actor勾选Replicates，勾选Replicate Movement，直接放置于场景中，初始一个随机速度运动

结果：虽然初始化了不同的速度（print出来了），但是服务端和客户端运动基本上是同步的，只是客户端的运动会有些许“抖动”。出现这种情况的原因是客户端“想”以自己的速度去运动，但是由于更新了Replicate Movement，服务端会以固定的频率去把自身的位置同步给客户端，因此客户端会在更新的瞬间跳跃到服务器指定的位置，从而产生了抖动。

放置于场景中的Actor的情况我们搞清楚了，再来考虑一下更麻烦的——动态生成：

实验4：我们先在LevelBlueprint的BeginPlay中直接生成Actor，这个Actor是实验2的，也就是Actor勾选了Replicate，但并不同步移动。

结果：服务端有一个Actor，客户端有2个Actor，并且3个Actor均以不同的速度在运动。不难理解，因为在LevelBP中生成，所以服务端生成了一个，但是这个Actor是Replicates的，所以被复制到客户端，同时客户端本身的LevelBP中也生成了一个，所以客户端有两个。

所以如果要在LevelBlueprint中生成Replicates的Actor，一定要在前面加上Switch has authority，并在Authority后面生成。

上述几个实验的工程源码存放在这里

II. Ownership

所谓“Own”（拥有）的主语其实是一个“连接”的实例或者PlayerController。

每个“连接”的实例肯定会Own（拥有）一个PlayerController

那么决定一个Actor是否被拥有，就是向上查找他的Ownership结构树，找到最上层的拥有者，如果是个PlayerController，它就被这个PlayerController以及它的“连接”所拥有。

最典型的的例子，一个Pawn被PlayerController Possess的时候它就被Owned。如果它被Unposses了，Ownership也就丢失了。

那么一个普通的Actor能不能被“拥有”呢？答案是可以的，使用Set Owner方法就可以让他被某个PlayerController拥有。

为什么要强调Ownership呢？

• 后面我们将描述这个问题：RPC需要决定在哪个客户端执行 Run on Client的 RPC
• Actor网络复制和连接的Rlevancy（相关性）
• 牵扯到Owner时候的property Replication条件

III. Actor Role 和 Remote Role

Actor Role在我的 这篇文章里已经很详细的描述过了，这里做一下补充：

Actor Role 和 Remote Role是一组相对的概念，Actor Role指的是在本地的角色，Remote Role指的是远程端的角色。这里的“远程端”有点tricky，容易误解，我也是糊涂了很久才明白。

设想有一个服务端加两个或两个以上的客户端，那么所谓的“远程端”到底指的是在哪个“端”？实际上我们只需要分两个“端”，一个服务端，一个客户端，把所有的客户端都看成一端，这个问题的答案就很显而易见了。

另外 官方文档专门说明了， “目前，仅服务端可以负责同步信息到客户端，因此仅服务端可以看到Role=Authority，并且RemoteRole=Simulated_Proxy或者Autonomous_Proxy”，这个“目前”说的是目前的网络构架。

总之，只有服务端才可能有Authority，所有Replicates的Actor在服务端的Role都是Authority，要牢记这点。（非Replciates的有没有Authority?有待验证）

实际上，Simulated_Proxy和Autonomous_Proxy讲的是两种同步模式（Mode of Replication），因为服务器不可能每一帧都去把信息同步给所有客户端，而是以一定的频率去下发信息，那么两次下发之间的空白怎么填补呢？虚幻设计了两种同步的模式：

Simulated_Proxy是标准模式，用最后的速度和位置去移动物体.（使用最后的速度只是一种算法，你也可以实施自己的算法）

Autonomous_Proxy基本上只会用于被PlayerController 所Possess的对象（那就是被Possess的Pawn啦），那么在空白期间就直接用用户的操作来填补。

看到这里，我们需要明确两点：

• Autonomous_Proxy就是Pawn(当然说的是被Possess的）在本客户端的Role——目前我能想到仅有这一种情况。它的RemoteRole——也就是在服务端的Role是Authority，它在其他客户端的Role是Simulated_Proxy。
• 而任何非Pawn的Actor，在服务端的Role都是Authority，他们的RemoteRole都是SimulatedProxy。

在C++中可以使用Role==XXX来判断一个Pawn的Role，但是在蓝图中我们可能需要分两步来进行：首先判断是否has authority，如果是，则是服务端，如果否，还要继续判断pawn是否isLocallyControlled，如果是，则是Autonomous_Proxy，如果否则是Simulated_Proxy。

IV. Actor Role和Ownership的关系

很重要的一点， Actor Role 和 Ownership没有任何关系 ，是不同的概念。

只是很巧合，Autonomous_Proxy肯定会被Own，但不能说被Own了就一定是Autonomous_Proxy，例如我们可以对一个非Pawn的Actor 设置所有者（Set Owner），但是它的Actor Role没有改变。

V. RPC

• RPC本质是用来调用在 另外一个游戏实例上的函数的 。
• RPC无法获取返回值 ，这就是为为什么没办法把蓝图中的Function设置为RPC的原因，因为Function是可以带返回值的。而CustomEvent是没法设置返回值的，所以RPC只能标记在CustomEvent上。
• RPC分三种，Run on Server，Run on owning Client，NetMulticast
• RPC必须在Actor或者其子类上调用
• Actor必须是Replicated的（否则不存在RPC一说）

1. Run on Server

　　表示在Actor的服务端实例上执行。

　　如果RPC是从客户端调用，让其在服务端执行，客户端必须 Own（拥有） 这个Actor。

2. Run on owning Client

表示在Actor的Owner上执行。

如果RPC是从服务端调用，让其在客户端执行，只有 Own（拥有） 这个Actor的客户端才会执行。

注意Run on Server和 Run on owning Client的条件：客户端必须Own这个Actor，也就是 这个Actor必须有Ownership 。

3. NetMulticast

表示在Actor的所有实例上执行。

如前所述，前两种RPC模式都要求Actor必须有Ownership。 Multicast是个例外，它不需要OwnerShip 。

如果从服务端调用，服务端会本地执行，所有目前连接的客户端也都会执行。

如果从客户端端执行，则只会本地执行，服务端不会执行，其他客户端也不会执行。