游戏编号规则——从NPC编号谈起
先宣传一下个人博客 希望行内行外对策划感兴趣的朋友都多光临指教 http://blog.sina.com.cn/u/1224467617
※※※※※※※※※※※※※※※ 分界线 ※※※※※※※※※※※※※※※※※※※ 以下正文 ※※※※※※※※※※※※※※※ 分界线 ※※※※※※※※※※※※※※※※※※※
做过执行策划的朋友应该至少对网游元素的编号有概念上的了解了,网游由各种各样的元素组成,其中有我们所熟悉的NPC、任务、物品、怪物、魔法、地图等等,也有一些部分人印象并不深的特效资源、动作资源、图片资源等等的元素,所有这些存在于客户端和服务器上的资源和数据,组成了我们所熟知的网游世界。
这些元素都是需要编号的。编号的理由很简单,元素的编号是客户端和服务器通讯的依据,就如同每个人的身份证号码一样,对于同种元素,其编号都是唯一确定的,通过一个编号就能确定同种元素中的一个元素,由于客户端和服务器的程序和数据库上有了这种约定的共识,于是通过一个编号的检测,双方就能知道这个是一个什么元素,有些什么特征,从而就能从数据库中查询到元素的其他具体属性,然后在客户端详细的表现出来——或文字、或图像。 在游戏的设计前期,对游戏元素的ID编号规则的规划很重要,如果在前期不注意其ID编号的规划,在后期的维护和增删元素的过程中就会碰到很多的麻烦。试想游戏元素中的编号是随意定下的或者是按流水号在制作的过程中顺序生成的,让我们来看看会造成什么后果: 1、最大的问题在于程序,如果编号是有一定的规则的,程序可以抽象出来分类来定位,定下元素的类型和具体属性,然而如果元素是仅仅通过感性的任意编号或者是流水生成,而没有什么规则,这样程序就必须记住并且枚举出所有的元素的ID,客户端也要保存一份这样的ID表,对于维护和更新的时候,同时也要对客户端更新这份表,这样一来对于程序的代码优化十分不利,二来最重要的是安全性很差,这些ID如果暴露在客户端,对于安全性很有问题。 2、第二个问题在于维护和管理,随意定下或者按流水号来定下的ID编号,即使对最初定下的人来说,到了以后维护的时候,从ID上完全看不到丝毫的信息,该ID除了一个标识以外就只有标识了,其信息量的浪费是很严重的。 当然,以上只是从最极端的情况——没有丝毫规则的定下编号——来谈后果,很多公司在真正定下编号的时候还是有或多或少的编号规则的,然而优劣在于信息量的足够程度——足够,不过多也不过少的信息含量。 让我们来看看身份证的编号,看看从中能获得什么启发: 身份证的编号为:【前六位是你户口所在地区的代码,中间是你的出生年月日,后面就是你的身份认证号码了,旧的身份证中,如果是女性,最后一位号码就是双数,男性就是单数。
新身份证号码是在旧身份证号码出生年份前加了19或者20,这是为了解决千年问题;】在旧身份证号码最后又加了一位数,是居民证号。居民证号取消了旧身份证的男女单数和双数之分,也就是说女性的最后一位号码也可以是单数,男性的也可以是双数。
编号规则中最重要的是【】中的内容,对于每个人来说,其个人信息最重要的不过是时空的概念——时间和空间——人所在的地方和人所存在的时间,而其次是一个编号的标识,这些组成了身份证的编号——一个人类唯一的标识。 对于游戏中的元素也是一样的,在规划一种元素的编号规则前,首先要注意的是哪些信息对于这种元素是最重要的,其次对这些元素定下位数,最后对这些位定下其编号的规则以及位的意义,这样就是一种元素的编号规则的设计流程。 下面以NPC的编号规则为例。
对于游戏中的NPC,像人一样,需要记录空间的信息,然而无需记录时间的信息,另一方面,NPC还需要记录其类型,因为游戏中的NPC都分为多种,有的是功能性的,有的是专门给玩家任务的,而另外的一些是用于场景点缀的,因此这样归纳下来,NPC的主要属性有三个:
空间信息:该NPC所存在的场景,对应场景地图的ID 功能信息:该NPC所属的功能类,是功能性NPC、任务性NPC还是点缀性NPC 编号信息:该NPC的唯一性编号,有了前面的两种划分,剩下的这个编号可以用流水号来记录了
根据这三个主要属性,可以对NPC的ID定位为8位,前四位为地图ID号(前两位为片区,后两位为地图),中间一位为功能号(0为功能性,1为任务性,2为点缀性),末三位为全局的流水号(至于为什么是全局的流水号,在附带文档中有说明) 以上只是笔者所认为的NPC的一种编号规划方式,没有最好的通用编号规则,只有最适合项目的编号规则,编号规则的规划需要因地制宜,需要因项目而作出调整和修改,笔者目前也只是尝试从游戏的通用元素的通用特征中提取一个通用的编号规则,而后可以在进行特定的项目的时候,以其作为模板,进行进一步的适应项目的细节修改。 以下贴出笔者作出的编号规则探讨书的一部分,以抛砖引玉,希望编号规则一事能引起设计师们更多的关注和讨论。
相关档案:sf_2006722175052.doc (218112bytes)
|