大连六兄弟网站建设,wordpress oss 内网,重庆网站排名优化公司,wordpress路由插件开发文章目录 一、常规学习#xff1a;Mirror核心功能有服务器和主机 二、时间戳批处理时间戳 三、TCP和UDP四、CCU(同时在线人数)五、SyncDirection(同步方向)六、RTT#xff08;往返时间#xff09;七、Connection Quality#xff08;连接质量#xff09;八、Lag Compensati… 文章目录 一、常规学习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(5050来回)前的位置进行对比矫正 这部分内容可以了解一下而已事实上Mirror已经为我们处理完这部分内容 在客户端中使用Predicted Rigidbody预测刚体插件情况将会简单很多。 预测和修正总是很难应用在刚体上。为了固话效果组件提供了两种模式 Smooth(平滑):一般开始移动所有的物理组件(RigidbodyColliders)都会移动到一个不可见的Ghost对象里。 渲染器在原位置并平滑插值到Ghost对像的位置这将提供非常平滑的结果但创造和跟随会有更大的额外成本开销。 Fast(快速)物体保留在原来的位置上渲染器直接移动到结果所在位置这种方式更节约性能。
关于预测的类型可以在forecast .cs中找到它。 Mirror还可以用于其他类型的预测但还需要了解后自行补全部分逻辑。
关于Mirror对于大型场景的预测 传统上预测算法并回滚模拟整个场景我们需要Physics.Simulate() 此方法可以最正确的模拟出结果但性能消耗巨大不适合用于大型场景。 Mirror经过努力兼容了大型场景的物理同及堆叠物理的同步。
十、History Bounds历史边界
优化延迟补偿和客户端预测为了最小化性能开销在我们使用的对像先对其强制使用HistoryBounds 使用方式 将HistoryCollider添加到NetworkIdentity上 确保NetworkIdentity中有碰撞器并拖至actualCollider中 按下播放键启动Gizmos,注意橙色的HistoryCollider. 组件以橙色包围盒显示这以为着您可以使用物理摄像进行物理检测。
当玩家开枪时对所有的HistoryColliders进行射线检测反出我们需要检测的玩家。 然后对碰撞器的父级NetworkIdentity使用延迟补偿处理然后再检查他是否补击中。
