策划需要了解的网游数据结构模板.docx

策划需要了解的网游数据结构10资料内容仅供参考，如有不当或者侵权，请联系本人改正或者删除。策划需要了解的网游数据结构( 一) 抽象的网络游戏架构网络游戏之因此叫做mmog, 是因为mmog必须得达到以下几个条件才能够进行游戏: 1. 玩家们的电脑必须得接通Internet; 2. 必须有网络服务端; 以上两个条件缺一不可。因此, 网络游戏的架构从概念上就分为了服务端和客户端。客户端指的就是玩家们电脑上安装的游戏程序; 而服务端则是游戏服务商所提供的数据同步、 共享的服务器; 网络游戏抽象结构: 由一个服务端和若干个客户端所组成。服务端从抽象来说, 我们能够理解为它只有一个, 它所做的服务就是给这无数客户端进行数据同步、 共享。l 客户端: 客户端往往是将很多的游戏资源储存起来的软件。这个软件具有象手机那样的接收、 发出数据信息的功能, 能够说, 客户端就是一个编译器, 将网络数据编译成游戏中能够看见的图像并将玩家的操作编译给服务端, 让服务端进行处理。编辑器配置数据和资源引擎客户端抽象结构注: 我们常说的开发套件各式编辑器, 就是对这些配置数据和资源进行编辑的工具软件。l 服务端: 服务端则是一个大型的智能化数据库, 同时有着游戏之中的大部分逻辑处理程序在内。服务端就像是龙与地下城的城主, 给客户端讲解着游戏该怎么玩, 该遵循什么样的规则。服务端抽象结构注: 以上是服务端的一个十分抽象、 整体化的结构, 在程序进行服务端架构时, 会将这个系统分割为若干块, 由不同的物理服务器来各司其责的进行管理。甚至有比较先进的动态服务器负载式管理, 例如我们耳闻能详的BigWorld的服务端系统。上面的网络游戏结构, 和我们往常所玩的单机游戏有很大的不同, 因为服务端和众多客户端之间多了很多的关系, 这种联系的媒介就是有网络通信的网线以及确定这根网线粗细的带宽。由于网络之间的通信毫无疑问会出现各种延迟现象, 因此, 在游戏之中, 你所看到的很多内容和所做的很多行为都需要数据同步。网络游戏数据同步网络游戏数据同步是非常底层的一块内容。似乎这一方面很多策划会觉得游戏策划不必去了解, 因为大家觉得可能这一块的架构和我们的游戏逻辑没有任何关系。我则觉得不应该如此。无论如何, 先让我们先来看看网络游戏数据同步的过程和方法, 再来考虑它是否对我们的设计有所影响。游戏里的一切参照以服务端为主首先我们要明确一个基本的概念, 就是游戏中的所有参照数据, 应该以服务端的数据作为参照。因为我们知道, 客户端的参照数据绝对是错误的, 主要是由于有网络延迟的状况出现。例如玩家确切的位置在哪里? 我们不能以客户端所见来判定, 而是必须以服务单的位置作为判定参照: 如上图。释放一个技能, 该技能释放的最大射程是20米, 这个时候, 在释放这个技能时, 先以客户端的自己和目标的距离作为参照, 看是否能够释放技能, 如果能够, 那么服务端依旧需要验证一次攻击目标和自己在服务端的距离是否能够满足该技能的最大射程。这是一种满足客户端玩家战斗手感的一种方式, 也是一种满足大家平衡的一种方式。一般, 客户端在表现这种情况时, 会让你开始释放技能( 做念咒) 的动作, 等服务端验证信息返回之后, 就会告诉你距离不够或者是满足射程, 如果距离不够, 则打断法术释放, 如果满足则释放成功。如果网络延时, 你会一直在念咒动作中停止, 相信我们在玩魔兽世界的时候就有这种体验。因此, 我们能够发现, 网络游戏数据同步的过程对游戏操作手感、 战斗合理性和流畅性的影响有多大了。因此, 服务端会拥有很多的临时数据需要同步, 这些需要同步的数据大部分是针对单个玩家作为对象进行同步的。需要同步的数据需要同步的数据有很多很多, 例如玩家周围其它玩家/NPC的位置, 自己的行为信息( 战斗行为、 其它行为) , 其它玩家的HP、 MP信息, 其它玩家的行为信息( 例如周围的玩家在战斗等) , 服务端的触发器的Action等; 区域的同步区域的同步主要是让各个玩家对象, 看见她身边所发生的事情。一般这个同步的过程是以玩家作为中心点, 来进行同步处理。不过一般玩家周围的一大片区域之中, 有些数据玩家会更为在意, 而有些数据呢, 玩家并不会在意。例如我更关心的是我周围目标的位置是否准确, 而并不担心远处目标的位置的准确程度, 因为她们对我的影响并不大。我们能够用屏数或其它各式为单位来分割需要同步给玩家的数据, 如下图: 0.1s0.5s1s上图每个格子就是屏单位大小, 中心的1屏是玩家所处的位置。中心1屏的情况应该是玩家最需要了解到的, 因此, 这部分数据需要服务端以最少的数据同步间隔来发送给玩家。即每隔0.1s同步一次数据; 而颜色稍浅的外围8屏的情况, 则对玩家影响会有所下降, 因此, 我们能够每隔0.5s同步一次数据; 而颜色最浅的最外围, 则对玩家影响几乎微乎其微, 因此同步的间隔会更长, 甚至1s同步一次。组织的同步除了区域的同步有权重以外, 玩家还有一些权重比较高的数据需要同步, 例如属于同一队伍的队友的数据, 我们也需要更准确的了解她们的状况。另外还有游戏里的其它组织, 例如师徒、 夫妻、 公会等。事件的同步例如玩家进行一些操作, 查看对方身上的装备, 需要获取对方的装备数据。这些可能是即时数据同步, 而且一般需要的同步的过程也尽量需要是即时的。这种数据同步的特性是: 数据同步队列( 信息发送器) 由于同步的方式有很多, 我前面罗列出来的方式只是常见的两种, 因此数据同步可能需要队列的产生。我们能够以同步数据的间隔时间来划分这些队列: 0.1s同步队列; 0.5s同步队列; 1s同步队列。由于队列的同步间隔时间各有不同, 因此队列能够过分饱和导致一次同步的数据也常有出现, 因此我们可能需要限制这些队列的数据量的大小。可是这样一来, 则会有一些数据被排除在外, 而且数据信息设置是对玩家至关重要的, 我们该怎么办呢? 我们能够给每条数据信息设置权重, 除了权重之外, 还有先来后到的权重。这样尽管会遗漏一部分信息, 好在这些信息对玩家来说并不是至关重要的, 因此, 玩家应该不会十分在意这种小问题。网络同步对游戏性的影响由于之前我们已经提到, 游戏里的一切参照必须以服务端的为准, 而玩家看到的都是过去式( 由于网络延迟) , 因此, 我们需要考虑的是, 哪些是玩家需要更快知道的过去式, 哪些是玩家能够晚些知道的过去式。这些过去式得罗列出一个权重, 因为我们不能让所有的数据都是更快知道的过去式, 那样做的话会对服务端的带宽造成影响, 使得服务端能够同时承载的玩家数量大幅度减少, 这一点是运营商不希望看到的, 也是我们不愿意看到的。因此关于数据同步的规划在服务端架构前期是一件十分重要的事情。