未分类归档 - 第7页共9页

视频编码封装推流资料（直播（安卓

理论：

大神博客：http://lib.csdn.net/article/liveplay/40882
安卓流程简介：http://blog.csdn.net/qq_26986211/article/details/52452268
腾讯直播技术分享：http://dev.qq.com/topic/5811d42e7fd6ec467453bf58

实践：

搭建rtmp推流服务器：http://blog.csdn.net/qq_30513483/article/details/51994820

资源网址收藏

mac精品应用下载：http://xclient.info
json在线解析：json.cn
曲线函数拟合：http://www.atool.org/fitted_curve.php
动画缓动曲线：http://www.jianshu.com/p/9b6824f7af51 （文中还有两个链接）

gradle资料：
1、gradle android plugin 用户指南文档（汉化）：https://avatarqing.github.io/Gradle-Plugin-User-Guide-Chinese-Verision/basic_project/general_tasks.html
2、gradle android plugin 用户指南文档（英文）：http://tools.android.com/tech-docs/new-build-system/user-guide
http://tools.android.com/tech-docs/new-build-system
http://tools.android.com/tech-docs/new-build-system/gradle-experimental（这个是NDK开发用的gradle插件说明）
https://android-developers.blogspot.com/2016/11/make-and-ndk-build-support-in-android.html (官方技术博客，如果大量使用c++代码官方推荐使用CMake编译)

NDK开发的小坑：native-activity的官方示例，往里边加java代码测试jin，始终不能获取到自定义的java类。原因是manifest文件中设置了has code 为false （PS：官方简直有病

OpenGL学习资料：1、https://www.opengl.org （官网点击右边的链接可以找到ReferenceCard 里边可以看到几乎所有的函数，分类很清晰。
2、http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-14-render-to-texture/ （OpenGL教程
3、Nehe的OpenGL教程（固定管线，非常古老，但是可以回味一下里边详细讲了windows的环境如何搭建，而不是用GLUT或者GLFW来直接初始化环境。
4、http://learnopengl.com 群友推荐的教程，还没看过，可以看出来很成规章。汉化版：https://learnopengl-cn.github.io

影子跟随算法【转】

原文：http://www.skywind.me/blog/archives/1145

算法简述

动作类游戏如何在高延迟下实现同步？不同的客户端网络情况，如何实现延迟补偿？十年前开始关注该问题，转眼十年已过，看到大家还在问这类问题，旧文一篇，略作补充（关于游戏同步相关问题还可以见我写于2005年的另外两篇文章，帧锁定算法和网游同步法则）：

影子跟随算法由普通DR（dead reckoning）算法发展而来，我将其称为“影子跟随”意再表示算法同步策略的主要思想：

1．屏幕上现实的实体（entity）只是不停的追逐它的“影子”（shadow）。

2．服务器向各客户端发送各个影子的状态改变（坐标，方向，速度，时间）。

3．各个客户端收到以后按照当前重新插值修正影子状态。

4．影子状态是跳变的，但实体追赶影子是连续的，故整个过程是平滑的。

图1 算法演示

前面的1号终端控制红色飞船P1向左飞，并把自己的状态时时告诉服务器

后面的2号终端上接收到飞船P1的影子S1的状态（向左移动），并让P1的实体追赶S1

网络性能指标一：带宽，限制了实时游戏的人数容量

网络性能指标二：延时，决定了实时游戏的最低反应时间

使用该算法可以容易的开发出一款马里奥赛车，或者Counter Strike，详细说明见后：

算法比较：

1．帧间同步：不同客户端每帧显示相同的内容，键盘/时钟数据传到服务器，服务器确认后所有终端做出响应，多用于局域网游戏，比如红警（需要等待客户端），街霸II的网络版（360），网速要求高，复杂度低。参考以及 LockStep和TimeWrap算法，以及我2007年旧文帧锁定算法。

2．插值同步：不同客户端显示不同步，但是状态同步，常见的Dead Reckoning（或叫导航插值），效果好，但复杂度高。常见于竞速类游戏和 FPS游戏。

算法定义：

1．时间：以贞为单位（FPS=10），一开始由服务器告诉向所有客户端，每5分钟同步。

2．玩家：每个玩家控制自己的实体，并在每贞将状态改变告知服务器。

3．状态：状态数据 = 实体ID + 坐标 + 方向 + 速度 + 时间（贞）。

4．插值：收到新状态包后将根据其运动方向与时间，根据现有时间计算当前的新状态。

5．跟随：实体不停的追踪自己的影子，追上后与影子保持状态同步。

相位滞后：可选参数，实体与影子保持一定距离同步，相当于保持一定车距，这样在控制者突然停止的时候，不容易因为网络延迟跑过了又被拉回来。

惯性移动：可选参数，开始移动或者停止或者改变方向都有加速度，这样就不需相位滞后了。

每次服务器向各个客户端同步时间的时候，由于延迟，所有客户端的时间都是慢于服务器的，这没有关系，只要大家在一定误差范围内以相同的速度增加，就完全没有问题。

图2 IDC网络响应

在公网平均130ms的Latency下，是不存在“完全的”的同步情况。如何通过消除/隐藏延时，将用户带入快速的交互式实时游戏中，体验完美的互动娱乐呢？

让所有的用户屏幕上面表现出完全不同的表象是完全没有问题的；

把这些完全不同表象完全柔和在一个统一的逻辑中也是完全没有问题的。

需要根据具体情况，分清楚哪些我们可以努力，哪些我们不值得努力，弄明白实时游戏中同步问题关键之所在，巧妙的化解与规避游戏，最终在适合普遍用户网络环境中(200ms)，实现实时快速互动游戏。

案例解析：Counter Strike

实现CS的话，首先我们需要给人物移动加上惯性，比如静止状态突然开始移动，那么需要0.5-1秒的加速过程，而移动中突然停止也需要0.5-1秒的减速过程，这样就实现了无差别同步，不需要相位滞后来避免拉扯影响用户感。

同时开枪射击采用客户端判断，也就是说如果我看见你在墙前面，开枪射中，那么我向服务器发送“我击中你了”，这时有可能真实的你在墙后，那么表现出来的就是我看见我打中你了（减不减血由服务段判断），而你没有看见我，觉得我穿墙打中你了。

图3 CS的同步逻辑

关键状态进行缓存，不然如果别人向前连续跳五次，每次取得状态都取到最高点的话，别人客户端上的影子和跟随的实体会奇怪的持续的飞在天上，所以需要将起跳和落地这两个关键状态缓存，实体追赶时只有追上的第一个状态（一号影子）才能追逐第二个状态（二号影子）。

由此可以在完全时间同步的情况下平滑的跑动、跳跃，开枪射击采用客户端判断后手感得到提高，唯一需要担心的就是外挂，外挂多是实时游戏的代价，只能通过Cheating Death等工具防止了。

案例解析：马里奥赛车

用该算法实现马里奥赛车是很简单的，影子和实体都使用惯性，由于赛车惯性很大，不容易有突变的状态更新，所以效果会比FPS游戏更好。

玩家碰到道具后，马上在屏幕上隐藏该道具的显示并通知服务器，由服务器决断道具属谁，由于刚碰到道具就隐藏所以不会有碰到道具却在一段时间内无法取得延迟现象。

游戏道具系统实现也很容易，比如那个将当前第一名炸毁的道具，它的描述是：原角色+对象角色+约定发生时间。既然知道对象是谁，什么时间发生，那就更本不需要怎么同步了，所有客户端和服务器在该时间让炸弹爆炸就得了，这种手法类似即时战略游戏。

游戏还有一类道具是可以发射的乌龟壳，这个东西属于有弹道的发射物，类似Quake里面的某些武器，需要作一些同步处理，基本特性是服务器判断起决定作用，客户端同步判断，如果客户端与服务器都判断集中，那就集中；如果客户端判断集中而服务器判断没有集中，那会看到该角色似乎被打了一下，但很快又恢复了速度向前冲。

由于赛车本身就具备惯性比较大的特点，因此同步效果是比较好的，可以在更大的延迟情况下表现得和FPS差不多（比如300ms效果相当于FPS的200ms）。

非可靠包：

该“影子跟随算法”支持非可靠传输协议，如果使用非可靠传输，那么我们按照特定频率（如每秒10次）定时发送状态更新，因为协议中每个更新包出了位置外还有速度、方向和时间，甚至还能加速加速度，因此我们丢一个包没有关系，可以根据后来的包重新计算插值。只有关键状态更新时才需要可靠传输，这就避免了TCP中丢包时RTO指数增长造成的延迟了。

负面情况：

该算法缺点就是无法向“帧间同步”算法那样，每次发送按键给服务器，服务器处理后再反馈结果，在局域网中（平均延迟<5ms），这样的效果相当于单机游戏一样即时，游戏性也能很复杂。然而在Internet中（平均延迟130ms，设计基准200ms，每秒最多发送10个数据包）该算法却不能像单机游戏那样有复杂的场景互动，有类似格斗游戏的即时的动作判定。

许多策划在设计实时动作游戏时很多设计我们都难以实现，这样因为策划不容易明白哪些我们能做，哪些我们不能做。即便程序员精通同步理论，策划也经常碰壁。

当多数设计被程序员回复“无法实现”后，策划只有采取一种消极设计（砍掉很多有意思的互动元素），于是网络游戏的表现力到今天还是差单机游戏一大截。

这些问题也并不能因为“影子跟随算法”的提出而得到改进，大于100ms的判定时间，都很难做到即时。

最后，该算法编码复杂度比其他同步策略高，因为服务器需要计算一份影子数据，各个客户端需要计算一份影子数据，还需要计算实体追赶，而这三种计算都需要在同样的时钟下保持一致，这就增加了编码与调试的复杂度。

总结话题：

Internet特点是“高带宽，高延迟”，可以说从本质上Internet就不是为了游戏而设计的。故此Internet绝对意义的同步是不存在的。“影子跟随算法”的核心思想有几个：时钟同步，客户端先行，平滑追赶。通过这三个特性，我们能够在近似时间同步的情况下，模拟各种物体的移动过程，而使用该算法的前提是设计者需要根据各个游戏的特性研究不同的优化技巧，策略因游戏而变。

比如发送状态更新包时，不需要每次都发送，而可以只发送改变的状态。什么时候我们觉得改变了？就是当客户端实体与自己的影子之间的误差大于某特定数值时我们才发送更新包，这样虽然玩家在原地做左右摇摆的小幅度移动，只要没有超出范围，都不需要发送新的状态更新，其他玩家机器上看起来，它是站着不动的。

比如当发现某客户端5秒钟没有相应了，那么就将该人物的影子冻结住，永远不要为了等待某个数据而不让游戏进行下去。

本算法需要客户端与服务器维护相同的时钟，当每5分钟同步的时候，直接根据服务器的时钟替换当前时钟就行了，不需要重新计算所有影子的位置，因为后续的状态数据将会马上刷新这些状态。更不需要将测量到的PING值考虑进去，该算法与PING具体值无关。

当发现策划案子不可行时，寻找近似替代方案，比如减少“一次性的”“决定性的”事件发生，比如延长导弹在空中飞行的时间，比如将敌人加入HP分多次打死，而不是以及毙命，等等，都是大家可以发挥想象的地方。

文献参考：

林伟（2007），帧锁定算法

林伟（2005），网游同步法则

Jesse Aronson (1997), Dead Reckoning: Latency Hiding for Networked Games

Yu-Shen Ng (1997), Designing Fast-Action Games For The Internet

Wentong Cai (1999), An auto-adaptive dead reckoning algorithm for distributed interactive sim

Micheal Abrash (1997), Quake’s 3-D Engine: The Big Picture

Nicholas Van Caldwell (2000), Defeating Lag With Cubic Splines

网络游戏同步法则【转】

网路的硬件也有限，而人的创造也无限，在公网平均130ms的Latency下，是不存在“完全的”的同步情况。如何通过消除/隐藏延时，将用户带入快速的交互式实时游戏中，体验完美的互动娱乐呢？

以下六点，将助你分清楚哪些我们可以努力，哪些我们不值得努力，弄明白实时游戏中同步问题关键之所在，巧妙的化解与规避游戏，最终在适合普遍用户网络环境中(200ms)，实现实时快速互动游戏：

1. 基本情况：
(A) 网络性能指标一：带宽，限制了实时游戏的人数容量
(B) 网络性能指标二：延时，决定了实时游戏的最低反应时间

2. 两个基本原则：
(A) 让所有的用户屏幕上面表现出完全不同的表象是完全没有问题的。
(B) 把这些完全不同表象完全柔和在一个统一的逻辑中也是完全没有问题的。

3. 同步的十二条应对策略：
(A) 最大可能减少游戏中的数据传输
(B) 将阻塞通信放到线程池中实现
(C) 永远不要为了等待某个数据而不让游戏进行下去
(D) 利用预测和插值改进游戏的效果
(E) 当使用预测插值的时候传送的数据不仅包括坐标，还需要速度和加速度
(F) 将输入数据枷锁或者队列化(例如键盘消息队列)，直到下次发送数据的时刻，传统的方法是在固定的时间(发送数据前)检测键盘，在游戏的原理上隐藏延时
(G) 使用事件调度表，将需要在所有用户客户端同时发生的事件，提前广播到所有用户
(H) 使用多次攻击来杀死一个精灵，尽量减少一次性的、确定性的、延时敏感的事件
(I) 延长子弹或者火箭在空中飞行的时间(在其飞行的同时，在所有客户端进行预测插值)
(J) 所有物体从一个地方移动到另外一个地方都需要时间，避免诸如“瞬间移动”的设计
(K) 尽量使游戏中所有精灵，飞船或者其他物体，都按照可预测的轨迹运行，比如在移动中增加惯性
(L) 充分发挥创造力，尽最大可能的合并游戏中前后相关的事件，合并游戏中存在的延时此问题，需要在技术上改进的同时也需要策划有所重视，规避一些影响较大的设计，巧妙的隐藏”延时”

4. 同步问题现状：
(A) 重视程度不够：很多人尚未意识到此问题的存在，曾有公司花半年时间打算做一款“松鼠大战”的网络版。
(B) 技术上无彻底解决方案：对于多数程序员，单机游戏技术善未成熟就匆匆步入网络时代。
(C) 研究这个技术需要条件：需要有实力的公司才能提供，无此条件，即便有能力的程序员也无法成功。

5. 目前网游的三大技术难题：
(A) 服务器的响应问题：如何使服务器在支持越来越多的人数的情况下提供最高的响应。
(B) 同步问题：如何在有限的网络响应情况下，实现快速实时类游戏，提供最完美的交互。
(C) 服务器分布式问题：如何在统一用户数据的情况下，利用分部式将各个分散的“世界”统一到一个“世界”中。
谁能真正解决好以上三个问题，配合策划在设计上的突破，将使其他人在至少两年内无法超越。

6. 相关补充：
(A) 网格技术现在还是抄作，真正用到游戏中，还有很多技术难点需要突破(比如：目前网格的单位计算时间是以秒计算).
(B) 其实与很多人想法相反的是现在3D技术早已不是主要的矛盾。而现在国内外对于以上三个问题可以说处于同一个起跑线上，完全有机会取得先机。
(C) 现在解决同步问题已经很紧迫，而同时所需要的环境也已经成熟，只要有所关注，半年之内可以得出较成熟的结论

那么具体怎么解决呢？再下一步怎么办？
这就得自己去实践了，我只说这么多了，哈哈，不然又教懒了那些成天再网上搜方案的人。

转载请注明出处：http://www.skywind.me/

帧锁定同步算法【转】

帧锁定算法解决游戏同步

早期 RTS，XBOX360 LIVE游戏常用同步策略是什么？格斗游戏多人联机如何保证流畅性和一致性？如何才能像单机游戏一样编写网游？敬请观看《帧锁定同步算法》

《帧锁定同步算法》转载请注明出处：http://www.skywind.me/blog/archives/131

算法概念

该算法普遍要求网速RTT要在100ms以内，一般人数不超过8人，在这样的情况下，可以像单机游戏一样编写网络游戏。所有客户端任意时刻逻辑都是统一的，缺点是一个人卡机，所有人等待。

1．客户端定时（比如每五帧）上传控制信息。
2．服务器收到所有控制信息后广播给所有客户。
3．客户端用服务器发来的更新消息中的控制信息进行游戏。
4．如果客户端进行到下一个关键帧（5帧后）时没有收到服务器的更新消息则等待。
5．如果客户端进行到下一个关键帧时已经接收到了服务器的更新消息，则将上面的数据用于游戏，并采集当前鼠标键盘输入发送给服务器，同时继续进行下去。
6．服务端采集到所有数据后再次发送下一个关键帧更新消息。

这个等待关键帧更新数据的过程称为“帧锁定”
应用案例：大部分RTS游戏，街霸II(xbox360)，Callus模拟器。

算法流程

客户端逻辑：
1. 判断当前帧F是否关键帧K1：如果不是跳转（7）。
2. 如果是关键帧，则察看有没有K1的UPDATE数据，如果没有的话重复2等待。
3. 采集当前K1的输入作为CTRL数据与K1编号一起发送给服务器
4. 从UPDATE K1中得到下一个关键帧的号码K2以及到下一个关键帧之间的输入数据I。
5. 从这个关键帧到下一个关键帧K2之间的虚拟输入都用I。
6. 令K1 = K2。
7. 执行该帧逻辑
8. 跳转（1）

服务端逻辑：
1．收集所有客户端本关键帧K1的CTRL数据（Ctrl-K）等待知道收集完成所有的CTRL-K。
2．根据所有CTRL-K，计算下一个关键帧K2的Update，计算再下一个关键帧的编号K3。
3．将Update发送给所有客户端
4．令K1=K2
5．跳转（1）

服务器根据所有客户端的最大RTT，平滑计算下一个关键帧的编号，让延迟根据网络情况自动调整。

算法演示

我根据该算法将街机模拟器修改出了一个可用于多人对战的版本，早期有一个叫做kaillera的东西，可以帮助模拟器实现多人联机，但是并没有作帧锁定，只是简单将键盘消息进行收集广播而已，后来Capcom在PSP和360上都出过街霸的联网版本，但是联网效果不理想。这个算法其实局域网有细就经常使用了，只是近年来公网速度提高，很容易找到RTT<50ms的服务器，因此根据上述算法，在平均RTT=100ms（操作灵敏度1/10秒），情况下，保证自动计算关键帧适应各种网络条件后，就能够像编写单机游戏一样开发网游，而不需状态上作复杂的位置/状态同步。

从上图的演示中可以看到，两个模拟器进程都在运行1941这个游戏，两边客户端使用了该算法，将逻辑统一在一个整体中。

乐观帧锁定

针对传统严格帧锁定算法中网速慢会卡到网速快的问题，实践中线上动作游戏通常用“定时不等待”的乐观方式再每次Interval时钟发生时固定将操作广播给所有用户，不依赖具体每个玩家是否有操作更新：

1. 单个用户当前键盘上下左右攻击跳跃是否按下用一个32位整数描述，服务端描述一局游戏中最多8玩家的键盘操作为：int player_keyboards[8];

2. 服务端每秒钟20-50次向所有客户端发送更新消息（包含所有客户端的操作和递增的帧号）：

update=（FrameID，player_keyboards）

3. 客户端就像播放游戏录像一样不停的播放这些包含每帧所有玩家操作的 update消息。

4. 客户端如果没有update数据了，就必须等待，直到有新的数据到来。

5. 客户端如果一下子收到很多连续的update，则快进播放。

6. 客户端只有按键按下或者放开，就会发送消息给服务端（而不是到每帧开始才采集键盘），消息只包含一个整数。服务端收到以后，改写player_keyboards

————-

虽然网速慢的玩家网络一卡，可能就被网速快的玩家给秒了（其他游戏也差不多）。但是网速慢的玩家不会卡到快的玩家，只会感觉自己操作延迟而已。另一个侧面来说，土豪的网宿一般比较快，我们要照顾。

随机数需要服务端提前将种子发给各个客户端，各个客户端算逻辑时用该种子生成随机数，另外该例子以键盘操作为例，实际可以以更高级的操作为例，比如“正走向A点”，“正在攻击”等。该方法目前也成功的被应用到了若干实时动作游戏中。

指令缓存

针对高级别的抽象指令（非前后可以覆盖的键盘操作），比如即时战略游戏中，各种高级操作指令，在“乐观帧锁定”中，客户端任何操作都是可靠消息发送到服务端，服务端缓存在对应玩家的指令队列里面，然后定时向所有人广播所有队列里面的历史操作，广播完成后清空队列，等待新的指令上传。客户端收到后按顺序执行这些指令，为了保证公平性，客户端可以先执轮询行每个用户的第一条指令，执行完以后弹出队列，再进入下一轮，直到没有任何指令。这样在即时战略游戏中，选择 250ms一个同步帧，每秒四次，已经足够了。如果做的好还可以象 AOE一样根据网速调整，比如网速快的时候，进化为每秒10帧，网速慢时退化成每秒4帧，2帧之类的。

————–

PS：可以把整段战斗过程的操作和随机数种子记录下来，不但可以当录像播放，还可以交给另外一台服务端延迟验算，还可以交给其他空闲的客户端验算，将验算结果的 hash值进行比较，如果相同则认可，如果不通则记录或者处理，服务端如果根据游戏当前进程加入一些临时事件（比如天上掉下一个宝箱），可以在广播的时候附带。

（完）

再谈网游同步技术：实时动作游戏同步方式和传输协议选择【转】

原贴：http://www.gameres.com/478430.html

再谈网游同步技术：实时动作游戏同步方式和传输协议选择 ...

GameRes游资网授权发布文 / 韦易笑

实时动作游戏在近年来得到迅猛的发展。而游戏同步问题，成为大家继续解决的核心问题之一。早在 2004年，国内游戏开发还处于慢节奏 RPG满天飞的情况下，我就开始实时动作游戏研究。分别在 2005-2006期间写了一系列相关文章，被好多网站转载：

帧间同步模式：《帧锁定同步算法》（2007）： http://www.skywind.me/blog/archives/131

玩法规避模式：《网络游戏同步法则》（2005）： http://www.skywind.me/blog/archives/112

预测插值模式：《影子跟随算法》（2007）： http://www.skywind.me/blog/archives/1145

如今十年过去，网上越来越多的人开始讨论游戏同步技术了，然而很多文章往往只针对某种特定的游戏情况，而观点又经常以偏概全。很多人并没有真正开发过实时动作游戏，更别说了解同步技术的前世今生了。转载别人的观点并加上自己理解的人很多，实际动过手的人很少。避免给更多人造成无谓的误导，我今天基于先前的实践和对欧美动作游戏，战网游戏，主机游戏（PSN，XBox Live等）网络技术的了解，来对这个问题做一个简单总结：

网速的变化

开发快速动作游戏，首先要对公网的网络质量数据有详细的了解。这里所说到的网速，是指 RTT，数据往返一周的毫秒时间，而非每秒传送多少 KB/s。我写这篇文章是基于我 2005-2006年开发的东西来说的，当时国内公网质量比国外差很多：

再谈网游同步技术：实时动作游戏同步方式和传输协议选择 ...

上图为 2005-2006年国内的网络环境，某三个省级 IDC的情况采样。当时公网 RTT平均值基本在100ms，120ms左右徘徊。所以我文中引用了很多 100ms。这个情况在2009 年以后已经好了很多（60ms的rtt）。到了2012年以后，公网平均 RTT已经降低到平均 40ms-50ms，省内平均10ms以内了：

再谈网游同步技术：实时动作游戏同步方式和传输协议选择 ...

上图为 2015年某省级 IDC的全国延迟情况，如若全国多布点以及区别电信联通的话，平均延迟能控制在20ms以内，延迟基本接近国外水平（当然带宽还差很多），比我当年文章中提到的网络情况好了不少。

帧间同步法

关于帧间同步的“帧锁定算法”系列的方法有很多类似实现（包括后面提到的帧间无等待改进，包括 LockStep等），但是他们的核心都是一个：保证所有客户端每帧的输入都一样。这样的方式被格斗游戏，RTS和足球（FIFA类）、篮球（NBA）等体育和动作游戏大量使用，比如我们熟悉的各大战网平台游戏（Xbox Live等），还有很多基于模拟器的街机对战平台。以及不少大型多人横版动作游戏。以开发便利，同步逻辑直观而受到大家欢迎。

帧锁定算法多用在 C/S模型中（或者一人做主多人做从的P2P里），它和 LockStep（多用于P2P）共同存在的问题就是 “网速慢的玩家会卡到网速快的玩家”，老式游戏经常一个角色断网，所有人就在那里等待。为此出现了帧锁定的改良版本 “乐观帧锁定”（具体描述见帧锁定文章的下半部分）经过了不少游戏的实践检验。先前还有几款上线的横版格斗页游（如熟知的街机三国）用 Flash 的 TCP without NODELAY 来每秒20个关键帧的模式（特意找该游戏开发者确认了一下）跑该算法（由于近两年国内网速提高，Flash的 Tcp without NODELAY也能做很多事情了），效果还不错。

具体实施时用不着按照文所述每一个步奏都相同，可以有很多变通。比如不一定是有变化的时候才通知服务端，有线上某横版格斗页游就是也可以每秒 20次向服务端直接发送数据（flash时钟不准需要自己独立计时），服务端再每秒 40次更新回所有客户端，看具体情况而定。

也有使用 UDP的端游，客户端每秒钟上传50次键盘信息到服务端，丢了就丢了，后面持续发送过来的键盘数据会覆盖前面的数据，所以丢了没关系，更快捷。当然，UDP也不是必须的，近两年网速提高很快，省内都能做到10ms的 RTT 了，跨省也就 50ms的rtt，不少页游上用该方法上裸的 TCP 照样跑的很顺畅。

而近两年国外动作游戏领域也涌现出其他一些新的改良方法，比如 Time Warp，以客户端先行+逻辑不一致时回滚的方式，带来了更好的同步效果，俗称时间回退法。不果国内暂时没看到有游戏这么尝试，更多的是国外近两年的双人动作游戏比较多，要求游戏每帧状态都可以保存，逻辑上开发会复杂一些。国内大部分是超过两人出去副本的，在3-4人出去 PK的情况下，引入状态回退，会让整个效果大打折扣。不过2人的效果确实有所改进，有兴趣的同学可以搜索 Time Warp相关的论文。

2009年，云游戏（游戏远程渲染）技术得到广泛应用，客户端上传操作，服务端远程渲染，并以低延迟视频编码流的方式传回给客户端，用的就是这样类似的技术。客户端不需要高额的硬件，也不存在盗版问题，其中 Gaikai和 OnLive两家公司做的比较好。

2012年，Sony推出 Playstation Now技术，可以在 PSV和 PS3/PS4上玩云游戏，玩家不需要购买游戏就可以免费体验一定时间。使得 PSV/PS3等低端硬件也可以流畅的跑 PS4游戏。

再谈网游同步技术：实时动作游戏同步方式和传输协议选择 ...

但是目前国外网络环境下跑的还比较流畅，国内的网络环境要低延迟传送 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年就开始弄同步相关的问题，期间也指导过不少游戏设计他们的同步方案，所以这次相当于将以前的观点做一个总结和点评，根据自己的游戏类型选择最适合的同步算法，为玩家提供更好的体验才是关键。

Android Studio2.x中NDK开发支持c++11

http://www.slideshare.net/ph0b/mastering-the-ndk-with-android-studio-and-the-gradleexperimental-plugin

ndk {
    moduleName = 'xduilib'
    stl = 'gnustl_static'
    cppFlags.add("-std=c++11")
    ldFlags.add("-c")
    ldLibs.addAll(['log', 'android'])
}