在游戏开发中一个功能的实现往往需要制作一个或多配置表来完成。比如很多游戏中会有任务的概念，我们可能需要一个字段表示任务名字，一个字段表示任务描述，如果任务的种类很多，我们可能还需要一个字段用来定义任务类型等等，除此之外，还需要一个主键作为索引。那么任务表大概是这样的：
|
主键 |
名称 |
描述 |
任务类型 |
|
|
类型 |
INT |
STRING |
STRING |
INT |
|
字段名 |
Id |
Name |
Desc |
Type |
|
100010 |
测试任务 |
测试任务描述 |
1 |
表-1 任务主表
通常，每个项目会有自己的导表工具，制表工具，读表规则等等。这里我不讨论程序流程，或导表流程之类的范式。我讨论一个程序通常不会去讨论的问题，如何根据策划提出的策划案设计制作相关的配置表，已实现相应的功能。
在实际工作中，程序和美术往往具有专业性，其本身通常是学习过相应的专业理论，进行过相关专业的实践的。而策划则不同，策划这个工种几乎不具备硬性的专业门槛。通常的公司选人的时候无外乎，有经验的，喜欢游戏的，好听点或热爱游戏的，然后聪明的，通常就是学历越高学校越好越可能入门。这使得策划找工作更像是玄学，而策划如何进行工作，往往也是一人个习惯，一个项目一套规则。
进入到设计制表这一项的时候，表现就是要么靠程序的经验搞定，要么程序的数量搞定。而策划在其提供的帮助很少，而且往往有害，如果程序经验不足，话语权不够，往往到最后就是项目的代码越来越烂，越难以维护。
那么回到要讨论的问题，策划表该如何设计制作？
这里我们先提出两条公理和一个明确事实，两条公理如下：
策划表时间公理：策划表的建立时间远小于数据表的使用和维护时间。
策划表错误必存在公理：当策划表被配置并被长时间使用时，数据错误一定会发生。
一条明确事实如下：
策划所填策划表格数据最终将由程序调用执行。
为避免更多无意义的争论，以下的讨论都将默认为同意两条公理和一个事实作为基础进行，这里就不再继续展开了。
完全覆盖原则
首先我们先介绍策划制表的第一个原则，完全覆盖原则。当一个策划案完整实现，并有充足的测试用例来测试后，我们可以认为当前的程序系统是可信任的。此时，如果策划想对表现进行修改，比如策划想将“测试任务”的名字改为“故事的起点”，那么只需要对应修改表1中Id为100010的Name字段即可，此时程序是不会因为这种修改而出错的。
但如果任务100010的完成条件为打死三只家鸡，策划想把他改为三只野鸡，但程序之前因为没有一个杀怪任务相关的配置表，而将完成条件写死在了代码里。那么提出这种修改时，程序就需要去修改代码，如果程序的代码辐射范围比较大，那么可能影响整个任务系统，也就是说，之前可信任的东西变得不值得信任了。若想它重新恢复可信，就需要对原系统重新进行测试。面对这种得不偿失的情况，程序会期望对于已完成系统的修改优先以更改表中数据的方式实现。
为了达成这一目的，我们需要在制表时就要遵循完全覆盖原则。完整定义为：
策划表应当包含所对应的策划案程序实现所需要的所有参数型内容。
单一职责原则
回到杀怪任务的例子，总结一下策划的需求。如果将杀怪任务的完成条件总结成一张策划表，我们需要一个怪物名称的字段，需要一个MonsterName标识怪物的名字，需要一个唯一对应怪物的标识MonsterId，需要对应Count字段控制杀死怪物的数量。一个主键和任务主表中的Id相同，已方便程序能够方便的找到对应关系，那么它看起来像表2这样：
|
主键 |
怪物名称 |
怪物ID |
怪物个数 |
|
|
类型 |
INT |
STRING |
INT |
INT |
|
字段名 |
Id |
MonsterName |
MonsterId |
Count |
|
100010 |
野鸡 |
10001 |
3 |
表-2 打怪任务表
如果有任务完成的类型很多，我们可能有对话任务表，交付物品任务表等等等等。这里将每一个功能中职责统一的部分单独建表原则，它体现了我接下来要介绍的原则——单一职责原则。单一职责原则是面向对象程序设计的原则之一，在指导程序设计时，是单只类的职责，一个类应该只负责一个职责。其核心是高内聚低耦合。这里做一下文字游戏将类换成策划表，那么单一职责原则的定义如下：
一张策划表应该只负责一个职责。
那么问题来了，策划会这样反馈，我认为任务功能是统一的两张表的主键ID是一样的是不是就能统一成一张表了？每一种任务类型都要定义一张表么？岂不是要维护很多张表？错误的概率是不是增加了？填表是不是更困难了？能不能从策划的角度出发，来建一个方便策划填的表？
首先，我这里举的任务的例子是一些常规的游戏比如，MMO，SLG之类的。如果说你的游戏项目是一个1024，那么需不需要例子中复杂的任务系统，甚至需不需要一个被称之为任务系统的东西都两说。
其次，如果我们讨论的都是同样一个复杂系统，并且我们将这个复杂系统中的数据都建立在一张策划表中，这时尝试讨论一下维护这张表格的策划他日常的工作是怎样的。
表格的填表操作，无非是增，删，改。我们可以合理假设一下这张表的列数，它需要维护于任务相关的基础数据，无非是任务名，任务奖励等，这随这项目的进度，这些会影响全部任务类型的列数可能有十几列。而每一个用来描述每一个任务类型的列数少的可能就一列，多的可能有七八列，最多的一个可能有十几列。综合起来，我们可能得到一个百十来列的表，而且列数还在不断增多扩容。
此时，作为表格的维护者，在为每一个任务填数据的时候，你重视的应该是那几个和当前所填任务相关的列，我们假设你在表的外部整理了。所以你填了于当前而任务相关列的数据，但你同时要将其它列填上无效值。也就是说在大表之外，策划维护了一个小的表，来帮助他进行填表。这还是理想情况，假设策划填表时是复制其它行数据填到当前列里呢？其它行的数据可能没有填成无效值呢？
所以我们看，如果统一成一张大表后，理想型策划需要的工作是什么，需要维护一张一张的小表。而且在填表时还增加了数据污染的可能。至于说觉得打开多个文件填表困难的情况，可以想象一下打卡上百列的表格文件，三个显示器横屏都看不到头的情况下，找到正确列填上不同数据的难度，以及学习成本。
这里刻意强调一下，一个系统的维护的困难程度是和系统本身的复杂度正相关的，而它的相关系数是和系统的实现方式有直接关系，遵循单一职责原则是降低这个相关系数最有效的方式。
总结
由于常年工作在业务逻辑第一线，在很多时候，我会疑惑于策划是以什么标准来处理业务实现阶段制表的逻辑呢？凭经验么？这些经验有什么依据么？我应该如何说服他们以理想的方式定义表格呢？而不是一言堂，你们都挺程序的。我提出的制表方案的逻辑是什么呢？从编程的角度来讲，策划表格不过是个仅含有字段的对象而已。天然的没有继承属性，那么它就不遵循OOP的很多原则。另外它本身的纯字段属性又让它具备领一些OOP没有涉及的东西，一些贴近业务逻辑的理解。
这里策划表制表原则将其看作对象那么它应该具有的是单一职责原则。它涉及到业务逻辑的部分将其总结为完全覆盖原则。