六年谈-2.了解程序、美术与测试
发表于2015-10-19
作者：leoneed
作为策划，不能不去了解程序、美术与测试的工作，了解的越多，沟通越有效，而沟通是策划最重要的工作。这些背景知识的积累说明了一个策划的真正经验之一。（很多人把玩游戏的经验就当作策划的经验）
作为策划，不能不去了解程序、美术与测试的工作，了解的越多，沟通越有效，而沟通是策划最重要的工作。这些背景知识的积累说明了一个策划的真正经验之一。（很多人把玩游戏的经验就当作策划的经验）
程序是游戏的实体。程序员关注于游戏的数据与数据结构，逻辑与运行效率。所有程序的功能不是用数据支持，就是用逻辑支持，或者两者结合。
数据类型是程序的基本功课。常用的数据类型说明如下：
l 整型：不含小数点的整数。
l 浮点型：有小数点的数。
l 字符型：字符串组成的文本。例如物品的名称就是字符型数据：”搅拌牛奶的圣剑”
程序使用的数据类型会更多样，因此策划在编写数据，或提出数据需求的时候，应尽量说明清楚这些数据属于哪种类型。以及该项数据的最小值和最大值，也就是数据的值域。这样能保证程序有足够的信息选择合适的数据类型。
例如NPC的血量，要求是整数型，最小为0，最大为10亿。
数据有三种存在方式：资源数据、实例数据和数据库数据。
资源数据：程序运行时作为资源读入的数据，这类数据提供了构建游戏世界的基础信息，例如地图数据、怪物模板数据。制作资源数据是策划最大量和频繁的工作。
实例数据：相对于怪物模板数据，游戏中同一种怪物可能有很多只，那每一只都是一个模板的实例，他们都有一个自己的实例ID，这些在游戏运行过程中生成出来的数据，就是实例数据。
数据库数据：实例数据在游戏程序关闭的时候就消失了。那玩家如何记录自己的角色，获得的装备，宠物呢？这些数据实例数据会通过服务器程序储存到游戏数据库中，在下次运行程序的时候，就可以再次读取并创建角色实例信息了。服务器程序不能一直不停的写数据库，一般游戏会定期进行储存，或者在重要的时候进行储存。如果不希望玩家因为服务器宕机而丢失已获得的东西，那么就应该在这个时候提出立即储存实例的功能需求。另外，在提需求的时候一定要注意实例储存的上限，不然可能会遇上例如装备不能再扩展属性的问题，因为装备的实例已经固定了大小存储到数据库中，所以再扩展的属性无法储存，除非将已经生成并储存在数据库的装备全部进行修改，而这是非常冒险切耗时的操作。
数据结构是程序非常在意的东西。结构良好的数据能够适应更多需求变动，并且清晰明了容易操作。策划最需要了解的是关系性数据库的数据结构，这种结构大量应用在策划编辑的数据中。
假设一个装备需要这几个属性：
l 装备ID
l 装备名称
l 装备类型
l 模型
l 图标
l 属性1
l 属性1的值
l 属性2
l 属性2的值
l 属性3
l 属性3的值
l 属性4
l 属性4的值
我们看到属性与属性值有很多个。那么一个装备可能加多少属性，就需要多少个属性/属性值对，这样一行装备信息（策划的数据一般都是用excel表格制作的）就会非常非常长，当不同装备需要用相同的装备属性时，需要重复填写两边，任何属性的调整都要生成一遍新的装备表，甚至是物品表，更要命的是在维护时，改了一个还要记住去改另几个。为避免这些问题，可以讲属性单独做一个数据，并通过属性ID将两个表关联起来，结果如下：
装备表：
l 装备ID
l 装备名称
l 装备类型
l 模型
l 图标
l 属性ID
属性表：
l 属性ID
l 属性1
l 属性1的值
l 属性2
l 属性2的值
l 属性3
l 属性3的值
l 属性4
l 属性4的值
通过固定ID，将数据关联起来，这是关系性数据库的关键。我们经常需要和程序讨论数据结构，整理出清晰简单的关系性数据，这非常重要。数据库的数据绝大部分也是关系性的。
数据通过二维表格最容易看懂和编写，而很多数据需要更多的维度。关系型数据结构就可以通过几个关联的二维表成功描述多维度的数据。
数据是程序在空间上的描述，那么通常逻辑是一个时间过程的描述。
对于程序来说，逻辑无非是做一个什么事，判断一个什么值，循环一个什么过程。在脑子里清楚有哪些数据后，程序会进行逻辑代码的编写，这个过程非常参考策划的功能需求。
当程序编写逻辑代码的时候，他会考虑如下几个问题：
l 逻辑的起始点在哪里？系统初始化是什么样子？
l 哪些是客户端逻辑？哪些是服务器逻辑？
l 逻辑是否分阶段分步骤？有哪些阶段和步骤？
l 玩家可以有哪些操作，如何反馈？
l 客户端如何处理异常操作？
l 服务器如何循环工作？
l 服务器如何处理玩家掉线、服务器关闭开启、何时存储数据库？
l 功能之后可能会有哪些扩展？（留下扩展接口，方便之后的扩展功能）
对于程序员来说，任何细节，无论大小，无论是否重要，都需要确切的说明。经常情况是策划认为重要的东西，程序做起来简单，而策划忽略的细节，是程序最大的工作量。往往不是程序员没有做好工作，而是策划并没有站在程序的角度描述功能，导致游戏功能缺失或残废。
想要更深入了解程序，试着自己写代码做一个小游戏吧。这样非常有用。
美术的工作最为单纯，但最需要功底和天赋。长期的绘画基础和经历让美术们形成了各自的风格、特点和特长。一个美术团队常由相同美术背景的人组成，否则他们的作品很难形成统一的风格感受。
美术一般工作过程如下：
l 接收策划的美术需求
l 设计2D原画（如果是图标、UI，则调过下面3D相关步骤）
l 根据原画进行3D建模
l 绘制3D贴图（如果是制作场景、道具则跳过下面一个步骤）
l 制作3D骨骼与动作（制作角色需要的步骤）
l 制作动作特效
l 渲染成2D动画（如果是2D游戏的话）
l 打包游戏美术资源
由于3D模型的动作表现更准确，制作更快，再加上角色需要大量的换装，使用3D模型制作，之后再渲染成2D游戏图素的方式已经非常普及。
一些美术喜欢非常自由的发挥空间，而另一些则希望自己的工作更符合确切的需求。对于较大型的项目来说，前者会是灾难。因此，无论美术是哪种类型，策划都必须非常清楚如何提出有效的需求。美术需求一般有以下几种：
l 界面样式
l 角色设定
l 怪物设定
l 装备设定
l 场景地图与场景物设定
l 物品图标
l 技能动作与特效
l 界面特效
提这些美术需求的时候，需要注意描述的几个项目：
l 美术资源ID名称
l 需求提交时间点
这个一般由策划先定一个，在审核版本工作计划的时候，还会根据实际情况进一步修改。
l （像素）尺寸
l 使用位置
在什么地方出现、在屏幕的什么位置。例如界面需求需要描述其初始的位置坐标点信息。
l 功能描述
有什么交互表现、功用或动画表现。当美术理解他们的作品会有什么用时，他们会发挥的更好。
l 绘图描述
语言描述需要绘制的是什么样的东西？注意需要表现什么样的特质，那些地方可以自由发挥。
l 例图
策划用PS简单的制作例图对于美术设计UI非常有用。同理，找到其他类似图片提供给美术作为参考，也会非常有效。
测试往往是很多团队轻视或者忽略的一个地方。但对于现在的游戏项目来说，反复的修改，各种版本的交叉，导致了测试实际上是非常重要和关键的一个位置。好的项目，测试时长应该是开发时长的2倍以上。但真正做到这点的团队很少，这就导致了测试部门压力巨大。最能帮助测试提高工作效率和精度的就是策划了。我们了解的测试知识越多，越能简化他们的工作。
测试一般的工作流程是这样的：
l 参与游戏设计的讨论，预测并记录新设计可能会产生的隐患
l 得到游戏设计方案，制定测试方案，列举测试用例。等待版本发布
l 根据最终版本的更新修改测试用例，进行版本用例验证
l 对新版本进行常规测试，也就是每个版本，无论是否有修改，都会去再测试验证功能是否正确的那些用例
l 反馈测试结果，提交bug，更新测试用例，等待新版本
一个测试用例就是一个测试点，尝尝就是策划的一条更新记录。将一个版本的内容细分成一个个小的测试用例点，是主测试的主要工作。主测试就是通过管理跟踪这些用例点的状态来了解测试情况的。
由于测试可分为白盒测试于黑河测试两种。因此当我们提供给测试新的功能或者更新清单的时候，不仅说明修改前后的区别，还需要给出修改后的新数据。前者用于黑盒测试，只从结果去验证；后者用于白盒测试，通过观察对比数据，寻找可能出现的问题。
从立场上来说，测试在接收到一个新版本的时候，应该是一个对游戏一点都不了解的状态，因此，每次给测试提出新功能或更新时，要尽量说明清楚，即使一个对游戏什么都不了解的人也能看懂的最好了。这时候对于策划来说，经常出现改起来很容易，说明改了什么很困难的情况。于是，很多策划在提新功能和更新说明的时候，尝尝省略、忽略一些内容。这会导致测试无法正确掌握信息，到头来还是会提很多奇怪的bug或者无法测试，引发更多的工作量。因此，策划在工作时，应该时刻记录，哪怕花费比制作还要多出一倍的时间在记录这些制作内容上，也是值得的。只要做到这点，与测试合作将会非常容易和高效。
当我们自己玩游戏发现问题的时候，应该先报告给测试进行复现验证，形成新的bug。这样每次的问题修改都会留有记录，如果是自己偷偷的修改掉了，其连锁引发的问题，可能会被自己忽略。留下bug记录的话，能减少这种情况的发生，至少再发现问题是有据可查的。
作为主管，应该向测试提供功能的负责人表，什么东西是哪个人负责的。这样方便测试在测试过程中及时进行沟通。