挑战1:网络同步
挑战2:是网络的可靠性,包括应对网络的延迟,丢包和掉线
挑战3: 反作弊和安全系统,因为网络游戏的本质是经济系统
挑战4:多样性(不同设备,不同服务器),在不停服的情况下热更新
挑战5:大量人数时对高并发,高操作的要求
Network Protocols 网络协议
Socket编程,通过接口,确认好相互的协议,就可以快速的建立持续的链接
国内是IVP4 居多,最好兼容IPV6,这是世界标准
通过三次握手建立可靠的连接,确保发送的包是有顺序的,会进行流量控制,但网络阻塞时会自动降低发包的效率
基本原理:当任何一个接受者收到一个信息时,给sender发送一个ACK(告知),当sender收到ACK时,才持续的往后发包。如果sender未收到ACK,会持续发送同一个消息
阻塞控制:滑动窗口,可以动态的控制发送数据的大小,当发生阻塞,丢包或者超时时,按照一定算法减少滑动窗口
端对端的传输,更简单,不需要建立长时间的连接,不需要一定要保证稳定,不管有没有收到,不管顺序,不管流量控制。发送完就不管了
对于时间(延迟)不太敏感的操作类型的游戏,可以选择TCP,对于响应特别快速(FPS类),尤其在公网这种不稳定的网络下,用UDP反应较快
对于大型的MMO类型这种来说,不会用单一协议,会用组合协议,用TCP协议来进行签名认证,确认登陆,建立账号连接,心跳包等。当游戏进入到战斗,进入到这个世界里时改用UDP,在聊天,邮件等,又走回TCP通道。
TCP太慢了,需要稳定发送上一个消息,才能继续发下一个消息,并且效率随着带宽变化不稳定
UDP不可靠,无法确认消息到底有没有发送成功
实战中常常对协议进行深度的改造,定制适合的协议:基于UDP的可靠连接
1.需要可靠的连接(TCP)
2.保持一定的顺序(TCP)
3.需要非常快的反应,最好没有延迟 (UDP)
4.需要群发(UDP)
ACK:确认收到
NACK:什么包没收到
SEQ:序列号
ARQ:当我建立一个网络连接传包时,如果我丢包或者未收到,能够有办法能告诉对方
滑动窗口协议:当有很多数据要传输时,会一次性把窗口里的数据全部传输,当我收到接收方返回的ACK包时,如果我收到的2号包的ACK,便确定0,1,2都已传输到位,接下来传输3,4,5,6,因为3已经传了,只需传输4,5,6,直到收到剩下包的ACK,窗口便继续往下滑动
窗口设成1,每个包发送完后要等ACK收到,才往下走
如果发现窗口里的一个包丢失,只把窗口里的包再传输一遍。窗口持续往下走,会被告知NACK(哪个包丢失),把丢失的包重新发送。连接更稳定,能减少带宽的浪费,但是有额外ACK类型,即NACK
解决UDP丢包的问题
丢包率低一个值的时候不管,然后通过FEC的方式把丢掉的包在传输段的另一头计算回来,通过额外的数据量换取稳定性
增加一个E(异或运算校验位),丢包后的数据可以通过异或校验位还原
对D构建一个矩阵B(确保任意抽掉若干行,仍然是一个可逆的矩阵),
B矩阵 乘以 D 矩阵 得到了 G,包含了三个其他多算出来的
传输中出现丢包
B`相对于 B的去掉了丢包数据的行数
B` 的逆矩阵可以重新将数据还原
总结:构造一个矩阵,确保矩阵抽掉若干行仍然可逆。将拿到的信息乘上,抽掉了对应行矩阵的逆,就可以恢复原始信息
定制自己独立的UDP策略:对ARQ有所理解,使用滑动窗口的方法(一个pool)去传递数据,确定resending/retransimission的策略,加上一定FEC的算法,保证即使在一定的丢包率下,包体仍然能正确收到,确保ACK尽量的成功
Clock Synchronization 时钟同步
RTT和Ping非常接近,区别是Ping更底层,是不同的协议层
RTT 很多时候是应用层自己写的,游戏里很多时候不用区分的太严格,RTT用的多一点
在协议包里有四个时间
t0:客户端发送的时间
t1:服务器收到的时间
t2:服务器发送的时间
t3:客户端收到的时间
通过这个算法可以估算出RTT
案例:延迟delay是4秒,按延迟即服务器发送的时间t3,客户端接收到的时间应该是35秒,与客户端本地时间05秒相差30秒。则估算出客户端和服务器相差30秒
算法与现实不符合的假设是:
1.网络的速度是恒定的
2.上下两路是对等的
1.先跑一边NTP算法,算出服务器和客户端的时间差
2.快速调整客户端的时间,然后做多次NTP算法,算出一系列NTP算法
3.把大于offset平均值50%的值扔掉,然后按剩下的offset值取平均值做时钟校准
链路不可靠的情况下,只能逼近准确的服务器时间,无法真正的完全校准
RPC Remote Procedure Call 远程程序调用
socket 编程模式缓解了复杂计算机网络架构的困难,但是在游戏业务逻辑方面其还有一系列的问题
socket 编程会需要使用到Messages的方式来工作,定义很多的消息,消息里面会包含很多的参数
客户端和服务端很多时候系统 OS 不一样
1.常见的有Linux作为服务器收发处理数据,客户端是安卓, IOS,Windows
2.Big Ending 和 Small Ending, 高位在前还是低位在前
3.数据打包之后需要对齐(4个Byte为单位),否则就会有很多空间浪费
4.解密和加密
让程序员像正常写业务代码,作为一个库存在,然后传入参数。之后如何变成Message,如何打包,如何序列化,网络如何路由到服务器,服务器如何接受,处理消息,如何返回等等这些都交给RPC来完成
案例
免去后台的处理过程,专注业务逻辑
IDL Interface Definition Language 界面定义语言
IDL 会定义各种参数,类似schema的定义
RPC Stubs RPC 存根:
当一个客户端或服务器起来之后,彼此会告诉对方自己上线,然后注册一大堆的RPC(用来个函数调用)。
每次call RPC时可以在RPC的存根里查询,如果没有对应RPC,系统会报错,但不影响其他业务逻辑的运行。
真实RPC路径:发出RPC请求后,首先进行压缩,加密,然后网络传输,服务器接收后,进行解密,解压缩
Network Topology 网络拓扑
现在多人游戏用的比较少,很多时候是点对点时使用,主要是switch这种局域网上使用p2p连接
p2p一般不会考虑作弊,没有什么限制
相比P2P,会选择一个玩家作为一个主机然后传输,早期网吧很多局域网游戏是这种类型。
现在一些沙盒类游戏,还有steam上的很多游戏是这种方式
不需要开发商维护一个服务器,玩家自己可以作为服务器
专用服务器:用于更复杂的大型MMO,电竞对战
会在服务端维持一个一致的世界,所有的客户端获得相对公平且稳定的连接
当跨越大洋的时候,物理延迟就是也需要考虑的。尤其是对于全球发行的游戏
所以各个区域一般都设置Protol,然后protol通过专有网络会链接到服务器上,从而不会使用公网的转跳,大大降低延迟
网络游戏加速器也是基于这个原理
Game Synchronization Intro 游戏同步
单人运行,单人输入
操作和显示是有延迟的,所以需要同步两个世界
1.快照同步 2.帧同步 3.状态同步
Snapshot Synchronization:
客户端只负责把输入发给服务器
服务器进行整个游戏世界的模拟
把整个游戏世界的状态生成一个快照(每个物体的血量,位置,速度。。。)
将快照发送给客户端
客户端展示快照的数据信息,(渲染绘制)
保证了整个世界状态的一致性,客户端只是一个渲染绘制的表现。
服务器会希望快照的计算不要占用过多的带宽,帧率会较低,10-20左右,客户端为了更丝滑的效果,帧率会更高。
客户端会在两个服务器快照之间进行插值
快照的数据量较大,且往往两个快照间多数物体没有变化,因此快照一般传递的是变化量,减少传输数据的大小
优点:
1.代码非常的简洁干净
2.绝对一致,无法作弊
缺点:
1.客户端的算力被浪费掉
2.生成快照的数据量很大,所需的上传带宽非常大
Lockstep Synchronization
可以理解为军队行走,整齐划一,某种程度上的高度性
也可以理解为是有回合制的,是有顺序的,类比与下棋
所有的信息一致性的同步的传递给目标,目标一致的处理
最简单的思想
所有客户端的操作统一的发给服务器,服务器再同一的分发给客户端,客户端做一致的模拟。
服务器一般做信息的汇总,同步及转发的处理
第一步初始化游戏内的初始状态(王者荣耀的加载条),必须要做到完全的一致,因为同步的是操作,如果初始条件有一丝偏差,最终结果可能误差非常大。
还需要同步时钟
每一帧都接受所有的客户端输入,确认收到所有输入后统一的发给所有人,所有人然后同时开始模拟
优点:简洁明了
缺点:延迟非常明显,所有人的延迟等于延迟最高客户端的延迟
公网帧同步的优化:
引入了Bucket,每隔一个Bucket(例如100ms)的时间内, 未收到客户端的操作,则丢弃这个客户端的操作
网络差者获利,与网络优者获利。权衡一致性和实时性
帧同步需要整个游戏逻辑具有确定性(Deterministic)
一样的输入,经过各种复杂的迭代运算后,保持一致结果很难
浮点数
随机数
数据容器,计算的算法
数学库
物理的模拟
逻辑执行顺序
帧同步上述一定都要保证一致
浮点数存储要符合IEEE754的标准,可以严格意义上保证浮点数一致性
但是不同平台的实现是不一样的
很多数学运算中需要用到三角函数,根号等,需要用查表法:所有的数字必须要是锁死的,不能各自算各自的
使用Fixed-point number 定点数的方法来计算,使用固定长的数字来处理数学运算,从而保证高度的一致性
整个游戏保持一致确定性几乎是不可能的,要把最核心的业务逻辑确定一致性。比如角色的移动,位置,血量,一些游戏的状态。但是渲染这种不确定不会有太大影响
同步随机数种子,且随机算法必须一致
游戏的确定性是帧同步的基础,如果无法保证一致性,则帧同步不能成立
跟踪和调试
错误是会不断累积的,需要不停地把游戏的状态保存下来,使用checksum的方法。
checksum:把现在所有的变量存在一起,算出一个md5编码,存出去,把游戏里所有的函数的call和parameter编程一个hash值存在那。可能每5-10帧,存下快照,包括input也保存快照
滞后和延迟
把服务器传过来的帧cache几帧,当服务器出现延迟,本地逻辑帧依旧能从cache获取
例如网络视频播放,是分成很多块,每次下载好几块作为cachebuffer
逻辑帧和渲染帧分离:
服务器差不多10帧,期间插入很多渲染帧。
当网络出现延迟或者各种问题时,渲染帧,画面不会因此出现各种各样的抖动。
断线重连:
客户端不仅仅只接收input,每隔一定帧数会有特定key frame把当前所有游戏的状态做一个snapshot并存在本地的内存或磁盘,保证游戏即使崩溃,snapshot的快照还在。
每次重连,从上一次快照的帧数开始演算到当前的帧数。避免从头开始演算
如果发生了重连情况,那么可以放弃渲染帧,只跑逻辑帧,以更快速度的逻辑帧,一定能追上现在游戏的进度
服务器再一些特定的keyFrame保存一个快照
当有些玩家断线时间过长,服务器可以给个更新的快照,帮助客户端设置游戏的状态
另一个应用是观战模式
观战实际上与断线重连的底层技术一模一样。服务器把前面关键帧的信息发送给客户端,再把参与玩家的input发送给客户端。注意观战发送的数据是有主动延迟防止作弊
回放同理
帧同步防作弊
多人情况下:投票机制,每隔一段时间,让所有客户端把游戏里状态的checksum校验码发给服务器,然后进行对比,有不一样的直接踢掉
双人对战的情况下,服务器会有个checksum。有来校验。(通常大部分双人游戏,都是采用p2p,很少帧同步。除非是电竞属性很强的游戏)
帧同步的一个难点是:所有的信息和状态都在客户端上模拟,理论上可以还原出一些不该让玩家看见的信息,例如moba的全图和fps的透视
现代的游戏不会单纯的使用最简单的帧同步,会有很多复杂方法策略的帧同步来规避
优点:
1.带宽要求低,仅同步指令
2.解决确定性问题之后,开发效率很高
3.可以做一些对打击操作非常敏感,精确的游戏
4.方便做游戏录屏
缺点:
1.保持一致性很难
2.难以防止全图挂这种问题
3.如果没有服务器快照,断线较长时,追赶问题会比较严重文章来源:https://www.toymoban.com/news/detail-716601.html
State Synchronization
核心思想是不会同步整个宇宙。
每个玩家只会提交自己部分的信息和部分的状态,每个玩家自己模拟自己的世界。
服务器会模拟一个完整的全宇宙,只会把部分的信息,和当前玩家相关的信息发给对应客户端
放作弊的能力会好一点点
Server最大,一切指令以服务器优先级最高
Authorized:是这个玩家对于本身local的操作
Replicated:其他玩家看到的这个玩家的复制品,依赖于服务器传输的信息
玩家1与玩家2客户端看到的情况
玩家1:开火,发送服务器
服务器:玩家1开火,广播所有客户端
玩家2:收到通知,玩家1开火
服务器通知每个客户端重复玩家1炮弹的运动
服务器判定击中了一个单位,广播给所有客户端
状态同步核心思想:
每个人提出自己的动作,整个世界的核心业务逻辑由server完成。server产生的结果与client提出的动作都会被同步给所有客户端。
并不要求所有的客户端保持高度一致性,只需要服务器做出判断。
状态同步只同步对于客户端需要的信息,即一个感知范围内的信息(AOI算法)
有个问题是玩家A如果自己需要操作,如往前走,依旧需要等待服务器的确认,这就会造成非常大的延迟,导致操作不顺手。
1.客户端预测
2.服务器校验
根据客户端预测,提前移动,服务器校验没问题则保持不变
由于RTT和一个command frame的延迟,会导致客户端永远比服务器超前
守望先锋:估计一个RTT,约160ms,半个RTT 80ms,一个command frame 16ms(刷新率60帧每秒),则客户端永远往前预测16+80ms,等服务器消息回来后,进行对齐,对齐是个插值的过程,尽可能使移动变得平滑
client本地一个消息发出到从server回来接收可能长达上百毫秒,本地可能已经跑了好几帧,此时会把本地的每一次预测和每一个状态全部buffer到一个序列帧里。当server的每一个信息回来时,会和过去的信息进行检验。因为从server回来的信息是经过了半个RTT时间的传输,对于client接收的瞬间是过去的信息。
如果和server的校验信息不一致,则以server的信息反向校准
从client角度看,会有做了某件事,但被校准回退的情况发生client需要一个ring buffer,存储在过去几帧的数据,当发现校验问题时,ring buffer之后的数据全部无效,重新算一遍
online游戏很常见,对网速慢的玩家不利,因为对世界的更新不及时,操作反应不如网速快的玩家
丢包问题:
1.server会把用户的输入,用一个ring buffer存储起来,会存储好几帧的输入
2.如果在一定时间内,接收不到用户的输入,有时候会自动把过去的最后一次操作进行复制(如,跑动过程中断网,在其他客户端展示的是扔在一直跑)
3.不同游戏有不同的处理丢包策略
number of players反了
帧同步:适合注重打击感,对抗感,竞技类的游戏。对引擎的要求很高,需要引擎的核心逻辑业务确定性非常高
状态同步:适合网络本身比较复杂,不太稳定,并且游戏业务比较复杂。以及游戏的参与者非常多
现代主流引擎大部分能实现状态同步,实现帧同步通常需要自己的引擎团队专门定制。文章来源地址https://www.toymoban.com/news/detail-716601.html
到了这里,关于Games104现代游戏引擎笔记 网络游戏架构基础的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!