我是靠谱客的博主 俊秀纸鹤,最近开发中收集的这篇文章主要介绍【游戏开发】多人游戏网络同步相关技术(基础原理篇),觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

常见网络同步模型

1.C/S 模型 (Client-Server) : 状态同步
2.对等网络模型(Peer-To-Peer): 帧同步

网络同步数据类型

将数据分为四个类型

  1. 非保障数据(可丢弃)
  2. 保障数据(需要确保到达顺序,如发起攻击次序)
  3. 最近的状态数据(如特定玩家生命值,旧的生命值可覆盖)
  4. 最快保障数据(最高优先级,如移动信息)

一、C/S 状态同步网络模型

在这里插入图片描述

1. ghost管理器

在这里插入图片描述

2. 移动管理器

在这里插入图片描述

3. 事件管理器

由游戏模拟层产生的事件队列
*可以看作是RPC(远程过程调用)的一种简单形式

4. 其他系统

与网络不相关的游戏逻辑,如本地画面表现或本地存档等

二、对等网络模型

对比两种游戏类型RTS和FPS

RTSFPS
相关节点数量多(50-400)少(20-30)
方案同步玩家命令同步单元

对等网络模型采用确定性锁步(deterministic lockstep)

  1. 同步玩家命令难点
    每一个实例独立执行玩家发出的命令,所有游戏实例之间需要保持同步
    a.不同客户端帧速率不同
    b.网络连接质量不同
    综上,引入方法:轮班计时器(保证传输一致)
    (1).基于网络情况动态调整渲染帧率
    (2).滞后过多 -> 强行退出
    (3).可在客户端直接保存命令,实现重播

  2. 同步
    保证每台计算机计算结果一致
    (1).随机
    伪随机数生成器
    a.种子一致
    b.调用次数一致
    c.调用顺序一致
    (2).防作弊
    a.行为作弊(修改当前角色信息,数据与其他客户端不一致)
    b.地图作弊(查看本应该隐藏的其他玩家信息)

网络拓扑(network topology)

网络拓扑决定了网络中计算机之间如何连接

一、C/S拓扑结构

在这里插入图片描述

  1. 使用一台权威服务器(Authoritative Server)
    客户端根据服务器的游戏状态更新自己的本地状态
  2. 产生延迟
    往返时间RTT(Round Trip Time)
    某一步游戏操作,最简化的数据传输 :客户端 -> 服务器 -> 客户端
    往返一次的时间称为往返时间RTT
  3. 服务器可被细分
    a.专用的(dedicated):多个不同进程负责多个状态
    b.监听(listen):可使用某个客户端作为计算游戏逻辑的服务器,若被指定为“逻辑服务器”的客户端断开连接,另一个客户端可被晋升为新的“逻辑服务器”,这一过程称为主机迁移(Host Migration)

二、对等网络拓扑结构

在这里插入图片描述

  1. 每个对等体共享所有动作(输入共享)
  2. 每个对等体都模拟这些动作的执行
  • 对等网络拓扑结构存在的两个问题
    a.如何验证对等体之间状态的一致性
    b.如何同步随机数发生器

对等网络的两种解决方案

  1. 集中服务器(rendzevous server)
    仅用于初始化通信,保证IP地址互相可访问
  2. 中央服务器
    处理对等体之间的整个数据包路由过程
    在这里插入图片描述
    两个对等体之间互不知道公网IP地址,可阻止一个对等体通过分布式拒绝服务攻击的方式来断开另一个对等体。

*分布式拒绝服务攻击(DDoS:Distributed Denial of Service)
大量合法请求占用大量网络资源,以达到使网络瘫痪的目的。

三、可靠性:TCP还是UDP

1.TCP和UDP的比较

TCPUDP
可靠性数据按顺序传递和处理需要自定义实现
流量控制如果数据包丢失,将自动降低传输速率需要自定义流量和拥塞控制
内存需求操作系统必须保存所有发送数据的副本,直到数据被确认自定义数据的保存和丢弃,内存管理在应用层
路由器优先级可能优于UDP数据包可能在TCP包之前被丢弃

2.TCP

优点:稳定可靠,所有数据按序送达
缺点

  1. 低优先级的数据丢失干扰高优先级数据接收
  2. 两个独立的可靠有序数据流相互干扰
  3. 过时游戏状态的重传
  4. 为管理连接和跟踪重传数据分配了很多资源

适合:回合制游戏,卡牌游戏,在线桌游等操作指令顺序稳定的游戏

3.UDP

缺点:数据不可靠,到达顺序不一定按照次序
方案实现一个基于UDP的可靠系统
适用:大部分对实时性要求较高的游戏
原理

  1. 发送端唯一标志每个数据包
  2. 接收端检查传入的数据包,针对每个包发送一个确认
  3. 发送端处理确认

其他
*1. 构建一个InFlightPacket容器,跟踪所有尚未被确认的数据包
*2. 传入序列号:
a. 一致:正常处理
b. < 期望:不处理,不确认
c. > 期望:正常处理
*3. 多个数据包合并发送一个确认

UDP扩展:对象复制可靠性

  1. 不需要重传每个丢失的数据,而是仅仅发送丢失数据的最新版本
  2. a.应用程序定期询问Replication Manager 是否有需要重传的数据
    b.找到相应的InflightPackage
    c.写入当前对象的最新状态数据
  3. 根据“正在传输”的数据包优化
    当包含最新数据的数据包正在传输,Replication Manager可监测传输状态,能避免发送多余状态
    数据包:
    a.已复制数据包Flag置为Dirty
    b.循环遍历Delivery Map中每个Packet
    c.找到对应的数据条目
    d.比较网络标识符与当前数据标识符
    e.判断是否重发

最后

以上就是俊秀纸鹤为你收集整理的【游戏开发】多人游戏网络同步相关技术(基础原理篇)的全部内容,希望文章能够帮你解决【游戏开发】多人游戏网络同步相关技术(基础原理篇)所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(86)

评论列表共有 0 条评论

立即
投稿
返回
顶部