请教一下，类似 LOL，王者荣耀， Diablo3 这样的网络游戏，如何同步多机实时的数据？

[yazoox]

比如：
一局游戏，
LOL 10 人
王者荣耀 10 人
暗黑 8 人 \

几个人的操作，显示，这些数据，都是要在 10 台机器 /客户端“同步“ 更新的！

类似这样的服务器&客户端架构，数据结构，数据同步，是如何设计实现的？有没有相关的文章详细讲解这个的？

p.s. 因为最近在看 Microsoft 的 Fluid 技术，用于多人协作的。但微软的这个，我个人理解，对于“实时”性要求不高，有点延时关系不大。只要数据准确，正确，不出错。

但是网络游戏不一样，对于实时性应该要求挺高的。好奇是如何设计和实现的。

[vus520]

都是走服务器中转，一般延迟能控制在 80~30ms 以内，你说的实时，怕是没见过 460 哦

[yunhui]

去搜帧同步

https://developers.weixin.qq.com/minigame/dev/guide/open-ability/lock-step.html

[Vegetable]

服务器有一个逻辑帧概念，也就是一个时间点的状态快照。客户端去和逻辑帧同步就行了，涉及到两个指标，一个是服务器本身有多少帧，一个是客户端同步的频率是多少 tickrate 。

[timethinker]

帧同步需要客户端计算结果严格一致，不然就会走偏，服务端在一局的游戏中只扮演数据转发的角色。

[chinvo]

帧同步 和 状态同步

[yeqizhang]

之前看主播解释攻速阈值时，说过帧这概念..

[ReferenceE]

建议可以去康康 SignalR ？好像也是微软的

[eason1874]

游戏有大厅服务器和专门的对战服，玩家匹配的时候就是客户端在确认用哪个对战服，然后客户端用 WebSocket 或者 UDP 直连对战服。

想知道客户端和服务端怎么交互数据，可以去腾讯云看一下游戏云解决方案，比如游戏联机对战引擎 SDK 文档的 API 介绍。

[wasd6267016]

帧同步、状态同步
一句话给你介绍：
帧同步，所有客户端根据服务器下发的逻辑帧（包含的信息是十台设备的操作输入），在客户端演算一遍，输入一致算法一致 所以每个人看到的结果一致，谁延迟高谁吃亏

状态同步：
服务器以一定的频率下发各个玩家角色的状态给各个客户端，客户端以服务器信息为绝对真理，努力往这个结果上靠

[Macv1994]

同问，我也一直想问这个问题

[Still4]

wow 是状态同步，客户端下发操作命令，服务器运算操作结果，产生的结果推送到同屏的客户端，如果所有人都在不停的动，服务器负载是人数的平方，70 级的时候屠城只要 7 个团在一个房间内就会宕机，大概 300 人

war3 是帧同步，客户端下发操作命令，服务器直接推送操作指令给同屏客户端，接收的客户端负责运算结果，要求所有客户端版本相同，不允许跨版本连接。录像文件可以很小，因为只需要记录操作行为，实际结果是录像+客户端共同完成的

[dbpe]

@Still4 有些游戏有延时补偿的..那是状态同步呢还是帧同步呢?

[polo3584]

自己写过一个简单帧同步的格斗游戏，简单来说，服务器用一个固定频率发送客户端数据，有两个流派，一个是服务器计算之后再发送显示的内容，另一种是服务器发送固定数据到客户端再运算显示。

[joesonw]

实时竞技都是帧同步, 每个客户端把当前帧(例如过去 1/60 秒)的动作, 用 UDP 发出去. 而且包得很小, 为了避免做排序重发. 一般都把当前帧和之前的 2(或多)帧放到一起发出去, 还得在一个 MTU 大小内, 避免被拆包.

[ETiV]

服务器同时跑一个同样的场景、地图的主要（验证）逻辑
然后把各个客户端传上来的数据依次 patch 当前状态
再把这一帧的状态下发下去

[HytonightYX]

第一次听到这两个概念感觉蛮有意思的，知乎上搜了下，这篇文章还不错
https://zhuanlan.zhihu.com/p/104932624

[luoqeng]

完全不是一个技术类别，没啥可类比的。

microsoft Fluid 类似于 CRDT 分布式框架，CRDT 主要无中心服务器，p2p 情况下可以最终一致结果。CRDT p2p 具体应用 聊天 文字协同编辑

游戏服务器是一台中心服务器，中心服务器决定客户端请求先后顺序，广播给其他客户端，没有一致性问题。

[gBurnX]

简单来说，王者荣耀这类游戏不是 p2p 游戏，而是严格的 客户端 - 服务器 模式（ C-S ）。
简单说一下流程：

1.玩家的客户端， 负责把玩家的操控指令，发到服务端。

2.服务端负责接收所有玩家客户端的操控指令，并负责计算，最后把计算结果反馈给所有的玩家客户端。

3.玩家客户端负责接受服务端的运算结果，并显示出来。

4.以上的过程，是会有延迟的。但有些技能是立即释放。立即释放技能的流程是：
第一阶段，玩家在客户端点击这类立即释放的技能按钮，客户端把释放指令发送到服务端，客户端同时立即显示技能释放画面。

第二阶段，服务端把技能释放后的结果，传回到客户端，客户端此时显示技能释放后的效果，比如有没有打中或对方英雄、中招的物体状态的变化（比如 HP 、行动速度等等）。

所以：
A.当客户端网络卡顿时，你会发现你无法操作角色，比如控制角色行走、拐弯、释放技能，此时会变得卡顿或无法操作。

B.当客户端网络卡顿时，你会发现技能释放后，虽然画面会显示技能释放动画，但被击中的对象，却没有及时反馈被击中后状态的改变，比如扣血、被控住，等等。

5.因为延迟的存在，并且很多技能是立即释放的。所以，如何把立即释放的技能进行阶段分解，减少玩家因延迟的卡顿感，这就是游戏设计者需要考虑的用户体验问题。

WOW 在这个问题上是花了大量心思的，当年网络延迟波动有可能高达一两秒，但游戏画面与操作却没有太大的卡顿。不像现在的 LOL 和王者荣耀，延迟大于 100ms 就会有明显感觉。这就是游戏体验在设计上的差距。

[gBurnX]

另外楼上有些小伙伴说了帧同步，实际上没有纯粹的帧同步游戏，不然只要有网络延迟，游戏的不同步率只会越来越大。

帧同步率的游戏，其实是帧同步 + 每隔一段时间（ 1s ）的全局状态同步。当年 war3 和 starcraft 的联机挂就是针对全局同步的漏洞来实现联机时资源修改的功能。

[Keyes]

@gBurnX 关键帧[捂脸哭]