日志正文
|
||
网络游戏数据同步 网络游戏数据同步是非常底层的一块内容。似乎这一方面很多策划会觉得游戏策划不必去了解,因为大家觉得可能这一块的架构和我们的游戏逻辑没有任何关系。我则觉得不应该如此。无论如何,先让我们先来看看网络游戏数据同步的过程和方法,再来考虑它是否对我们的设计有所影响。 游戏里的一切参照以服务端为主 首先我们要明确一个基本的概念,就是游戏中的所有参照数据,应该以服务端的数据作为参照。因为我们知道,客户端的参照数据绝对是错误的,主要是由于有网络延迟的状况出现。 例如玩家确切的位置在哪里?我们不能以客户端所见来判定,而是必须以服务单的位置作为判定参照: 如上图。释放一个技能,该技能释放的最大射程是20米,这个时候,在释放这个技能时,先以客户端的自己和目标的距离作为参照,看是否能够释放技能,如果可以,那么服务端依旧需要验证一次攻击目标和自己在服务端的距离是否能够满足该技能的最大射程。这是一种满足客户端玩家战斗手感的一种方式,也是一种满足大家平衡的一种方式。通常,客户端在表现这种情况时,会让你开始释放技能(做念咒)的动作,等服务端验证信息返回之后,就会告诉你距离不够或者是满足射程,如果距离不够,则打断法术释放,如果满足则释放成功。如果网络延时,你会一直在念咒动作中停止,相信我们在玩《魔兽世界》的时候就有这种体验。因此,我们可以发现,网络游戏数据同步的过程对游戏操作手感、战斗合理性和流畅性的影响有多大了。 因此,服务端会拥有很多的临时数据需要同步,这些需要同步的数据大部分是针对单个玩家作为对象进行同步的。 需要同步的数据 需要同步的数据有很多很多,例如玩家周围其他玩家/NPC的位置,自己的行为信息(战斗行为、其他行为),其他玩家的HP、MP信息,其他玩家的行为信息(例如周围的玩家在战斗等),服务端的触发器的Action等; 区域的同步 区域的同步主要是让各个玩家对象,看见他身边所发生的事情。通常这个同步的过程是以玩家作为中心点,来进行同步处理。 不过通常玩家周围的一大片区域之中,有些数据玩家会更为在意,而有些数据呢,玩家并不会在意。例如我更关心的是我周围目标的位置是否准确,而并不担心远处目标的位置的准确程度,因为他们对我的影响并不大。 我们可以用屏数或其他各式为单位来分割需要同步给玩家的数据,如下图: 上图每个格子就是屏单位大小,中心的1屏是玩家所处的位置。 中心1屏的情况应该是玩家最需要了解到的,因此,这部分数据需要服务端以最少的数据同步间隔来发送给玩家。即每隔0.1s同步一次数据; 而颜色稍浅的外围8屏的情况,则对玩家影响会有所下降,因此,我们可以每隔0.5s同步一次数据; 而颜色最浅的最外围,则对玩家影响几乎微乎其微,因此同步的间隔会更长,甚至1s同步一次。 组织的同步 除了区域的同步有权重以外,玩家还有一些权重比较高的数据需要同步,例如属于同一队伍的队友的数据,我们也需要更准确的了解他们的状况。 另外还有游戏里的其他组织,例如师徒、夫妻、公会等。 事件的同步 例如玩家进行一些操作,查看对方身上的装备,需要获取对方的装备数据。这些可能是即时数据同步,而且通常需要的同步的过程也尽量需要是即时的。这种数据同步的特性是: 数据同步队列(信息发送队列) 由于同步的方式有很多,我前面罗列出来的方式只是常见的两种,因此数据同步可能需要队列的产生。我们可以以同步数据的间隔时间来划分这些队列: 0.1s同步队列;0.5s同步队列;1s同步队列。 由于队列的同步间隔时间各有不同,因此队列可以过分饱和导致一次同步的数据也常有出现,因此我们可能需要限制这些队列的数据量的大小。 但是这样一来,则会有一些数据被排除在外,而且数据信息设置是对玩家至关重要的,我们该怎么办呢? 我们可以给每条数据信息设置权重,除了权重之外,还有先来后到的权重。这样尽管会遗漏一部分信息,好在这些信息对玩家来说并不是至关重要的,因此,玩家应该不会十分在意这种小问题。 网络同步对游戏性的影响 由于之前我们已经提到,游戏里的一切参照必须以服务端的为准,而玩家看到的都是过去式(由于网络延迟),因此,我们需要考虑的是,哪些是玩家需要更快知道的过去式,哪些是玩家可以晚些知道的过去式。这些过去式得罗列出一个权重,因为我们不能让所有的数据都是更快知道的过去式,那样做的话会对服务端的带宽造成影响,使得服务端能够同时承载的玩家数量大幅度减少,这一点是运营商不希望看到的,也是我们不愿意看到的。因此关于数据同步的规划在服务端架构前期是一件十分重要的事情。
阅读(?)评论(0)
|
||
评论 想第一时间抢沙发么?