文章目录
- 一、常规学习:
- Mirror核心功能有
- 服务器和主机
- 二、时间戳批处理
- 时间戳
- 三、TCP和UDP
- 四、CCU(同时在线人数)
- 五、SyncDirection(同步方向)
- 六、RTT(往返时间)
- 七、Connection Quality(连接质量)
- 八、Lag Compensation(滞后补偿)
- 一、独立算法类LagCompensation.cs
- 二、Log Compensator组件
- 九、Client Side Prediction(客户端预测)
- 十、History Bounds(历史边界)
一、常规学习:
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使用延迟补偿处理,然后再检查他是否补击中。