U3d同步

这是我在《游戏架构-核心技术与面试精粹》看的，记录一下~

目前游戏大体分为两个类别。

1.MO（Multiplayer Online）
少量玩家一起的竞技游戏

2.MMO（Massively Multiplayer Online）
期望大量玩家进行长期的社交性游戏

MMO里面的小副本也可以以MO的方式实现，技术并没有冲突

通信方式有什么？
1.C/S架构
客户端与服务器连接的消息传递方式
所有消息都是由服务器进行转发
优点：
1.服务器知道一切，可以控制非法行为
2.客户端只做表现，完全由服务器的数据驱动
缺点：
1.网络延迟较大 （200m以下）
2.昂贵的服务器成本
一般用在不需要，或者很少需要预表现的游戏中

2.P2P架构
两个客户端之间直接连接
基本和C/S优缺点相反

数据模式有什么？
1.全网状数据模式
每个客户端需要给网络中的每个设备广播自己的数据
每个设备上都有完整的数据，各个终端指数控制设备的输入信息
如果终端数据增加，信息量会急剧增长
一般只传递用户的输入信息，需要保证每个客户端的初始数据与每次操作的运算结果必须完全相同，否则就会表现不一致

2.星型数据模式
不平等模式，所有终端都要依从中央终端的数据（中央服务器）
服务器在收集完所有设备发送的数据之前 一直处于等待状态，接收完成后再广播出去
避免了终端过多导致数据暴涨
但是会导致数据传输速度下降，有利有弊

同步方式
1.状态同步
将玩家的状态行为同步（怪物的AI控制，角色技能释放，战斗伤害计算等）
由服务器运算，下发给客户的，客户端根据数据驱动显示
缺点：
响应速度存在问题，无法做到高频交互的顺畅体验
某个角色突然会出在某个位置，某个技能效果突然出现，甚至角色忽然死亡
（网络波动导致数据未及时送达，客户端进行了某些程度的预表现或者航位预测）

2.帧同步
客户端之前只同步用户的输入指令（向哪走，用什么技能）
消耗的流量只取决于指令数，会大大减少消息
特点：
需要保证计算结果的一致性（相同的时机，相同的内容，会得到相同的结果）
Untiy的不确定性：
a.各脚本之间的Start、Update生命周期函数调用顺序不确定
b.Physic物理系统也不保证是确定性模拟。
（某个单位坐标偏差了0.01导致技能未命中，血量判断就会受到影响）

常见的注意：
a.不使用浮点数，用整数代替
b.不同客户的同步频率要保证一直
c.随机种子相同，自定义接口防止其他公用系统干扰
d.使用排序容器，保证遍历顺序
e.逻辑显示分离
f.使用补间过渡，调整速率，掩盖卡顿

流畅度问题：
通过网络传输的数据一定会慢于本地，又希望相同时刻输入信息，因此就会引发等待，用户体验不流畅
解决办法：
a.广播消息最小化
b.将所有客户的同时发生的内容提前广播给其他用户，时钟同步
c.客户端逻辑先行，采用平滑追赶的方式
d.等等

使用UDP作为传输协议
TCP可以保证传输的可靠性，但是不适合做波动较大的移动网络
UDP虽然会丢包乱序，可以发冗余包解决这个问题（每帧三个数据包，包含过去两帧的数据）