用HBuilder做网站的模板网站首页不收录

---

一、常规学习：

Mirror是一个用于Unity多人游戏的功能系统。它允许在其中一个参与者同时承担服务器的功能，因此不需要专用的服务器进程从而减少了开发人员的工作量。

Mirror核心功能有

1.消息处理程序
2.通用高性能序列化
3.分布式对像管理
4.状态同步
5.服务器与客户端的各种链接等.

服务器和主机

1.服务器是游戏的一个实例，所有客户端与其链接。由服务器对数据进行处理并回传给各客户端展示。
2.服务器可以是“专用服务器”也可以是“主机服务器”。
“专用服务器”仅作为服务器支行游戏实例。
“主机服务器 “当没有专用服务器时，即充当服务器也充当客户端。
下图代表了三个玩家。在游戏充当了主机也就是本地客户端，并且两者在同一客户端支行。另外两个是远程客户端。

因为主机与本地服务器在同一进程中，因而可以使用“特殊”的通讯方便直接调用方法和消息。
远端客户端则通过常规的网络通讯与服务器交互，Mirror会自动处理这些工作。

多人游戏系统目标之一是使服务端、客户端代码相同。因而多数时候你只需要考虑一种类型的客户端,Mirror将会自动处理差异。

二、时间戳批处理

你发送的每条消息将被批处理直至当前帧结束，以最大程度的减少传输的消耗。消息中将会把大量的小消息合并为一条进行发送。
客户端和服务端都会进行批处理以最大化的减少性能消耗。

时间戳

确保远程发送消息的时序性，接收到消息后对他们之间进行插值。可以准确的知道物在服务器上，何时处于何处。
早期版本通过NetworkTransform来实现，成本巨大因为需要包含一个4字节(float)，甚至8字节(double),当在大型游戏中时，宽带压力会迅速增加。
而NetworkTransform只是其中一种组件，其他的组件也可能需要时间戳，这将进一步增加宽带消耗。
为了减轻宽带压力，Mirror每个批次都包含8个字节，但并不是每条消息都包含，而是每1200个字节批出来一次，这有效减轻了宽带压力。

在客户机上，所有对象数据都以消息/批处理的形式从服务器到达。因此，在任何给定的时间，您都可以发现对象的Rpc/OnDeserialize/OnMessage处理程序何时由服务器通过NetworkClient.connection.remoteTimeStamp发送。

在服务器上，只有玩家拥有的对像才能于家连接中获得消息。因此，在任何时间，您都可以找到对像的Cmd/OnDeserialize/OnMessage处理程序，由客户端能过connectionToClient.remoteTimeStam发送

三、TCP和UDP

TPC由1970年开发，UDP由1980年引入，TCP内靠性，时序性，但延迟较高，UDP反之。

四、CCU(同时在线人数)

Mirror 可以处理多少个CCU,通常来说每个地图可以处理200CCU，但理论上是可以达到1000个。
官方尝试了一些项目480CCU时已有些卡顿，同时3D比2D的开销会更大。

五、SyncDirection(同步方向)

Mirror新增了SyncDirection功能

Mirror 中通常从服务器同步到客户端，但某些组件（如：NetworkTransform）需要在客户权限的情况下同步到服务器，因为OnSerialize只会从服务器到客户端，这里有几个缺点：
1.同时进行OnSerialize和手动远程调用需要大量的额外代码
2.会有额外宽带消耗，因每个命令包含一个函数哈希
3.间隔需要手动实现，因为syncInterval仅适用于OnSerialize.
因此OnSerialize提供了从客户端同步到服务器，组件提供了SyncDirection功能。

六、RTT（往返时间）

往返时间是指消息到另一端并返回的时间，由以下两个因素决定：
1.延迟：网络通过互联网传播需要时间
2.更新间隔：消息需要被处理并发送回另一端，与服务器处理时间及压力有关。
用户可以在NetworkTime.rtt查看，服务器可以在每个不同链接的NetworkServer.connection.rtt查看
如果你想在游戏中显示rtt可以使用NetworkPingDisplay

七、Connection Quality（连接质量）

Mirror的连接由三部分组成:
ConnectionQuality.cs提供了以下连接质量级别：
Public enum ConnectionQuality : byte
{
EXCELLENT, //高水平理想体验
GOOD， //非常适合所有人，高水平连接
FAIR, //非常明显卡顿，让人不愉悦
POOR, //无效的玩家
ESTIMATING, //仍在评估
}
两种发起方式：
Simple(based on Ping & Jitter)
Pragmatic( 基于快照插值)
NetworkPingDisplay
此组件可以添加到NetworkManager中，以在屏幕右下角显示ping和连接质量指示

NetworkManager回调
以覆盖CalculateConnectionQuality方式注入。可以在NetworkManager中配置。
OnConnectionQualityChanged可用于向用户显示警告，默认情况 下会发出一条日志。

八、Lag Compensation（滞后补偿）

快节奏的第一人称射击需要延迟补偿，又叫回滚。而对于MMORPG、纸牌、回合、等策略则不需要。
为什么需要回滚，假设在设计游戏中你和另一名玩家同步需要50毫秒，到达服务器需要50毫秒。这里就有100毫秒的时间差。这100毫秒里可能对方发生了位移，可能使你的设计位置不准确。

滞后补偿分为两部分：

一、独立算法类LagCompensation.cs

该算法可以记录采样类型任何记录。
换句话说，如果你愿意，您可以根据自己的需要定制它，这是底层代码，使用高级组件会更方便。

二、Log Compensator组件

只需要添加下面组件，Mirror将会管理指定Collider的历史快照。
当你做为玩家在本地发射子弹时，[Command]将输入发送到服务器，这进我们不检查另一端玩家是否补击中，
而是检查另一端玩家当时的Lag Compensation(滞后补偿)
官方文档中提供了例子。

九、Client Side Prediction（客户端预测）

打开Examples/Billiards例子，选择NetworkManager -> LatencySimulation 增加一些延迟(50ms),构建选择Server Only.

这是一个桌球游戏，在你击打白球时，由于数据需要发送给服务器再回传我们能明显的感觉到打击感滞后。
因此我们需要要用客户端模拟预测结果，一旦服务端返回状态我们必须立马纠正它。
由于大多数物理引擎，如Unity的PhysX是不确定的。这以为着在客户端和服务端施加的力(浮点数)会有所不同，而差异会逐渐累计。

为什么不使用确定性物理引擎：
一、Unity没有
二、工作量大
三、比常规物理引擎慢

最简单回滚流程说明：
由客户端执行Rigidbody.AddForce() 同时发送给服务器端执行[Command]CmdApplyForce(force)
服务器执行wellRigidbody.AddForce(force)
服务器同步新的刚体位置到客户端，但些修正将有一定时间差，而客户端一直在进行修改。
这也以为着客户端将一直有明显的“后跳”行为。
应当如何解决因时间差带来的后跳问题呢？
由客户端执行Rigidbody.AddForce() 客户端保存刚体位置 每50ms保存一次，以便后面进去比较

发送给服务器端执行[Command]CmdApplyForce(force)
拿到服务端的位置后与100ms(50+50来回)前的位置进行对比矫正
这部分内容可以了解一下而已，事实上Mirror已经为我们处理完这部分内容
在客户端中使用：Predicted Rigidbody（预测刚体）插件，情况将会简单很多。
预测和修正总是很难应用在刚体上。为了固话效果组件提供了两种模式：

Smooth(平滑):一般开始移动，所有的物理组件(Rigidbody+Colliders)都会移动到一个不可见的Ghost对象里。
渲染器在原位置并平滑插值到Ghost对像的位置，这将提供非常平滑的结果，但创造和跟随会有更大的额外成本开销。
Fast(快速)：物体保留在原来的位置上，渲染器直接移动到结果所在位置，这种方式更节约性能。

关于预测的类型可以在forecast .cs中找到它。
Mirror还可以用于其他类型的预测，但还需要了解后自行补全部分逻辑。

关于Mirror对于大型场景的预测
传统上预测算法并回滚模拟整个场景我们需要Physics.Simulate()
此方法可以最正确的模拟出结果，但性能消耗巨大，不适合用于大型场景。
Mirror经过努力兼容了大型场景的物理同及堆叠物理的同步。

十、History Bounds（历史边界）

优化延迟补偿和客户端预测，为了最小化性能开销，在我们使用的对像先对其强制使用HistoryBounds
使用方式：
将HistoryCollider添加到NetworkIdentity上
确保NetworkIdentity中有碰撞器，并拖至actualCollider中
按下播放键，启动Gizmos,注意橙色的HistoryCollider.
组件以橙色包围盒显示，这以为着您可以使用物理摄像进行物理检测。

当玩家开枪时，对所有的HistoryColliders进行射线检测，反出我们需要检测的玩家。
然后对碰撞器的父级NetworkIdentity使用延迟补偿处理，然后再检查他是否补击中。