在游戲開發中一個功能的實現往往需要制作一個或多配置表來完成。比如很多游戲中會有任務的概念，我們可能需要一個字段表示任務名字，一個字段表示任務描述，如果任務的種類很多，我們可能還需要一個字段用來定義任務類型等等，除此之外，還需要一個主鍵作為索引。那么任務表大概是這樣的：
| 主鍵 |
名稱 |
描述 |
任務類型 |
|
| 類型 |
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沒有涉及的東西，一些貼近業務邏輯的理解。
這里策划表制表原則將其看作對象那么它應該具有的是單一職責原則。它涉及到業務邏輯的部分將其總結為完全覆蓋原則。