本帖最后由 小篱 于 2015-12-22 16:08 编辑


　　但是目前国外网络环境下跑的还比较流畅，国内的网络环境要低延迟传送 HD画质的视频流还比较困难，视频都是比较费带宽的。但是帧锁定等保证每帧输入一致的算法，在当今的网络质量下传递一下玩家操作，还是没有任何问题的。

　　状态同步法

　　对于逻辑不需要精确到帧的游戏类型而言（RPG/ARPG，FPS，赛车），允许每个客户端屏幕上显示的内容不同，只要将他们统一到一个逻辑中即可，这部分见：“网络游戏同步法则”（最好给策划看看这篇，从玩法上规避）。如果是 RPG游戏，其实更多是使用障眼法从玩法和动画效果上减少 “一次性的”，“决定性”的事件即可：

　　RPG 游戏的移动很简单，只需要“谁在哪里朝着哪里移动”，客户端再做一些简单的平滑处理即可，不需要额外的“时间”参数。比如《魔兽世界》移动时，就是差不多每秒发送一次（坐标，朝向，速度），别的客户端收到以后就会矫正一下，如果矫正错误，比如 A本来往北走突然拐弯向东，这个数据包传到B上，B屏幕上的A可能在拐弯前往北跑了更远，致使拐弯向东时被树卡住，那么B就会看到A被树卡了两秒无法移动，然后突然瞬间移动到新的坐标，继续朝着东跑。

　　通常 RPG攻击分为“有锁定攻击”和“无锁定攻击”，有锁定攻击意思是，我朝你发射火球，不管你怎么跑，火球都会追踪并射击到你，比如你在我面前横着跑过，我向你发射火球，可以发现火球并不是直线飞行，而是曲线追踪着你就过去了，这叫有锁定攻击。无锁定攻击一般是范围攻击，先播放个动画（比如挥刀），然后将攻击请求提交服务器，服务器结果回来时，动画刚好播放完毕，然后大家一起减血。

　　而 FPS和 赛车类游戏的同步性要求比 RPG高很多，每秒发包量也会多很多（10-30个），多半采用位置预测及坐标差值的“导航推测算法（DR）”，具体实现见我的：“影子跟随算法”（DR算法的一个改进实现）。


　　这类算法由于位置判定更为精确，所以计算量大，很多没法服务端判断，而是客户端直接判断，比如 FPS射击是否打到别人，客户端先判断，除了狙击这种一枪毙命的射击外基本都是客户端判断的。由于计算更为复杂，每秒同步发包差不多到 30个以上，这样的模式下，每局游戏的人数也不可能很多，一般16人左右。而且很多才用 P2P的方式运行，具体 FPS游戏的实现，及 DR算法的代码编写，见 “影子跟随算法”这篇文章。

　　其实状态同步是一种乐观的同步方法，认为大家屏幕上的东西不同没关系，只要每次操作的结果相同即可，不需要象“帧间同步”那样保证每帧都一样，因此，对网速的要求也没有 “帧间同步”系列算法那么苛刻，一般100ms-200ms都是能够接受的（DiabloIII里面300ms的延迟照样打），偶尔网络抖一下，出现1秒的延迟，也能掩盖过去。然而比起 “帧间同步”，状态同步方式对玩法有不少要求，诸如 “一次性”，“决定性”的事件要少很多，而且代码编写会复杂一些，不果由于能容忍更坏的网络情况，以及容纳更多同时游戏的人数，在一些玩法确定的游戏中（RPG，FPS，赛车），被广泛使用。


　　而状态同步又分为“DR同步”和“非DR同步”，前者针对 FPS，赛车或者更激烈点的 ARPG，后者针对 RPG和普通 ARPG。他们对网速的要求和错误的容忍度也是不一样，当然，带来的游戏即时感也是不同的。

　　总得来说，你希望游戏体验更爽快，即时感更强，那么你每秒发包数就越多，每局（副本）支持的人数越少；而你如果追求对网络的容忍，想降低发包数，并且增加同时游戏的人数，那么相应的就需要以降低即时感为代价，其二者不可得兼。然而聪明的策划和程序们总能想出很多好主意，利用障眼法和玩法规避，动作掩盖等方法，在相同的情况下来掩盖延迟，让玩家“看起来”更加“即时”和“爽快”，而这个方法具体该怎么做，并没有统一的做法，就得大家结合自己的游戏和玩法，发挥自己的聪明才智了。

　　结果同步法

　　结果同步往往比较简单，位置即使全部错乱或者延迟很久都没有关系，因为游戏过程完全不在乎位置，只在乎最后的结果，比如《梦幻西游》这样的“回合制 RPG” 游戏，屏幕上的人走到哪里确实无所谓，所有操作都是要点击或者选择菜单来下命令，象这样的游戏背后其实是文字游戏，只是加了一个图形的壳。

　　游戏表面上看起来是动作/RTS 游戏，但是没有玩家直接协作和对抗，都是单机游戏，并不需要同步什么东西，服务端只要监测下结果不离谱即可，延迟检测都没关系。基本是 PVE，而且无协作。即使是 PVP也就是打一下别人的离线数据，和无同步回合制游戏并无本质上的区别。

　　传输协议选择

　　老话题 TCP还是 UDP，答案是大部分时候，TCP打开 NODELAY即可，现在网络情况好了很多，没必要引入新的复杂度。即便是“帧锁定算法”上线的多人实时格斗游戏，也有在用 TCP跑着的。帧间同步如果能够做到更好的架设机房，那么延迟基本能控制在 10ms以内，将游戏玩家按照区域分服务器，让他们选择更快的服务器。

　　即便是带 DR的状态同步，很多也都是 TCP的，《魔兽世界》和《暗黑破坏神3》都是基于 TCP来实现的，所以我的建议是，先上 TCP，把你的游戏发布出去。

　　当然，等到你的游戏发布出去了，开始挣钱了，你想改进你的游戏效果，特别是高峰期的卡顿比例（需要收集客户端统计），那么你可以使用 UDP来改进，《街霸4》和《英雄联盟》都是使用 UDP的，比如你可以使用 libenet（英雄联盟用的）。不过 libenet所采用的传输技术，是上世纪的标准 ARQ做法了，《街霸4》所采用的传输技术远远高过 libenet，如果你想采用更为现代的传输技术，赢得更低延迟的话，可以使用我的“快速传输协议-KCP”（http://www.skywind.me/blog/archives/1048），被再若干上线项目和开源项目使用的协议，效果远远 PK libenet。

　　在使用 KCP时，你可以用在你 TCP的基础上，再登陆时服务端返回 UDP端口和密钥，客户端通过 TCP收到以后，向服务端的 UDP端口每隔一秒重复发送包含握手信息，直到服务端返回成功或者失败。服务端通过 UDP传上来的密钥得知该客户端 sockaddr对应的 TCP连接，这样就建立 TCP连接到 UDP连接的映射关系。为了保持连接和 NAT出口映射，客户端一般需要每 60秒就发送一个 UDP心跳，服务端收到后回复客户端，再在这个 UDP连接的基础上增加调用 KCP的逻辑，实现快速可靠传输，这样一套 TCP/UDP两用的传输系统就建立了。

　　中国的网络情况比较特殊，会存在有些网络 UDP连接不上的情况，因此都是先连接 TCP，然后试图 UDP，UDP不通的情况下，退回 TCP也能正常游戏，一旦 TCP断开，则认为 UDP也断开了。

　　不果归根结底，还是先上 TCP，再根据自己游戏的特点和是否出现传输问题，选择 UDP。

　　话题总结

　　根据游戏类型，选择恰当的同步方式和传输协议是最基础的问题，很多讲述网络同步的文章一般就是只会强调上述那么多种算法的其中一种方式，好像使用该方式就可以 hold住所有游戏一样的，其实并非如此。技术需要多和策划沟通，别策划一个需求下来，技术就来一句：无法实现，这样的游戏永远没有竞争力。就像国内当时都是慢节奏 RPG，偶尔有点 ARPG的时候，大家觉得《DNF》这样的游戏无法实现，于是韩国实现了，在市场上取得了先机，国内才慢慢跟进，再一看，哇塞，好多坑呢。

　　然后开发者开始在网上寻找各种同步算法，东一榔头西一棒子，明明是一款需要帧间同步的格斗游戏，结果却上了导航推测，最后发现问题永远解决不了，一堆 BUG这就叫误导。正因为我 2004年就开始弄同步相关的问题，期间也指导过不少游戏设计他们的同步方案，所以这次相当于将以前的观点做一个总结和点评，根据自己的游戏类型选择最适合的同步算法，为玩家提供更好的体验才是关键。

　　相关阅读：

　　手机格斗网游该如何避免延迟？

　　影子跟随算法：FPS游戏中游戏同步性的实现

锐亚教育，游戏开发论坛|游戏制作人|游戏策划|游戏开发|独立游戏|游戏产业|游戏研发|游戏运营| unity|unity3d|unity3d官网|unity3d 教程|金融帝国3|8k8k8k|mcafee8.5i|游戏蛮牛|蛮牛 unity|蛮牛