本发明涉及游戏技术领域，尤其涉及一种针对多用户场景的游戏交互方法及系统。
背景技术：
目前，多用户场景下的游戏交互，通常采用权威服务器结构实现。这种传统的方式，一般使用典型的c/s架构：游戏逻辑在服务器计算，客户端只实现游戏表现。服务器把游戏对象的属性表格数据以及效果表现命令发送给客户端，由客户端根据这些数据，呈现游戏世界。
然而，随着用户数量（即客户端数量）的膨胀，服务器的数据运算量以及同步量急剧上升，cpu消耗较大，无法支持大量游戏单位的实时交互。比如即时策略类型游戏，当大量战斗单位在可视区域内交互时，传统游戏服务器的网络同步压力，已经超过了可接受的设计上限。
传统的多用户场景游戏交互方式下，为了降低同步量以及网络消耗，通常只能降低数据同步的频度与粒度。这样会导致玩家对于游戏世界的模拟表现失真，比如玩家位置模拟偏差，游戏技能打偏等。这些都严重影响用户体验。为提升用户体验，现有的国产武侠游戏，刀光特效通常需要设计在1米以上，实际攻击监测距离需要设计在2米以上。这样做就是为了克服现有服务器负载水平导致的同步粒度偏差：当客户端表现玩家距离很近，但实际距离很远时，也需要保证攻击命中。
为了提高服务器负载，现有技术往往只能降低游戏世界的模拟精度。这样服务器对游戏世界的模拟，只能基于行走图、高度图等抽象数据，无法基于实际3d场景，游戏交互体验会比较差。如果需要服务器进行3d场景的模拟(如ue4等商业引擎)，则服务器的消耗将急剧增加，服务器负载能力将降低到游戏可商业化的临界值。
综上所述，传统的游戏服务器，在实现针对多用户场景的游戏交互时，在网络、cpu消耗与用户承载、用户体验上，均存在巨大的、无法解决的矛盾。要求服务器承载高，网络消耗要低，则必然导致用户体验的恶化;而改善用户体验，则必然导致游戏运营阶段的成本增高。
技术实现要素：
为了解决现有技术存在的不足，本发明的目的在于提供一种基于对等计算的针对多用户场景的游戏交互方法及系统。通过基于对等计算的游戏架构，实现高精度，高负载，多用户实时交互的系统。
首先，为实现上述目的，提出一种针对多用户场景的游戏交互方法，包括以下步骤：
第一步，各用户端进入游戏时分别获取相同的游戏数据；
第二步，所述各用户端分别按照所述游戏数据独立运行相同的游戏世界，接收并响应用户操作；
第三步，所述各用户端每完成对用户操作的响应后，打包该用户操作产生的控制命令至服务器端；
第四步，所述服务器端接收所述各用户端上传的控制指令，向所述各用户端广播所述控制指令；
第五步，所述各用户端接收所述广播，分别同步响应广播的所述控制指令，重复上述步骤直至游戏结束。
进一步，上述方法中，所述第四步中，所述服务器端接收所述各用户端上传的控制指令时，还包括对比所述各用户端上传的控制指令的步骤；
所述第五步中，所述各用户端还在比对出所述控制指令不一致时，结束游戏并输出游戏数据的比对记录。
再进一步，上述方法中，所述第四步中，所述服务器端接收并对比所述各用户端上传的控制指令后，还按照时间顺序将多个所述控制指令打包生成一个游戏命令，以固定周期，向所述各用户端广播所述游戏命令。
进一步，上述方法中，所述第四步中，所述服务器端接收并对比所述各用户端上传的游戏数据后，还包括保存所述控制指令或所述游戏命令的操作；
当所述用户端中途加入游戏、或掉线后重新接入游戏、或重启进入游戏后，通过所述第一步获取所述游戏数据时，所述服务器端根据其保存的所述控制指令或游戏命令，向要求进入所述游戏的用户端反馈相应的游戏数据。
进一步，上述方法中，所述第四步中保存的所述控制指令或所述游戏命令还用于生成游戏录像；
生成游戏录像的步骤包括：
步骤a1，所述服务器端筛选所述控制指令或游戏命令，将筛选出的各用户端的控制指令按照时序生成有效游戏命令序列；
步骤a2，将所述有效游戏命令序列压缩并打包，生成游戏录像。
进一步，上述方法中，所述游戏录像按照如下步骤播放：
步骤b1，所述用户端向所述服务器端请求所述游戏录像；
步骤b2，所述服务器端将所述游戏录像实时发送至所述用户端；
步骤b3，所述用户端顺序接收所述游戏录像，并按时序响应所述游戏录像中的所述有效游戏命令。
其次，为实现上述目的，还提出一种针对多用户场景的游戏交互系统，包括用户端和服务器端，所述用户端与服务器端之间通信连接，其特征在于：
所述用户端包括完整的游戏世界；所述用户端用于接收所述服务器广播的游戏数据，接收并响应用户操作后，打包并向所述服务器上传该用户操作产生的控制指令，所述用户端按照所述游戏数据和所述控制指令运行所述游戏世界；
所述服务器端包括相互连接的存储模块与广播模块；所述存储模块用于存储各用户端上传的所述控制指令；所述广播模块用于读取所述存储模块内的控制指令并向所述各用户端广播所述控制指令。
进一步，上述的系统中，所述游戏世界包括通过mvc模式相互独立的游戏逻辑模块与用户表现模块；所述游戏逻辑模块与所述用户表现模块之间通过控制命令接口连接；
各用户端的所述游戏逻辑模块均完全一致；所述游戏逻辑模块用于通过所述控制命令接口接收所述用户表现模块发送的用户的控制指令，响应所述控制指令，并将响应结果是数据反馈至所述用户表现模块；
不同用户端的所述用户表现模块配适有不同版本；所述用户表现模块用于接收用户的控制指令并通过所述控制命令接口向所述游戏逻辑模块发送所述控制命令，读取所述游戏逻辑模块的反馈的数据进行游戏场景呈现。
进一步，上述系统中，所述游戏逻辑模块内，采用统一的逻辑驱动点响应所述控制命令；响应所述控制命令过程中，采用统一的运算调用方式，采用定点数模拟浮点数运算，且采用跨平台的定点数数学库执行浮点数相关运算。
有益效果
本发明，基于对等计算技术，将用户操作过程中产生的游戏数据上传至服务器，再由服务器进行游戏数据的广播，各用户端接收所述服务器广播的游戏数据同时接收用户的控制指令，从而按照所述游戏数据和所述控制指令分别同步运行完整的游戏世界，实现各用户端之间的交互及同步。由于本发明的服务器端仅进行游戏数据的存储与广播，因此，即使在多用户场景下，本发明所提供的对等计算技术也不会对网络、cpu消耗带来更高要求，可大大用户承载水平。
进一步，由于本发明的服务器端可获得全部用户端的控制指令，因此，通过比对，可及时发现控制指令的不一致，并进行相应的处理，防止用户通过外挂等方式在游戏中作弊。同时，服务器端还可将其获取的控制指令存储，并按照时序生成有效游戏命令序列用于游戏录像的生成。相对于现有的游戏录像压缩技术，由于本发明游游戏录像仅需相应游戏数据即可通过游戏世界进行还原，而无需考虑图像本身，因此本发明所生成的游戏录像数据量小，压缩效率更高。
进一步，考虑到用户体验和系统的稳定性，本发明将用户体验交由各用户端内相对独立的用户表现模块实现，同时保证各用户端的游戏逻辑模块均完全一致，以实现游戏世界的统一。本发明利用用户表现模块，根据用户选择，配适不同版本，利用用户表现模块根据统一的游戏逻辑模块反馈的数据进行游戏场景的具体呈现。因而，在用户进行3d场景游戏时，本发明无需像现有系统一样，将全部3d效果的渲染呈现交由服务器完成，而是直接在用户端实现。因此，本发明能够在改善用户体验的同时，降低对服务器承载能力的要求，从而进一步降低游戏运营阶段的成本。
本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。
附图说明
附图用来提供对本发明的进一步理解，并且构成说明书的一部分，并与本发明的实施例一起，用于解释本发明，并不构成对本发明的限制。在附图中：
图1为根据本发明的针对多用户场景的游戏交互方法的流程图；
图2为根据本发明的针对多用户场景的游戏交互系统的框图；
图3为根据本发明的游戏世界架构示意图；
图4为根据本发明的游戏数据流程示意图；
图5为根据本发明的一致性检测过程示意图。
具体实施方式
以下结合附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。
首先，本发明所提供的游戏架构是一种基于一致性输入的对等计算。所有参与计算的对等端（包括各个用户端），均保持一致的开始，一致的变化过程，最终会有一致的结果。
通过该游戏架构，实现多用户场景的游戏交互，其具体步骤参考图1所示的本发明的多用户场景的游戏交互方法，包括以下步骤：
第一步，一致的开始:各用户端进入游戏时分别获取相同的游戏数据；
第二步，所述各用户端分别按照所述游戏数据独立运行相同的游戏世界，接收并响应用户操作；
由此，本发明所提供的游戏世界可容纳多个玩家，多个阵营。每个玩家，均独立运行整个游戏世界，其游戏世界所对应的游戏逻辑相关的所有数据（包括，游戏初始化的数据，玩家数据，场景配置，npc配置，技能配置等）及程序逻辑模块（即编译执行的二进制代码）均完全一致；
第三步，一致的变化过程：所述各用户端每完成对用户操作的响应后，打包该用户操作产生的控制命令至服务器端；（本发明中，控制命令是玩家对游戏的操作，产生的控制命令，比如，移动，使用技能；游戏命令是指，把1个或多个控制命令组装到某个游戏帧，产生的游戏执行所使用的命令。第一步的数据，是游戏启动时候的初始化数据，如游戏场景，玩家，各种参数配置。第三步中的数据，即控制指令，是玩家有游戏过程中，玩家操作所产生的游戏控制命令。）
第四步，所述服务器端接收所述各用户端上传的控制指令，向所述各用户端广播所述控制指令；
第五步，所述各用户端接收所述广播，分别同步响应广播的所述控制指令，重复上述步骤直至游戏结束；
由此，游戏中的逻辑驱动流程（即游戏逻辑执行流程）完全一致，游戏中逻辑数据变化完全一致。每个参与游戏的玩家，都通过其特定的阵营窗口（针对某个阵营玩家，游戏内通过阵营串口看到游戏内容，进行相应的游戏操作和交互），对游戏世界进行的观察及操作。游戏世界，所有人都一致，区别仅在于游戏窗口的表现方式不同。
上述的游戏交互方法所对应的游戏该架构参考图3。在该架构下，游戏的服务器端，只负责接收游戏操作命令队列并进行广播。服务器端不执行具体的游戏场景，因此cpu消耗低，承载能力非常高。游戏中，由用户端运行整个游戏世界，服务器端只同步用户操作，因此同步的数据量非常低，但可依托对等计算，实现多玩家高精度，实时同步游戏。因此，应用本方法，游戏场景内活动单位数量，可不受网络同步限制，可视范围内活动对象数量可以达到cpu承载上限值，且游戏的操作反馈和体验均非常好。整个游戏系统的承载能力，不会因为游戏复杂度的提高，玩家操作精度、频度的提高，而出现明显下降。
进一步，上述方法中，所述第四步中，所述服务器端接收所述各用户端上传的控制指令时，还包括对比所述各用户端上传的控制指令的步骤；
所述第五步中，所述各用户端还在比对出所述控制指令不一致时，结束游戏并输出游戏数据的比对记录。
再进一步，上述方法中，所述第四步中，所述服务器端接收并对比所述各用户端上传的控制指令后，还按照时间顺序将固定周期内的第1至第n个所述控制指令打包生成一个游戏命令，以固定周期（即，在该周期结束时），向所述各用户端广播所述游戏命令。
进一步，上述方法中，所述第四步中，所述服务器端接收并对比所述各用户端上传的控制指令后，还包括保存所述控制指令或所述游戏命令的操作；
当所述用户端中途加入游戏、或掉线后重新接入游戏、或重启进入游戏后，通过所述第一步获取所述游戏数据时，所述服务器端根据其保存的所述控制指令或游戏命令，向要求进入所述游戏的用户端反馈相应的游戏数据。
进一步，上述方法中，所述第四步中保存的所述控制指令或所述游戏命令还用于生成游戏录像；
生成游戏录像的步骤包括：
步骤a1，所述服务器端筛选所述控制指令或游戏命令，将筛选出的各用户端的控制指令按照时序生成有效游戏命令序列；
步骤a2，将所述有效游戏命令序列压缩并打包，生成游戏录像。
进一步，上述方法中，所述游戏录像按照如下步骤播放：
步骤b1，所述用户端向所述服务器端请求所述游戏录像；
步骤b2，所述服务器端将所述游戏录像实时发送至所述用户端；
步骤b3，所述用户端顺序接收所述游戏录像，并按时序响应所述游戏录像中的所述有效游戏命令。
其次，参考图2，为实现上述目的，还提出一种针对多用户场景的游戏交互系统，包括用户端和服务器端，所述用户端与服务器端之间通信连接，其特征在于：
所述用户端包括完整的游戏世界；所述用户端用于接收所述服务器广播的游戏数据，接收并响应用户操作后，打包并向所述服务器上传该用户操作产生的控制指令（即上传玩家操作的控制命令，只含有该命令相关参数。如移动，使用技能等），所述用户端按照所述游戏数据和所述控制指令运行所述游戏世界；
所述服务器端包括相互连接的存储模块与广播模块；所述存储模块用于存储各用户端上传的所述控制指令；所述广播模块用于读取所述存储模块内的控制指令并向所述各用户端广播所述控制指令。
进一步，上述的系统中，在设计上，我们可以把游戏拆分为逻辑部分及表现部分：即，通过mvc方式设计相互独立的游戏逻辑模块与用户表现模块；通过控制命令接口连接所述游戏逻辑模块与所述用户表现模块；
各用户端的所述游戏逻辑模块均完全一致；所述游戏逻辑模块实现游戏逻辑部分，即游戏世界中，真实对游戏发展会产生影响的游戏客户端逻辑。该模块用于通过所述控制命令接口接收所述用户表现模块发送的用户的控制指令，响应所述控制指令，并将响应结果是数据反馈至所述用户表现模块；
不同用户端的所述用户表现模块配适有不同版本；所述用户表现模块实现游戏表现相关部分，即游戏世界中，呈现给玩家的游戏客户端表现。用于接收用户的控制指令并通过所述控制命令接口向所述游戏逻辑模块发送所述控制命令，读取所述游戏逻辑模块的反馈的数据进行游戏场景呈现。
这里强制加入逻辑、表现概念，是希望让开发者，在进行开发设计时，把这两个作为独立部分进行处理。在编码上，甚至可以把它们放在两个独立工程下。逻辑部分，表示完整的游戏本身，在校验服务器进行逻辑后校验时，也只会执行逻辑模块相关内容。客户端表现部分，会只读使用逻辑的数据，并通过一个特殊接口发送用户操作所对应的控制命令给游戏逻辑。由此在相同的游戏逻辑基础上，客户端表现可以是2d,也可以是3d，在实际开发中可以进行相关适配。
在实际工程实践中，实现上述的系统，需要我们要重点解决以下问题:如何确保我们开发的逻辑在所有对等端都有一致的开始及一致的变化。如果发生了不一致，我们如何能检测到。因此，我们需要一个框架来帮助我们解决这些问题，我们先把这个框架命名为游戏核心。由此，在上述系统中，所述游戏逻辑模块内，设计统一的逻辑驱动点响应所述控制命令；响应所述控制命令过程中，采用统一的运算调用方式，采用定点数模拟浮点数运算，且采用跨平台的定点数数学库执行浮点数相关运算。
其具体实现过程包括：
游戏一致的开始:游戏框架逻辑部分，在所有对等端中，根据一致的初始化参数，进行一致的初始化构造，如场景，对象，逻辑模块等。如此游戏会有一致的开始。
游戏数据变化一致性:游戏数据类型，包括int,bool,float,string。其中int，bool,string运算不会有一致性问题。对于需要确定性的数据运算，浮点数是一个问题。在不同的cpu架构，不同编译器版本，在乘法，除法，精度控制上，都可能具有一定程度的不一致。虽然理论上，只要编译器及处理器都遵循ieee754标准，就能够确保浮点数的一致性。但在手游环境下，芯片种类繁多，执行的标准，尤其是对浮点数运算器的优化，都有一定的差异。因此要确保浮点数运算结果的完全一致，就算强制调用类似_controlfp(_pc_24,_mcw_pc);_controlfp(_rc_near,_mcw_rc);代码，也不一定有效果。因此，我们不直接使用浮点数，我们使用定点数模拟浮点数（参与运算的数的小数点位置固定不变），通过类似公司引擎内或开源数学库内完整实现的定点数运算器进行伪浮点数运算。这样我们就能够达到数据运算的一致性。
另外浮点数相关的函数库，也是一个问题。数学库，如cos,sin等，甚至浮点数fmod运算，都需要自己实现一套，与环境及编译器无关的实例(可参照跨平台开源数学库)。另外开方等高阶数学计算，因为存在cpu及数学库的依赖性，我们也需要自己手动实现相关函数，并保证结果的一致性,如卡马克在quake3中的快速开平方等。目前，开源项目内通常均包含有大量定点数数学库的实现方式，在此，本实施例不加以赘述。
其他关于数据运算，如随机函数等，也需要使用游戏核心提供的伪随机数接口，以保持一致性。
游戏逻辑驱动一致性：游戏驱动，必须完全由游戏核心框架完成。游戏控制命令的同步细节由框架全部隐藏，在用户接口层，完全不体现关于控制命令的同步细节，开发者只关注通用意义上的驱动点。在结构设计上，框架把游戏逻辑实体分为游戏对象,游戏模块。游戏对象包含所有数据，游戏模块负责逻辑执行。本框架提供的逻辑驱动点，只会包含：控制命令回调，心跳回调，事件回调，属性变化回调。控制命令回调是引擎针对命令模式的一种封装。逻辑通过引擎接口，发送控制命令，有注册关注该命令的处理逻辑会收到控制命令，并执行处理。心跳回调是引擎提供的心跳驱动的回调节点，在心跳到来时，引擎通知相关逻辑处理心跳回调。事件回调，是引擎的内部事件，如对象创建等，逻辑可以注册关注各种引擎事件，在事件发生时，引擎通知逻辑进行处理。属性变化回调是引擎在对象属性发生变化时，通知关注了该属性变更的模块，进行属性变更处理。
其通常的执行流程如下，框架执行某一个游戏命令，游戏命令包含两个部分，时间及玩家控制命令。框架会投递玩家控制命令进行执行，然后内部心跳管理器进行心跳更新。心跳更新时，所有注册的心跳被驱动，在心跳执行逻辑时，可以通过发送command执行各种定制行为；当有游戏对象属性或表格数据发生变更时，也发送属性变更事件，并执行相关逻辑。
为了保证执行过程的一致性，框架只是第一步。我们还需要确保游戏逻辑调用是一致的，即采用统一的运算调用方式。这里关注几个常见项:排序算法是稳定一致的，容器遍历顺序是一致的。
以上我们大致讲解了如何保持对等计算游戏的一致性。但是对于对等计算开发，哪怕开发团队很有经验，也很难避免出现因为人为疏忽，或者经验原因，导致的游戏不一致。此时我们需要一种手段能在最短时间，以最小代价，通过可重现的方式，自动化的帮助我们找到不一致点。对等计算一致性检测,能帮助解决该问题。
我们希望能直接锁定发生不一致的游戏执行点，并且精确锁定哪些游戏对象的哪些属性发生了不一致，该游戏执行在哪个调用流程发生了不一致。而且最关键的，我们希望能通过程序，直接调试该不一致发生的过程。满足以上特性的框架，能把对等计算开发最大的挑战，有效解决掉。
这个是能做到的么，当然可以。这里给出我们的解决方案：
游戏对象类体系结构由框架维护，即游戏对象的所有类型，属性，表格定义，由框架维护。框架给出类似get/set接口，对某一个对象的命名属性进行操作。通过引擎层，封装igameobject接口，并把所有关于gameobject的操作，通过命名方式进行。这样引擎可以进行属性修改事件的获取，并把相关事件投递给逻辑模块处理。整个游戏的运行，由框架驱动并检测。框架在每一组游戏命令执行完成后，抓取游戏内所有游戏对象的数据，以及本次游戏运行驱动流程数据，打包上传到游戏同步服务器。游戏同步服务器在收集到所有玩家提交的游戏数据后，对数据进行比对，分别比对所有游戏对象的属性及表格，并比对所有的事件驱动流。如果发生不一致，则通知玩家端，不一致发生的完整数据信息(该异常相关所有数据)。玩家端收集完异常数据后，游戏结束，并输出游戏录像，同时输出异常比对文档。文档中打印出游戏内所有游戏对象的数据及游戏运行流程数据，并标注清楚相同及不同标记，参照图4。
在项目测试阶段，使用pc模拟端，ios设备，android设备，运行自动匹配战斗脚本。当有不一致发生后，使用每帧采集的游戏世界对象数据，整合对比后输出游戏录像以及不一致信息，自动输出录像及异常信息文档。测试完成后，把相关的录像及文档发给项目组，项目组可以安排人员进行问题调查及重现，对复杂问题，也能通过异常录像直接调试。
该系统，配合之前描述的多用户游戏交互方法，很容易实现对等计算游戏框架的其他关键要素:游戏同步结构，游戏重入新，游戏录像，游戏观战，游戏反外挂。
游戏同步结构。参照图3及图5。我们采用乐观同步锁定方式。玩家操作，会以操作命令形式，发送给游戏同步服务器，服务器会把操作命令插入某一个游戏命令（即一组命令的集合，包含多条玩家操作命令。），然后在合适的时机把游戏命令广播给所有玩家，游戏世界一致执行。在这个结构上，游戏同步服务器，是以固定间隔把游戏命令进行广播，某一个玩家卡住或者挂了，对于其他玩家是完全不可见，也是无影响的。
游戏重入性。游戏断线重连及客户端重启后游戏恢复，都是依靠游戏同步服务器来保证的。在服务器上，保存游戏开始到当前的所有游戏命令。这样断线重连就很简单了，客户端在网络断开恢复链接后，请求服务器重新发送从第x开始的游戏命令。服务器收到请求后，发送从x到最新的游戏命令到客户端，客户端快速运行完成这些游戏命令，然后游戏继续执行。客户端重启也类似，客户端重启后，服务器通知客户端正在游戏中，客户端开始加载游戏，并请求载入游戏命令，服务器发送所有游戏命令，客户端快速执行到最新状态，游戏就可以继续执行了。游戏旁观，玩家中途加入，也采用类似方法。
游戏录像功能，是对等计算的天赋属性，因为游戏基于一致性的演算，所以通过保存游戏命令，就能作为游戏录像。唯一需要关注的，是录像压缩。我们在录像中，只记录存在有效游戏命令的数据（通常，即，游戏中玩家的操作命令）。然后把该录像序列化（serialization，即，将对象的状态信息转换为可以存储或传输的形式），再通过类似zip等压缩方式，做整体打包。通过以上方法，类似皇室战争复杂度的游戏，一场战斗，处理过的录像大小，基本能控制在1k字节以内。
游戏观战。玩家链接游戏同步服务器，同步服务器把实时游戏录像发送给客户端。客户端根据游戏实时录像，进行游戏播放。
游戏反外挂。对等计算结构中，所有数据都在玩家本地，理论上玩家可以任意修改这些数据。这里不讨论传统的加壳及反调试技术。这里讨论在实际开发中，对等计算框架能够通过什么方法来解决该问题。框架能提供至少3种保护:1.关键数据保护，2.虚拟化,3.服务器后验证。关键数据保护可以有很多种类，框架对核心数据，可以做内存加密，内存多拷贝冗余保护等。框架提供虚拟化技术，也是一个不错的选择，部分代码可以在虚拟机(比如lua)中直接执行，破解难度会增加。服务器后验证是杀手锏，验证服务器能运行游戏录像，并直接得出游戏战斗结果，任何作弊都无所遁形。因此对于对等计算，反外挂是一件相对比较容易的事情。游戏过程中，玩家作弊只会影响到自己，不会影响到他人。游戏结算时，当服务器检测到玩家之间游戏结果，因玩家中的某位作弊，导致游戏世界与其他非作弊玩家不一致时，通过验证服务器，对游戏录像进行验证计算，很容易就能发现是哪个玩家发生了作弊。
本发明技术方案的优点主要体现在：将用户操作过程中产生的控制指令上传至服务器，再由服务器进行控制指令的广播，各用户端接收所述服务器广播的控制指令同时接收自身用户的控制指令，从而按照所述控制指令分别同步运行完整的游戏世界，实现各用户端之间的交互及同步。由于本发明的服务器端仅进行数据的存储与广播，因此，即使在多用户场景下，本发明所提供的对等计算技术也不会对网络、cpu消耗带来更高要求，可大大用户承载水平。而且，由于将用户体验交由各用户端内相对独立的用户表现模块实现，本发明能够在改善用户体验的同时，降低对服务器承载能力的要求，从而降低游戏运营阶段的成本。还可利用服务器内接受的游戏数据实现反外挂、游戏录像和游戏重入等操作，进一步提高游戏处理效率和用户体验。
本领域普通技术人员可以理解：以上所述仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。