[技术交流] 如何建好数据表.docx
需积分: 0 193 浏览量
2014-02-13
17:45:05
上传
评论
收藏 16KB DOCX 举报
最近对外交流比较频繁，接触了很多朋友的项目，发现在他们的项目中，数据表的建立都
有比较大的问题，大多表现为：
1，数据列众多：随机挑张表打开一看，我的天，横向没有 100 列也得有 5、60 列，做个页
游甚至手游，至于吗？但是他们却能详细的分析出每一条打算干嘛？这点我觉得至少他们
都是做过项目的老团队，分析出这些数据的作用应该不难，但是却让我看到了一些问题—
—策划与程序的沟通缺乏，甚至有些团队的表结构是由程序建立的，而程序员本身对游戏
即将做成什么样也是一知半解。
2，表连表频繁：一个任务表，某几列挂向 NPC 表，为的是谁给的任务，任务交给谁，还
有任务过程中要接触谁（比如杀什么怪）；除此之外，还要挂向道具表，任务奖品、任务
掉落等；这还不够，他还要挂向一些其他表，比如 bu 表，技能表。我的天，这你让策划
怎么去填这个表，天地良心，一个公司机器配置最差的基本都是策划，而他们却要用这种
机器打开高配机器开了都吃力的这么多的表，仅仅只是为了填一个表。
我相信大家经历的项目中，以上两大问题，多多少少都会遇到过一些吧，从我的经验来看
在一个游戏设计师设计表的时候（我认为数据表结构应该由策划提供），需要注意以下这
些，才能建立出比较适合的表来：
1，合理利用计算公式、巧妙运用数据类型，该去掉的去掉，该合并的
合并。
什么是合理利用计算公式？我见过很多混账表，其中甚至包括了玩家升级经验表，这往往
发生于那些认为策划应该被细分为系统、数值等工种的团队。事实上在经验值的数值设计
上，是最开放的，在你设计整个游戏系统的时候你想要的经验值提升曲线如何？无非越高
等级需要越多经验，这我们都知道，那么经验增长速度的环比如何？无非也就是越到后面
提升越慢的和越到后面提升越明显的，2 个都接近于公式 y=power(a,b)，区别在于前者的 b
要大于 1 而尽可能小于 1.5，后者只要大胆的大于等于 2 就好了，这至于去填一个表吗？不
值得！这就是所谓的该去掉的去掉，某列数据可以用公式计算，或者通过其他数据演算获
得，那么就去掉它，表的每一列数据都应该是独特的，是计算机无法通过一种固定逻辑产
生来的，因此才需要人为去填写。
什么事巧妙运用数据类型？我见过一些技能表，在不断地开发过程中无限膨胀：今天策划
想出来了某某技能不能对建筑物使用（dota 类），由于表是程序建立的，程序说了，加一
列“可否对建筑有效”，布尔型；明天策划又想到了，一些技能还不能对元素类别的怪物使
用，于是程序又说了……逐渐逐渐的，表列越来越多了。你可以说策划初期为什么没有想
好有哪些目标类别，那这样一早建立好表，不就不用去改了吗？事实上有经验的项目经理
都知道，这是不现实的，因为人每天都在思考，新的主意如果够好，应该被利用。那么像
这样一个动态性的问题，事实上我们可以把它变成一个位运算的做法。每一个角色数据中
有一项免疫类别(ImmuneType)，而技能本身有一项效果类别(eectType)，我们指定元素类
为 0 位、建筑为 1 位、魔法为 2 位、诅咒为 3 位、钢铁为 4 位，这些都是我现在脑袋一拍说
的，明天策划说了我又有技能不能对昆虫类用，没关系，昆虫为 5 位，用一个 int64 来记录
该项我觉得足够了，但使用 string 就有些亏了，我不信有策划能想出 64 个特性来。而实际
工作中，策划只要为元素建筑物单位的免疫类型配置为 3（1 左移 0 或 1 左移 1，这句话不
能用语文的方式理解，而要用程序的方式），钢铁元素建筑 19 就可以；而我们有一个火球
技能为元素魔法那么他的效果类别就是 5，刀砍技能没有符合以上的特效他就是 0。而在程
序处 理过 程中 ，判 断技 能是 否对 目标 有效 的函 数也 比多 条 if 好些很多，直接 return
评论0
最新资源