CN100428255C - 在终端上实现在线实时游戏的方法和装置 - Google Patents

Abstract

本发明提供一种在终端上实现在线实时游戏的方法和装置，属于数据传输领域。本发明克服了现有技术中数据传输时延较大的缺点，通过高压缩，高冗余的可靠性传输机制和状态同步机制，以及端到端的游戏业务流程，使在线游戏可以在不同的终端上同时运行，并且保持高度的一致，从而提高游戏参与终端的娱乐体验。本发明可以作为终端一个独立的公共算法模块，为增值游戏提供高可靠性传输，而设计游戏者无需了解这方面的内容，减少了游戏开发者的开发工作量，方便了游戏软件的开发。

Description

在终端上实现在线实时游戏的方法和装置

技术领域

本发明涉及数据传输领域，尤其涉及一种在终端上实现在线实时游戏的方法和装置。

背景技术

简单的基于本地运行的游戏已经无法满足消费者日益增长的娱乐需求，消费者更希望能通过网络连接与服务器或者与另外的终端实现互动游戏。

目前能实现互动游戏的现有技术有三种。第一种是参与游戏的各终端登陆游戏服务器，由各终端或者游戏服务器进行相应终端的参数匹配，匹配完成后，游戏服务器开始运行游戏，并把游戏运行的情景下发到参与游戏的各终端，各终端通过发送游戏操作命令给服务器获得互动游戏的体验。此技术的缺点是需要游戏服务器的参与，增加了游戏的运行成本，游戏运行的情景需要下发到参与游戏的各终端，会产生很大的数据流量，对网络带宽消耗很大。第二种现有技术与第一种技术类似，唯一的区别是游戏参与终端登陆游戏服务器后，由游戏终端创建游戏，然后邀请另一特定终端共同参与游戏。虽然它提供了定向邀请其他参与终端的功能，但它同样具有运行成本高，数据流量大，网络带宽消耗大的缺点。第三种现有技术是游戏创建终端在本地完成游戏创建，邀请另一终端参与游戏。此时游戏创建终端充当了服务器的角色，除了运行游戏外，还把游戏的情景分发给其它游戏参与终端。这种技术的缺点是游戏创建终端操作的响应时延小，而游戏参与终端操作的响应时延大，且存在操作命令丢失的可能，这样对游戏双方来说不公平；同样也需要比较大的业务带宽。

发明内容

为了克服现有技术中数据传输时延大的缺点，本发明的目的在于提供一种在终端上实现在线实时游戏的方法和装置，使在线游戏可以在不同的终端上同时运行，并且保持高度的一致，从而提高游戏参与终端的娱乐体验。

本发明提供的在终端上实现在线实时游戏的方法，具体包括以下步骤：

步骤A：主叫端邀请被叫端参与在线实时游戏；

步骤B：所述双方互相冗余发送游戏命令，所述游戏命令中包括当前的操作命令和历史操作命令；

步骤C：任何一方在接收不到当前的游戏命令时，在后继接收的游戏命令中恢复出所述当前的操作命令；

步骤D：任何一方提出终止游戏，则游戏结束。

步骤A1：主叫端向被叫端发起启动在线实时游戏的请求，所述请求中包括所述主叫端设置的游戏初始参数；

步骤A2：所述被叫端接收到所述请求后，运行所述游戏并发送确认消息给所述主叫端，所述主叫端接收到所述确认消息后，运行所述游戏。

所述步骤A2具体为：

所述被叫端接收到所述请求后，根据自己的媒体处理能力修改所述请求中的游戏的初始参数，然后运行所述游戏，并发送包含修改后的游戏初始参数的确认消息给所述主叫端，所述主叫端接收到所述确认消息后，修改相应的初始参数使双方的初始参数一致，然后运行所述游戏。

所述双方互相发送游戏命令之的均按预先定义的数据格式封装游戏命令，所述预先定义的数据格式含有状态同步码和数据包序列号。

在所述双方互相发送游戏命令的过程中，所述主叫端接收到被叫端发来的游戏命令后立即执行，同时在所述主叫端保存该命令并发回给所述被叫端以示确认，所述被叫端接收到主叫端发回的确认命令后再执行该命令。

在所述双方互相发送游戏命令的过程中，所述被叫端接收到主叫端发来的游戏命令后立即执行，同时在所述被叫端保存该命令并发回给所述主叫端以示确认，所述主叫端接收到被叫端发回的确认命令后再执行该命令。

所述步骤B中发送游戏命令具体包括以下步骤：

步骤B1：将多个游戏命令按固定的规则依次映射为二进制码；

步骤B2：将所述映射后的多个二进制码按固定的次序连接成一个二进制码流；

步骤B3：将所述二进制码流转换成字节序列后发送。

所述步骤C还包括状态同步的步骤：

所述主叫端接收到所述被叫端发来的封装了游戏命令和同步数据的数据包，将所述数据包中的状态同步码和所述主叫端接收到的上一个数据包中的状态同步码进行比较，

如果二者相同，则不发起状态同步请求；

如果二者相差的数值在设定的范围之内，则分析所述数据包中的游戏命令和同步数据，进行状态同步；

如果不是上述两种情况，则丢弃所述数据包。

所述步骤C还包括状态同步的步骤：

所述主叫端根据两次发送数据包之间的时间间隔判断是否需要所述主叫端发起状态同步请求，如果是则所述主叫端向被叫端发起状态同步的请求，所述被叫端接收到所述请求后，进行状态同步；如果不是则所述主叫端将刚接收到的数据包中的数据包序列号与接收到的上一个合法数据包中的数据包序列号进行比较，如果二者的关系符合设定的条件，则所述主叫端不发起状态同步的请求，否则所述主叫端丢弃刚接收到的数据包。

本发明还提供了一种在终端上实现在线实时游戏的装置，所述装置包括：

邀请模块，用于主叫端邀请被叫端参与在线实时游戏；

发送模块，用于所述双方互相冗余发送游戏命令，所述游戏命令中包括当前的操作命令和历史操作命令；

恢复模块，用于任何一方在接收不到当前的游戏命令时，在后继接收的游戏命令中恢复出所述当前的操作命令；

终止模块，用于任何一方提出终止游戏，则游戏结束。

所述邀请模块具体包括：

请求单元，用于主叫端向被叫端发起启动在线实时游戏的请求，所述请求中包括所述主叫端设置的游戏初始参数；

运行单元，用于所述被叫端接收到所述请求后，运行所述游戏并发送确认消息给所述主叫端，所述主叫端接收到所述确认消息后，运行所述游戏。

所述运行单元具体包括：

第一运行子单元，用于所述被叫端接收到所述请求后，根据自己的媒体处理能力修改所述请求中的游戏的初始参数，然后运行所述游戏，并发送包含修改后的游戏初始参数的确认消息给所述主叫端；

第二运行子单元，用于所述主叫端接收到所述确认消息后，修改相应的初始参数使双方的初始参数一致，然后运行所述游戏。

所述装置还包括：

封装模块，用于所述双方互相发送游戏命令之前均按预先定义的数据格式封装游戏命令，所述预先定义的数据格式含有状态同步码和数据包序列号。

所述装置还包括：

第一执行和确认模块，用于在所述双方互相发送游戏命令的过程中，所述主叫端接收到被叫端发来的游戏命令后立即执行，同时在所述主叫端保存该命令并发回给所述被叫端以示确认，所述被叫端接收到主叫端发回的确认命令后再执行该命令。

所述装置还包括：

第二执行和确认模块，用于在所述双方互相发送游戏命令的过程中，所述被叫端接收到主叫端发来的游戏命令后立即执行，同时在所述被叫端保存该命令并发回给所述主叫端以示确认，所述主叫端接收到被叫端发回的确认命令后再执行该命令。

所述发送模块具体包括：

映射单元，用于将多个游戏命令按固定的规则依次映射为二进制码；

连接单元，用于将所述映射后的多个二进制码按固定的次序连接成一个二进制码流；

发送单元，用于将所述二进制码流转换成字节序列后发送。

所述发送模块还包括：

第一同步单元，用于所述主叫端接收到所述被叫端发来的封装了游戏命令和同步数据的数据包，将所述数据包中的状态同步码和所述主叫端接收到的上一个数据包中的状态同步码进行比较，如果二者相同，则不发起状态同步请求；如果二者相差的数值在设定的范围之内，则分析所述数据包中的游戏命令和同步数据，进行状态同步；如果不是上述两种情况，则丢弃所述数据包。

所述发送模块还包括：

第二同步单元，用于所述主叫端根据两次发送数据包之间的时间间隔判断是否需要所述主叫端发起状态同步请求，如果是则所述主叫端向被叫端发起状态同步的请求，所述被叫端接收到所述请求后，进行状态同步；如果不是则所述主叫端将刚接收到的数据包中的数据包序列号与接收到的上一个合法数据包中的数据包序列号进行比较，如果二者的关系符合设定的条件，则所述主叫端不发起状态同步的请求，否则所述主叫端丢弃刚接收到的数据包。

本发明的有益效果是通过高压缩，高冗余的可靠性传输机制和状态同步机制，以及端到端的游戏业务流程，使在线游戏可以在不同的终端上同时运行，并且保持高度的一致，为在线游戏提供了更好的业务体验。本发明可以作为终端一个独立的公共算法模块，为增值游戏提供高可靠性传输，而设计游戏者无需了解这方面的内容，减少了游戏开发者的开发工作量，方便了游戏软件的开发。

附图说明

图1为本发明在终端上实现在线实时游戏的方法的流程图；

图2为本发明在终端上实现在线实时游戏的方法的实施例的流程图；

图3为本发明在终端上实现在线实时游戏的方法中游戏双方互相通讯的示意图；

图4为本发明中主叫端用压缩方法发送操作命令的示意图；

图5为本发明中主叫端压缩发送待确认的被叫端操作命令的示意图；

图6为本发明在终端上实现在线实时游戏的装置示意图。

具体实施方式

下面结合附图和实施例来进一步说明本发明，但并不作为对本发明的限定。

参见图1，本发明在终端上实现在线实时游戏的方法包括以下步骤：

步骤1：主叫端邀请被叫端参与在线实时游戏；被叫端可以是近端终端也可以是远端终端，当被叫端是近端终端时，如双方同在一个局域网内，则不用通过电信网可以进行近距离通讯，从而实现游戏的免费互动；

步骤2：主叫端和被叫端互相冗余发送游戏命令，游戏命令中包括当前的操作命令和历史操作命令；历史操作命令是指在当前操作命令之前产生的操作命令，可以是一个操作命令，也可以是多个操作命令，它的个数可以在设置初始参数时具体指定；

步骤3：任何一方在接收不到当前的游戏命令时，在后继接收的游戏命令中恢复出所述当前的操作命令；由于后继接收到的游戏命令中包含了之前的操作命令，而当前的操作命令在后继操作命令之前发生，所以可以从后继的操作命令中中提取出当前的操作命令；

步骤4：任何一方提出终止游戏，则游戏结束。

下面以一个具体的实施例来说明上述方法，参见图2，该方法具体包括以下步骤：

步骤11：主叫终端根据使用者意愿与被叫端建立连接；

步骤12：主叫端从游戏软件中获取相关的初始参数，初始参数可包括：游戏开发商、游戏名称、游戏下载地址、游戏状态数据、命令有效比特位、数据发送频率、数据连续传输次数、对端数据连续确认次数和状态同步数据大小等；

游戏初始参数既可以由游戏软件开发者提供，也可以通过终端软件内部进行预设置，还可以根据使用者的意愿进行调整(即用户通过游戏界面上的菜单进行设置)；

在上述初始参数的基础上本例还增加了一些新的应用要求，如游戏格式，具体举例如下：

m＝data 46666 udp x-huawei-game；//增加了格式说明“x-huawei-game”，表明该媒体是一种游戏格式

a＝gamedevelope:huawei；       //本游戏的开发商

a＝gamename:tankwar；         //游戏的名字

a＝downloadaddress:http://www.huawei.com/cn/game/exe/view.do？f＝402&ctype＝0；

                             //游戏的下载地址

a＝gamedate:“2”；              //游戏的状态数据，由游戏开发商自行定义，在本例中，游戏从第二关开始玩

a＝validbit:5；            //数据中有效数据的比特数，用于数据压缩

a＝framerate:10；         //每秒发送数据包的次数

a＝sendtimes:12；        //数据发送的冗余传输次数

a＝recvacktimes:12；    //对端数据进行确认的次数

a＝syncpayloadsize:20；//状态同步数据的最大数据包大小

主叫端向被叫端发起启动在线实时游戏的请求，请求中包含上述游戏初始参数，参见图3，主叫端在SIP信令中INVITE方法上带的SDP中，描述了上述相关初始参数；

步骤13：被叫端接收到主叫端发来的请求后，检查请求中的游戏初始参数，如果发现终端内部无相应的游戏软件，则根据参数中的游戏下载地址链接先下载游戏软件，再运行游戏；如果发现终端支持该游戏软件，则运行该游戏，并发送确认消息给主叫端；

被叫端也可以根据自己的媒体处理能力先修改游戏初始参数，再发确认消息给主叫端，如：在被叫端游戏缓冲能力较差的情况下，可以将冗余传输次数和数据确认次数都修改为10次：

a＝sendtimes:10；

a＝recvacktimes:10；

此时被叫端发送的确认消息中包含了修改后的初始参数；

步骤14：主叫端接收到被叫端发来的确认消息后，分析被叫端在200OK上携带的SDP，如果确认能支持被叫端修改后的游戏初始参数则修改本端的参数，使双方的参数一致，并回ACK确认消息给被叫端；在上述双方进行初始参数协商的过程中，也可采用XML进行描述的方法进行协商，其效果是一样的；

然后主叫端运行该游戏，并按照预先定义的数据格式封装游戏命令；

所述预先定义的数据格式如下表所示：

表中的格式说明如下：

数据包类型：长度为4比特，总共可定义16种数据类型，本例只定义了10种类型，具体如下：

0：终端在线确认，表明该数据包没有净荷，只包含两个字节的内容；

1：表明该数据包只包含本端命令；

2：表明该数据包只包含对端待确认命令；

3：表明该数据包同时包含本端命令和对端待确认命令，净荷中前部分是本端命令的内容，后部分是对端待确认命令的内容；

4：表明该数据包包含失步指示和完整的同步数据；

5：表明该数据包包含失步指示和初始的同步数据；

6：表明该数据包为同步数据(中间数据段)；

7：表明该数据包为同步数据(结束数据段)；

8：同步数据接收确认，表明该数据包包含对同步数据接收的确认命令；

9：表明该数据包为同步成功指示命令，即对同步结果的确认。

其中数据类型根据上述的定义和实际发送数据的情况填入数据包；

同步码：长度为4比特，总共可定义16个同步码，同步码可循环使用，初始时设置为0，当游戏双方发生失步时，需要启动状态同步，这时的同步码应该加1(模16)；

数据包序列号：长度为8比特，总共可定义256个序列号，序号可循环使用，每发一个数据包，序列号加1(模256)；

净荷：协议包内的用户数据，净荷大小根据数据包类型的不同而不同；

步骤15：主叫端和被叫端互相冗余发送游戏命令，游戏命令中包括当前的操作命令和历史操作命令；其中历史操作命令可以为一个或者多个，本例中步骤13将数据发送的冗余传输次数修改为10(a＝sendtimes:10)，则每次发送的游戏命令包括当前的操作命令和发生在当前操作命令之前的9个历史操作命令，如果当前操作命令之前的历史操作命令个数小于9个，则以实际的数目为准，但是每次发送的游戏命令中最多不会超过10个操作命令；

主叫端发送游戏命令之前，首先检查是否存在有效的本端操作命令，如果有，则将本端操作命令封装进净荷中再发送；如果没有，则检查是否存在有效的待确认的对端操作命令，如果有，则将待确认的对端操作命令封装进净荷中再发送；如果长时间无有效数据发送，则需要在一个内部定义的时间(如3秒)内发送一个空数据包到被叫端，和对方确认连接并未中断；

为了保证游戏的实时性(尤其是当被叫端为远端的用户时)，本发明采用了一种确认机制，具体过程如下：

对于主叫端接收的被叫端发来的游戏命令，主叫端接收到之后就可以立即执行，但同时必须将该命令在本端保存，再发回给被叫端进行确认，表明该命令已经收到并执行，被叫端接收到主叫端发回的命令后才可以执行该命令；

对于主叫端发出的游戏命令，被叫端接收到后保存该命令并立即执行，并且要发回该命令给主叫端进行确认，表明该命令已经被收到并执行，主叫端收到被叫端发回的该命令即得到被叫端的回送确认后，才能在本地执行该命令；

本发明中的数据包是承载在UDP/IP协议上的，直接采用IP协议进行承载也可以，如果用其它的传输协议，如RTP/UDP/IP也是可以的；

为了提高数据传输的效率，增强数据传输的可靠性，本发明在冗余发送和确认机制的基础上还提供了压缩发送游戏命令的方法，具体包括以下步骤：

步骤16：将多个游戏命令按固定的规则依次映射为二进制码，固定的规则是指事先指定的一组映射关系，并且在不同的应用中规则有可能是不相同的，映射后的二进制码的位数也有可能是不同的；如将四个游戏命令“用户从键盘上敲入＜”，“用户从键盘上敲入＞”，“用户从键盘上敲入L”，“用户从键盘上敲入空格”分别映射成二进制码“00”，“01”，“10”和“11”，对应于实际的应用表示“向左”，“向右”，“前进”和“后退”，此时的映射关系为事先指定的，当游戏软件完成设计时就已经把该映射关系固定在软件程序里，由于只有四个命令，所以二进制码只要两个比特位就够了，若有八个命令则二进制码需要三个比特位才行，初始参数中设置的数据中有效数据的比特数(如a＝validbit:5能表示32个命令)就是指的此处的二进制码的位数；

步骤17：将所述映射后的多个二进制码按固定的次序连接成一个二进制码流，固定的次序是指顺序或者逆序把所有二进制码逐个连接起来，如有4个二进制码“00”，“01”，“10”和“11”，顺序连接后形成的二进制码流为“00011011”，逆序连接后形成的二进制码流为“11100100”，连接完成后按模8在二进制码流的末端以加零的方式补齐位数，假设二进制码流的位数为10个比特位，则在二进制码流的末端补6个“0”形成一个16位的二进制码流；

步骤18：将所述二进制码流转换成字节序列后发送，如把16位的二进制码流转换成两个字节后发送；

步骤16至18所述的压缩方法即可以用于主叫端发送游戏命令时进行压缩，也可以用于确认被叫端发来的游戏命令时进行压缩，下面分别举例说明：

举例一：主叫端压缩本端的游戏命令发送给被叫端

假设主叫端设置初始参数时指定数据发送的冗余传输次数为10(a＝sendtimes:10)，操作命令有效长度为5个比特长度，发送定时器是100毫秒；主叫端根据上述参数以及事先指定的映射规则在本端首先创建一列长度为10的命令队列，然后对该命令队列中的游戏命令进行压缩，参见图4，主叫端压缩游戏命令时执行以下步骤：

(1)每隔100毫秒，主叫端将用户通过界面发来的操作命令翻译成游戏命令，并发送到上述命令队列中，如果操作界面没有操作命令，则产生一个空命令(如全零)；

(2主叫端将当前操作命令映射成二进制码后按先进先出原则移入命令队列中，具体过程如下：

将命令N-8移动到命令N-9的位置，命令N-7移动到命令N-8的位置，...，命令N移动到命令N-1的位置，当前操作命令移动到命令N的位置，直到命令队列中装满10个操作命令为止；

(3)将命令队列中的10个操作命令顺序连接，由于每个操作命令的有效长度为5个比特位，则形成一个长度为50个比特位的二进制码流，然后按模8在该二进制码流的末端补6个零，成为一个长度为56个比特位的二进制码流；

(4)将该二进制码流转化为7个字节的发送命令，并发送给被叫端；

在主叫端向被叫端发送游戏命令的过程中，上述四个步骤是循环执行的；

举例二：主叫端压缩发送待确认的被叫端操作命令

假设主叫端在设置游戏的初始参数时指定对端数据进行确认的次数为10(a＝recvacktimes:10)，操作命令有效长度为5个比特长度，发送定时器是100毫秒；主叫端根据上述参数以及事先指定的映射规则首先在本端创建一列长度为10的命令队列，然后对该命令队列中的游戏命令进行压缩，参见图5，主叫端压缩待确认的对端游戏命令时执行以下步骤：

(1)每隔100毫秒，主叫端接收被叫端发来的操作命令，发送到上述命令队列中，如果操作界面没有操作命令，则产生一个空命令(如全零)；

(2主叫端将当前操作命令映射成二进制码后按先进先出原则移入命令队列中，具体过程如下：

将命令M-8移动到命令M-9的位置，命令M-7移动到命令M-8的位置，...，命令M移动到命令M-1的位置，当前操作命令移动到命令M的位置，直到命令队列中装满10个操作命令为止；

(3)将命令队列中的10个操作命令顺序连接，由于每个操作命令的有效长度为5个比特位，则形成一个长度为50个比特位的二进制码流，然后按模8在该二进制码流的末端补6个零，成为一个长度为56个比特位的二进制码流；

(4)将该二进制码流转化为7个字节的对端确认命令，并发送给被叫端；

在主叫端向被叫端发送确认被叫端的游戏命令的过程中，上述四个步骤是循环执行的；

为了进一步完善本发明，本发明还提供了状态同步的步骤，具体如下：

步骤19：所述主叫端接收到所述被叫端发来的封装了游戏命令和同步数据的数据包，将所述数据包中的状态同步码和所述主叫端接收到的上一个数据包中的状态同步码进行比较，

如果二者相同，则不发起状态同步请求，说明双方状态同步；

如果二者相差的数值在设定的范围之内，则分析所述数据包中的游戏命令和同步数据，进行状态同步，假设游戏初始启动时设置状态同步码为0，每次状态同步时都按模16加1，那么此时若刚接收到数据包中的状态同步码是上一个数据包中的状态同步码在模16上加1，则说明被叫端已经发起同步请求，要求进入状态同步模式，于是主叫端就会暂停游戏进行，进行游戏的状态同步；同时也会把同步数据发送给被叫端，确认该同步数据已在主叫端执行；状态同步完成后，主叫端清除所有经过被叫端确认的本端操作命令以及所有对端发来的操作命令，同时发送状态同步成功指示给被叫端；

如果不是上述两种情况，则丢弃所述数据包，该数据包为无效数据包；

步骤20：所述主叫端根据两次发送数据包之间的时间间隔T(由初始参数中设置的每秒发送数据包的次数可以推算出)判断是否需要所述主叫端发起状态同步请求，如果是则所述主叫端向被叫端发起状态同步的请求，所述被叫端接收到所述请求后，进行状态同步；否则所述主叫端将刚接收到的数据包中的数据包序列号与接收到的上一个合法数据包中的数据包序列号进行比较，如果二者的关系符合设定的条件，则说明双方状态同步，数据包是合法的可以使用，所述主叫端不发起状态同步的请求，否则数据包为无效数据包，需要丢弃；

首先判断如果超过10*T(也可以根据实际需要将10设置成不同的值)的时间主叫端还收不到合法数据包，则说明有大量的数据包在传输过程中被延迟或丢弃，这时候双方状态已经不同步，需要主叫端发起状态同步请求，主叫端会主动发送要求进行状态同步的命令给被叫端；

否则做出如下判断：

假设数据包序列号是按模64(也可以根据实际需要设置不同的值)循环使用的，则有下面两种情况：

(1)如果刚接收到的数据包中的数据包序列号Y与上一个合法数据包中的数据包序列号X符合条件：((Y+64-X)mod 64)＞9，则表明此数据包是无效数据包，需要丢弃；

(2)如果刚接收到的数据包中的数据包序列号Y与上一个合法数据包中的数据包序列号X符合条件：((Y+64-X)mod 64)＜＝9，则说明双方状态同步，数据包合法可以使用；

其中数值9为一个具体的实例，实际应用中可以根据不同的情况设置成不同的数值；

当主叫端发起状态同步请求时，首先暂停游戏进行，并把游戏状态同步数据发送给被叫端；主叫端清除所有经被叫端确认的本端操作命令以及所有对端发来的操作命令；然后发送失步指示和状态同步数据给被叫端；在数据发送的过程中，如果被叫端未收到同步数据，则需要进行数据重发，如果被叫端多次未收到同步数据或长时间未收到同步成功指示，则释放游戏；

在游戏的运行过程中，主叫端定期(如每隔100毫秒)检查本端是否存在有效数据，如果发现存在有效的同步数据、同步请求和成功指示，则优先发送这些数据，然后再发送本端操作命令和待确认的对端操作命令；

本发明中的游戏操作命令和状态同步数据都是采用和信令通道不同的数据传输通道进行传输的(如媒体通道)，在实际应用中由于数据流量很小，也可以采用和信令通道相同的通道进行传输；

游戏终止时需要执行下面的步骤：

步骤21：游戏的一方决定终止游戏，发送消息BYE给对方，结束游戏；接收到BYE消息的另一方，回200OK，结束游戏；游戏结束后，会话并不自动终止，游戏的任何一方可以再发起邀请INVITE，协商下一次游戏。

参见图6，本发明还提供了一种在终端上实现在线实时游戏的装置，所述装置包括两个部分：一部分是终端模块，是终端厂家根据本发明为游戏开发者提供的一整套高可靠性传输方案；另一部分是游戏软件模块，是游戏开发者开发的软件中，涉及和终端软件进行交互的部分；

终端模块，用于和对端建立连接以及存储用户设置的初始参数，还用于定期发送本端操作命令和经本端确认的对端操作命令给对端以及对接收到的对端数据进行分析和处理；

游戏软件模块，用于设置游戏的初始参数并发送该参数给所述终端模块，还用于转换由所述终端模块发来的本端操作命令成游戏软件的命令操作码以及返回该命令操作码给所述终端模块，还用于运行由所述终端模块发来的对端操作命令和经对端确认的本端操作命令并将运行结果输出到所述终端模块。

所述终端模块包括：

(1)通讯控制模块，用于和对端建立连接；

(2)数据接收模块，用于接收所述通讯控制模块发来的初始参数和对端发来的数据，还用于根据数据包的类型、序列号和状态同步码对所述数据进行分析和处理；

如果分析发现两边操作失步，则发送暂停游戏的命令给同步模块；

如果分析发现数据包是经过长时间延迟过来的，则表明该数据包无效，直接丢弃；

如果分析发现数据包有效，则将对端的操作命令发送给游戏软件模块中的对端命令模块，同时发送给终端模块中的对端命令确认模块；将经对端确认的本端操作命令发送给本端命令确认模块；

(3)数据发送模块，用于接收所述通讯控制模块发来的初始参数，还用于发送本端操作命令和经本端确认的对端操作命令给对端；

(4)对端命令确认模块，用于接收所述通讯控制模块发来的初始参数以及数据接收模块发来的对端操作命令，还用于定期将对端操作命令发送到所述数据发送模块中；

(5)本端命令模块，用于接收所述通讯控制模块发来的初始参数，还用于保存本端操作命令并定期将所述命令发送给所述数据发送模块；

(6)界面模块，用于显示游戏界面及游戏运行过程中的视频画面，还用于对用户通过终端(如键盘、鼠标、触摸屏等)输入的操作行为进行分析，如果用户输入的是操作命令，则发送给翻译模块；如果用户输入的是设置的初始参数则发送给通讯控制模块；

所述游戏软件模块包括：

(1)初始模块，用于设置游戏的初始参数，还用于将设置好的游戏初始参数发送给所述通讯控制模块；

(2)本端命令确认模块，用于接收所述数据接收模块发来的经过对端确认的本端操作命令并开辟合适的缓冲空间保存该命令；

(3)对端命令模块，用于接收所述数据接收模块发来的对端的操作命令并开辟合适的缓冲空间保存该命令；

(4)运行模块，用于接收所述本端命令确认模块和对端命令模块发来的操作命令，还用于运行所述操作命令并将运行结果输出到所述界面模块；

(5)翻译模块，用于接收所述界面模块发来的本端操作命令，还用于将所述命令转换成游戏软件的命令操作码并发送给所述本端命令模块。

所述数据发送模块还包括压缩子模块，用于根据压缩要求和数据包封装要求(如根据UDP，IP协议进行封装)将多个游戏操作命令按固定的规则依次映射为二进制码，还用于将所述映射后的多个二进制码按固定的次序连接成一个二进制码流，还用于将所述二进制码流转换成字节序列后发送给对端。

所述终端模块还包括同步模块，用于接收所述数据接收模块发来的对端状态同步数据，还用于将本端状态同步数据和对端状态同步数据发送给所述数据发送模块；

所述运行模块还包括同步运行子模块，用于接收所述同步模块发来的暂停命令，还用于发送游戏状态同步数据给所述同步模块。

以上只是对本发明的优选实施方式进行了描述，本领域的技术人员在本发明技术的方案范围内进行的通常变化和替换，都应包含在本发明的保护范围内。

Claims (18)

1.一种在终端上实现在线实时游戏的方法，其特征在于，所述方法包括以下步骤：

步骤A：主叫端邀请被叫端参与在线实时游戏；

步骤B：所述双方互相冗余发送游戏命令，所述游戏命令中包括当前的操作命令和历史操作命令；

步骤C：任何一方在接收不到当前的游戏命令时，在后继接收的游戏命令中恢复出所述当前的操作命令；

步骤D：任何一方提出终止游戏，则游戏结束。

2.根据权利要求1所述的在终端上实现在线实时游戏的方法，其特征在于，所述步骤A具体包括以下步骤：

步骤A1：主叫端向被叫端发起启动在线实时游戏的请求，所述请求中包括所述主叫端设置的游戏初始参数；

步骤A2：所述被叫端接收到所述请求后，运行所述游戏并发送确认消息给所述主叫端，所述主叫端接收到所述确认消息后，运行所述游戏。

3.根据权利要求2所述的在终端上实现在线实时游戏的方法，其特征在于，所述步骤A2具体为：

所述被叫端接收到所述请求后，根据自己的媒体处理能力修改所述请求中的游戏的初始参数，然后运行所述游戏，并发送包含修改后的游戏初始参数的确认消息给所述主叫端，所述主叫端接收到所述确认消息后，修改相应的初始参数使双方的初始参数一致，然后运行所述游戏。

4.根据权利要求1所述的在终端上实现在线实时游戏的方法，其特征在于，所述双方互相发送游戏命令之前均按预先定义的数据格式封装游戏命令，所述预先定义的数据格式含有状态同步码和数据包序列号。

5.根据权利要求1所述的在终端上实现在线实时游戏的方法，其特征在于，在所述双方互相发送游戏命令的过程中，所述主叫端接收到被叫端发来的游戏命令后立即执行，同时在所述主叫端保存该命令并发回给所述被叫端以示确认，所述被叫端接收到主叫端发回的确认命令后再执行该命令。

6.根据权利要求1或5所述的在终端上实现在线实时游戏的方法，其特征在于，在所述双方互相发送游戏命令的过程中，所述被叫端接收到主叫端发来的游戏命令后立即执行，同时在所述被叫端保存该命令并发回给所述主叫端以示确认，所述主叫端接收到被叫端发回的确认命令后再执行该命令。

7.根据权利要求1所述的在终端上实现在线实时游戏的方法，其特征在于，所述步骤B中发送游戏命令具体包括以下步骤：

步骤B1：将多个游戏命令按固定的规则依次映射为二进制码；

步骤B2：将所述映射后的多个二进制码按固定的次序连接成一个二进制码流；

步骤B3：将所述二进制码流转换成字节序列后发送。

8.根据权利要求4所述的在终端上实现在线实时游戏的方法，其特征在于，所述步骤C还包括状态同步的步骤：

所述主叫端接收到所述被叫端发来的封装了游戏命令和同步数据的数据包，将所述数据包中的状态同步码和所述主叫端接收到的上一个数据包中的状态同步码进行比较，

如果二者相同，则不发起状态同步请求；

如果二者相差的数值在设定的范围之内，则分析所述数据包中的游戏命令和同步数据，进行状态同步；

如果不是上述两种情况，则丢弃所述数据包。

9.根据权利要求4或8所述的在终端上实现在线实时游戏的方法，其特征在于，所述步骤C还包括状态同步的步骤：

所述主叫端根据两次发送数据包之间的时间间隔判断是否需要所述主叫端发起状态同步请求，如果是则所述主叫端向被叫端发起状态同步的请求，所述被叫端接收到所述请求后，进行状态同步；如果不是则所述主叫端将刚接收到的数据包中的数据包序列号与接收到的上一个合法数据包中的数据包序列号进行比较，如果二者的关系符合设定的条件，则所述主叫端不发起状态同步的请求，否则所述主叫端丢弃刚接收到的数据包。

10.一种在终端上实现在线实时游戏的装置，其特征在于，所述装置包括：

邀请模块，用于主叫端邀请被叫端参与在线实时游戏；

发送模块，用于所述双方互相冗余发送游戏命令，所述游戏命令中包括当前的操作命令和历史操作命令；

恢复模块，用于任何一方在接收不到当前的游戏命令时，在后继接收的游戏命令中恢复出所述当前的操作命令；

终止模块，用于任何一方提出终止游戏，则游戏结束。

11.根据权利要求10所述的在终端上实现在线实时游戏的装置，其特征在于，所述邀请模块具体包括：

请求单元，用于主叫端向被叫端发起启动在线实时游戏的请求，所述请求中包括所述主叫端设置的游戏初始参数；

运行单元，用于所述被叫端接收到所述请求后，运行所述游戏并发送确认消息给所述主叫端，所述主叫端接收到所述确认消息后，运行所述游戏。

12.根据权利要求11所述的在终端上实现在线实时游戏的装置，其特征在于，所述运行单元具体包括：

第一运行子单元，用于所述被叫端接收到所述请求后，根据自己的媒体处理能力修改所述请求中的游戏的初始参数，然后运行所述游戏，并发送包含修改后的游戏初始参数的确认消息给所述主叫端；

第二运行子单元，用于所述主叫端接收到所述确认消息后，修改相应的初始参数使双方的初始参数一致，然后运行所述游戏。

13.根据权利要求10所述的在终端上实现在线实时游戏的装置，其特征在于，所述装置还包括：

封装模块，用于所述双方互相发送游戏命令之前均按预先定义的数据格式封装游戏命令，所述预先定义的数据格式含有状态同步码和数据包序列号。

14.根据权利要求10所述的在终端上实现在线实时游戏的装置，其特征在于，所述装置还包括：

第一执行和确认模块，用于在所述双方互相发送游戏命令的过程中，所述主叫端接收到被叫端发来的游戏命令后立即执行，同时在所述主叫端保存该命令并发回给所述被叫端以示确认，所述被叫端接收到主叫端发回的确认命令后再执行该命令。

15.根据权利要求10或14所述的在终端上实现在线实时游戏的装置，其特征在于，所述装置还包括：

第二执行和确认模块，用于在所述双方互相发送游戏命令的过程中，所述被叫端接收到主叫端发来的游戏命令后立即执行，同时在所述被叫端保存该命令并发回给所述主叫端以示确认，所述主叫端接收到被叫端发回的确认命令后再执行该命令。

16.根据权利要求10所述的在终端上实现在线实时游戏的装置，其特征在于，所述发送模块具体包括：

映射单元，用于将多个游戏命令按固定的规则依次映射为二进制码；

连接单元，用于将所述映射后的多个二进制码按固定的次序连接成一个二进制码流；

发送单元，用于将所述二进制码流转换成字节序列后发送。

17.根据权利要求13所述的在终端上实现在线实时游戏的装置，其特征在于，所述发送模块还包括：

第一同步单元，用于所述主叫端接收到所述被叫端发来的封装了游戏命令和同步数据的数据包，将所述数据包中的状态同步码和所述主叫端接收到的上一个数据包中的状态同步码进行比较，如果二者相同，则不发起状态同步请求；如果二者相差的数值在设定的范围之内，则分析所述数据包中的游戏命令和同步数据，进行状态同步；如果不是上述两种情况，则丢弃所述数据包。

18.根据权利要求13或17所述的在终端上实现在线实时游戏的装置，其特征在于，所述发送模块还包括：

第二同步单元，用于所述主叫端根据两次发送数据包之间的时间间隔判断是否需要所述主叫端发起状态同步请求，如果是则所述主叫端向被叫端发起状态同步的请求，所述被叫端接收到所述请求后，进行状态同步；如果不是则所述主叫端将刚接收到的数据包中的数据包序列号与接收到的上一个合法数据包中的数据包序列号进行比较，如果二者的关系符合设定的条件，则所述主叫端不发起状态同步的请求，否则所述主叫端丢弃刚接收到的数据包。

Images