蓝牙4.0相关资料(LBE)

LBE应用,iOS平台上只能是基于GATT协议的(貌似是比较通用的一个协议)

 

GATT简述:分主设备(Client)/外围设备(Service、Peripheral)) ,比如蓝牙耳机就是一个Service(会广播自己的信息),手机(client)主动搜索并连接耳机,Service接受连接后就可以按照协议交换信息。一个设备可以包含多个Service,每个Service可以包含多个提供数据的Characteristic,如图:(具体如何广播(advancing),如何交换信息,后边再讲)

gatt profile hierarchy.ashx.png

苹果关于蓝牙4.0的规范文档:https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf

蓝牙官方文档下载页面:https://www.bluetooth.com/specifications/adopted-specifications

 

蓝牙4.2官方文档:Core Version 4.2   (我们主要关心应用层(第六章在97页)

BLUETOOTH APPLICATION ARCHITECTURE)

 

GATT协议官方资料:https://www.bluetooth.com/specifications/generic-attributes-overview

UserDataService(UDS)资料:1.0

资源网址收藏

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. 影子状态是跳变的,但实体追赶影子是连续的,故整个过程是平滑的。

clip_image002

算法演示

前面的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秒的减速过程,这样就实现了无差别同步,不需要相位滞后来避免拉扯影响用户感。

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

image

图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分多次打死,而不是以及毙命,等等,都是大家可以发挥想象的地方。

 

相关例子:

文章相关DEMO如果有需要的话,可向我索要。

 

文献参考:

 

林伟(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秒),情况下,保证自动计算关键帧适应各种网络条件后,就能够像编写单机游戏一样开发网游,而不需状态上作复杂的位置/状态同步。

20161010-87

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

最后这张图是运行KOF99的效果图,两边完美同步。
最后这张图是运行KOF99的效果图,两边完美同步。

乐观帧锁定

针对传统严格帧锁定算法中网速慢会卡到网速快的问题,实践中线上动作游戏通常用“定时不等待”的乐观方式再每次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值进行比较,如果相同则认可,如果不通则记录或者处理,服务端如果根据游戏当前进程加入一些临时事件(比如天上掉下一个宝箱),可以在广播的时候附带。

(完)