本发明涉及一种数据同步方法，尤其涉及一种地形可修改网络游戏的网络游戏地形数据同步方法。
背景技术：
现有的网络游戏中，客户端在登陆服务器之后，就会与服务器保持连接状态，并不断的与服务器进行数据上的交互，以获取服务器的最新数据。比如玩家的移动，玩家a在自己的客户端移动之后，玩家b要能在自己的客户端及时看到a的移动，大体的流程是a客户端需要先把移动数据上发到服务器，服务器进行验证后将移动数据通知其他客户端，这样b收到服务器的消息之后就能看到a的移动。
目前市面上大多数的网络游戏，地形数据都是无法改变的，因此同步的数据主要是与玩家有关的各种信息，比如上面提到的玩家移动，以及玩家的装备，玩家的等级属性等。这些数据会随着在线玩家数量的增加而不断增加，目前已经有了一些比较成熟的技术，例如cn102469123a（网络游戏数据同步的系统及方法），cn102571695a（一种数据同步方法和游戏服务器）等文献中所公开的技术。
目前市面上已经出现了少量地形可修改的网络游戏，对于此类地形可变的网络游戏，同步的数据不仅包括以上所说的玩家数据，还包括所有玩家修改的地形数据。也就是说，服务器与客户端之间同步的数据量，不仅与在线玩家的数量有关，而且还与服务器地形的修改量有关。如何判断哪些地形数据需要同步，如何最大化的减小地形数据的同步量，成为这类网络游戏中非常重要的一个问题。
技术实现要素：
本发明所要解决的技术问题在于克服现有技术不足，提供一种网络游戏地形数据同步方法，可用较少的资源消耗解决地形可变的网络游戏中的地形数据同步问题。
本发明采用以下技术方案解决上述技术问题：
网络游戏地形数据同步方法，所述网络游戏为地形可修改网络游戏，所述地形可修改网络游戏中的每个地形数据块chunk中均被赋予一个由服务器维护的时间戳；客户端在游戏过程中通过比较同一chunk在本地与在服务器端的时间戳是否一致来确定该chunk是否已被修改，并用从服务器端获取的修改后chunk及其时间戳更新本地chunk及其时间戳。
优选地，所述时间戳是以地形区域zone为单位进行保存。
优选地，所述方法具体包括以下步骤：
步骤1、客户端向服务器请求当前视野范围内所有zone的时间戳数据，并读取本地的这些zone的时间戳数据；
步骤2、客户端收到服务器下发的时间戳数据后，以chunk为单位比较服务器下发的时间戳和客户端本地的时间戳：如果一致，则客户端直接调用该chunk的本地数据，否则，向服务器请求该chunk的服务器端数据；
步骤3、客户端用收到的该chunk的服务器端数据覆盖该chunk的本地数据，并更新本地的对应zone的时间戳数据中该chunk的时间戳。
优选地，对于服务器下发的时间戳为初始值的chunk，客户端使用地形随机算法及随机种子生成该chunk的本地数据，所述地形随机算法及随机种子与服务器初始化时所使用的地形随机算法及随机种子相同。
优选地，所述网络游戏的地形为3d地形，每个zone由512个chunk构成。
根据相同的发明思路还可以得到以下技术方案：
网络游戏地形数据同步装置，所述网络游戏为地形可修改网络游戏，所述地形可修改网络游戏中的每个地形数据块chunk中均被赋予一个由服务器维护的时间戳；所述地形数据同步装置设置于客户端，其包括：
地形修改检测模块，用于在游戏过程中通过比较同一chunk在本地与在服务器端的时间戳是否一致来确定该chunk是否已被修改；
更新模块，用于用从服务器端获取的修改后chunk及其时间戳更新本地chunk及其时间戳。
优选地，所述时间戳是以地形区域zone为单位进行保存。
优选地，所述地形修改检测模块具体包括以下子模块：
时间戳获取子模块，用于向服务器请求当前视野范围内所有zone的时间戳数据，并读取本地的这些zone的时间戳数据；
时间戳比较子模块，用于在收到服务器下发的时间戳数据后，以chunk为单位比较服务器下发的时间戳和客户端本地的时间戳；
本地chunk调用子模块，用于根据时间戳比较子模块的比较结果，调用服务器下发的时间戳和客户端本地的时间戳相一致的chunk的本地数据；
服务器端chunk请求子模块，用于根据时间戳比较子模块的比较结果，向服务器请求服务器下发的时间戳和客户端本地的时间戳不一致的chunk的服务器端数据。
所述更新模块具体包括以下子模块：
chunk数据更新子模块，用于用收到的服务器下发的时间戳和客户端本地的时间戳不一致的chunk的服务器端数据覆盖该chunk的本地数据；
时间戳更新子模块，用于更新本地的对应zone的时间戳数据中chunk数据更新子模块所更新chunk的时间戳。
优选地，所述装置还包括：
chunk数据初始化模块，用于对服务器下发的时间戳为初始值的chunk，使用地形随机算法及随机种子生成该chunk的本地数据，所述地形随机算法及随机种子与服务器初始化时所使用的地形随机算法及随机种子相同。
优选地，所述网络游戏的地形为3d地形，每个zone由512个chunk构成。
一种网络游戏系统，所述网络游戏系统为地形可修改网络游戏系统，其包括一个服务器以及若干客户端，所述客户端设置有如上任一技术方案所述网络游戏地形数据同步装置；所述服务器包括用于对每个chunk的时间戳进行维护的时间戳维护模块。
相比现有技术，本发明具有以下有益效果：
本发明首次提出利用时间戳机制来解决地形可变的网络游戏中的地形数据同步问题，本发明技术方案可以准确的判断出哪些地形数据需要真正的同步，既保证了所有客户端看到的地形数据是与服务器保持一致的，同时极大的减少了在地形数据同步上对网络带宽的消耗，节省了游戏运营的成本。
附图说明
图1为实施例中的地形数据组织结构示意图。
具体实施方式
针对地形可变的网络游戏中的地形数据同步问题，本发明的思路是基于时间戳机制来快速准确识别出发生改变的地形数据，并仅对这部分改变的地形数据进行更新。
本发明所采用技术方案具体如下：
网络游戏地形数据同步方法，所述地形可修改网络游戏中的每个地形数据块chunk中均被赋予一个由服务器维护的时间戳；客户端在游戏过程中通过比较同一chunk在本地与在服务器端的时间戳是否一致来确定该chunk是否已被修改，并用从服务器端获取的修改后chunk及其时间戳更新本地chunk及其时间戳。
网络游戏地形数据同步装置，所述网络游戏为地形可修改网络游戏，所述地形可修改网络游戏中的每个地形数据块chunk中均被赋予一个由服务器维护的时间戳；所述地形数据同步装置设置于客户端，其包括：
地形修改检测模块，用于在游戏过程中通过比较同一chunk在本地与在服务器端的时间戳是否一致来确定该chunk是否已被修改；
更新模块，用于用从服务器端获取的修改后chunk及其时间戳更新本地chunk及其时间戳。
优选地，所述地形修改检测模块具体包括以下子模块：
时间戳获取子模块，用于向服务器请求当前视野范围内所有zone的时间戳数据，并读取本地的这些zone的时间戳数据；
时间戳比较子模块，用于在收到服务器下发的时间戳数据后，以chunk为单位比较服务器下发的时间戳和客户端本地的时间戳；
本地chunk调用子模块，用于根据时间戳比较子模块的比较结果，调用服务器下发的时间戳和客户端本地的时间戳相一致的chunk的本地数据；
服务器端chunk请求子模块，用于根据时间戳比较子模块的比较结果，向服务器请求服务器下发的时间戳和客户端本地的时间戳不一致的chunk的服务器端数据。
所述更新模块具体包括以下子模块：
chunk数据更新子模块，用于用收到的服务器下发的时间戳和客户端本地的时间戳不一致的chunk的服务器端数据覆盖该chunk的本地数据；
时间戳更新子模块，用于更新本地的对应zone的时间戳数据中chunk数据更新子模块所更新chunk的时间戳。
优选地，所述装置还包括：
chunk数据初始化模块，用于对服务器下发的时间戳为初始值的chunk，使用地形随机算法及随机种子生成该chunk的本地数据，所述地形随机算法及随机种子与服务器初始化时所使用的地形随机算法及随机种子相同。
在游戏地形中，某一个地形数据块被称为一个chunk，多个地形数据块的集合被称为一个zone（地形区域），本发明所使用的时间戳是以chunk为单位记录了当前chunk最后一次被修改的服务器系统时间。
优选地，时间戳在服务器和客户端都是以zone为单位保存的，也就是说，时间戳的保存与chunk数据的保存脱离。这样做的好处是：当仅仅想知道chunk的时间戳而不需要知道其地形数据时，没必要加载这个chunk的数据文件，只需要加载zone对应的时间戳文件即可，可以减少不必要的i/o操作。
时间戳都是由服务器进行设置和更新的，由于服务器的唯一性，因此对于某个chunk来说，其时间戳在某一时刻是唯一的。服务器第一次启动时，所有地形数据都为初始数据，因此所有chunk的时间戳都为0。当玩家发生了修改地形的行为时，服务器会更新这次修改所有涉及到的chunk的时间戳，设置为服务器的当前系统时间，并及时同步给所有在线玩家。
客户端在第一次登录服务器时，本地没有任何时间戳数据和地形数据，但是一旦收到了服务器的某个chunk数据，就会将数据保存在本地并记录时间戳。因此可以看到，随着游戏的不断进行，服务器的地形数据和时间戳永远都是最新的，但是对于某一个客户端而言，由于其不可能一直在线，而其离线的时候，其他玩家可能会修改服务器的地形并更新了时间戳，这样就导致客户端本地保存的地形数据和时间戳可能不是最新的，这时就需要进行地形数据的同步。优选地地形数据同步流程如下：
步骤1、客户端向服务器请求当前视野范围内所有zone的时间戳数据，并读取本地的这些zone的时间戳数据；
步骤2、客户端收到服务器下发的时间戳数据后，以chunk为单位比较服务器下发的时间戳和客户端本地的时间戳：如果一致，则客户端直接调用该chunk的本地数据，否则，向服务器请求该chunk的服务器端数据；
步骤3、客户端用收到的该chunk的服务器端数据覆盖该chunk的本地数据，并更新本地的对应zone的时间戳数据中该chunk的时间戳。
为了便于公众理解，下面以一个具体实施例并结合附图来对本发明的技术方案进行进一步详细说明。
游戏地形的数据组织结构，在3d空间中，沿xyz轴三个不同方向延伸，例如可以16米为单位可以划分成多个小立方体，每个小立方体被称为一个chunk。同理，以128米为单位可以划分成多个大立方体，每个大立方体被称为一个zone。由于zone的边长是chunk边长的8倍，因此在3d空间中，一个zone完全包含了83=512个chunk。
图1显示了类似的2d空间中的地形数据组织结构，下面我们基于此来详细阐述本发明的技术方案，3d空间以此类推。
服务器第一次启动时，图1所示zone的64个chunk对应的时间戳都为0，表示都是初始数据。
客户端a第一次登录服务器的流程：
步骤一、假设客户端a的视野范围就对应如图所示的一个zone，a会发消息向服务器请求这个zone的所有chunk时间戳。
步骤二、服务器下发所有chunk的时间戳。
步骤三、客户端a收到服务器的时间戳消息后进行比对，服务器因为都是初始数据，因此所有时间戳都是0，客户端因为是第一次登录，因此本地的所有时间戳也都是0（初始值），所有时间戳都一致，不需要进行chunk数据的同步，客户端直接调用随机算法初始化地形数据（服务器和客户端都调用同样的地形随机算法及随机种子，因此可以确保随机地形一致）。
步骤四、客户端a请求修改地形数据，涉及到chunk(0,0)和chunk(1,1)，并发消息给服务器。
步骤五、服务器收到客户端a的地形修改消息后，修改对应的chunk数据，并设置chunk(0,0)和chunk(1,1)的时间戳为服务器的当前系统时间，这里为了描述方便，假设为1，并下发给所有在线的客户端。
步骤六、客户端a收到服务器的地形修改消息后，不仅修改chunk数据，并且设置客户端本地chunk(0,0)和chunk(1,1)的时间戳为1，与服务器一致。
步骤七、客户端正常关闭，本地硬盘数据中会保存这两个已修改的chunk数据和对应的时间戳。
客户端b第一次登录服务器的流程：
步骤一到步骤二同客户端a第一次登录服务器的流程一致，不再赘述。
步骤三、客户端b收到服务器下发的时间戳消息后进行比对，服务器的chunk(0,0)和chunk(1,1)的时间戳为1，其他为0，而客户端本地的所有时间戳都为0，因此客户端需要向服务器请求这两个chunk的地形数据，而其他chunk的数据都可以直接调用地形随机算法获取。
步骤四、客户端b请求修改地形数据，仅涉及到chunk(1,1)，发消息给服务器。
步骤五、服务器收到消息后，修改chunk(1,1)的地形数据，并更新其时间戳，这里假设为2，然后下发客户端。
步骤六、客户端b收到服务器的消息后，修改chunk(1,1)的数据，并更新时间戳为2。
步骤七、客户端b正常关闭，chunk(0,0)的时间戳为1，chunk(1,1)的时间戳为2。
客户端a第二次登录服务器的流程：
步骤一到步骤二同客户端a第一次登录服务器的流程一致，不再赘述。
步骤三、客户端a收到服务器下发的时间戳消息后进行比对，服务器的chunk(0,0)时间戳为1，chunk(1,1)时间戳为2，而客户端本地这两个chunk的时间戳都为1，说明在客户端a离线的这段时间中，chunk(0,0)没有发生修改，直接读取本地数据即可，而chunk(1,1)发生了修改，本地数据已经失效，需要向服务器请求最新的数据。
步骤四、客户端a如果不修改地形数据，正常关闭后与服务器的数据保持一致。
客户端b第二次登录服务器的流程：
步骤一到步骤二同客户端a第一次登录服务器的流程一致，不再赘述。
步骤三、客户端b收到服务器下发的时间戳消息后进行比对，服务器的chunk(0,0)时间戳为1，chunk(1,1)时间戳为2，客户端本地这两个chunk的时间戳与服务器都一致，说明客户端b离线的这段时间中，服务器地形数据没有发生任何修改，不需要再向服务器请求，直接读取本地保存的地形数据即可。
步骤四、客户端b如果不修改地形数据，正常关闭后也不需要重新保存地形数据，因为启动时就已经与服务器保持一致了。
从上面的流程可以看出，本发明可以准确的判断出哪些地形数据块需要从服务器同步地形数据，避免不必要的同步。