【遊戲開發】配表在程序與策劃的溝通中極爲重要 V1.0

序

成爲一名遊戲程序有較長一段時間了，自認爲仍是有進步，雖然感受太慢了點。一直想寫一些東西，總拿不出東西來寫。從這裏開始吧。

在第一個失敗項目中，策劃會在出策劃案之時或以後不久給出配表。

習慣了這種模式，在第二個項目中，策劃不配表，甚至開始都不怎麼管配表（測試測完後一段時間才檢查配表），遇到了一些麻煩。

據說在遊戲的開發中配表並不是都是策劃來配，也有程序配的沒能再說什麼。遊戲開發的流程也確實是測試先驗收、策劃再驗收。

但在此過程當中，本身也一直在思考。但根據本身的理解，自認爲配表在溝通中極爲重要的內容，是功能模塊實現前應該最早肯定，最早驗收的東西。

配表的重要做用

配表是遊戲程序的組成部分，是策劃控制遊戲實際運行的重要工具。是鏈接策劃和程序的橋樑。程序代碼是否符合策劃的需求，首先就體如今配表上。

程序所配表不能實現策劃控制遊戲運行的功能需求，那使用該配表的程序代碼就必定不符合策劃需求，程序和策劃之間對功能需求的理解就必定有不一致，進一步溝通。

程序所配表配表能知足策劃控制遊戲運行的功能需求，但實踐上不便於填表使用不方便，那使用該配表的程序代碼也必定不符合策劃需求。這在程序和策劃間對功能需求的理解上或有或沒有誤差，但必定須要進一步溝通，代碼必定會改。

程序必定會第一時間看配表，從已經完成的配表中結合策劃案能夠更精確瞭解策劃對遊戲運行的實際需求。有配表的輔助，策劃案的許多地方都再也不須要寫或講解到那麼清晰。

策劃不知道怎麼配表的地方，策劃所配表讓程序認爲有問題的地方。要麼策劃案中必然不會清楚描述遊戲該怎麼運行，要麼遊戲運行的控制相對複雜，須要特別當心。這剛好就是程序須要特別關注，或許與策劃理解有誤差的地方。

策劃與程序間傳達功能需求的三個層次工具

策劃向程序傳遞功能需求，最明顯的兩個工具就是策劃案和口頭交流。

策劃案適合表達框架性、基礎性、概念性的東西。這些內容較爲抽象不易用口頭語言表達，較爲基礎可能須要常常查閱。

口頭表達適合細節的，須要特別注意的關鍵點。這些或者內容用文本表達冗長、繁瑣，或者須要雙方相互交流，一開始沒法明確要傳遞的內容重點。

要提升效率，在準確傳達需求的前提下須要：（1）減小花在策劃案上的時間。（2）減小口頭交流的時間。這須要：提高工做能力，好比更快更好地寫出策劃案，更快更準地理解策劃案的意思；更好的口頭交流技巧； 提高了解，包括對對方自己及工做內容的瞭解、對共同事業的瞭解。這些都是職業素養相關的內容，須要長期積累、不斷提高。

有沒有一種工具可以直接提高溝通效率呢？我認爲就是遊戲配表。

遊戲的各功能模塊或多或少受配表驅動，其運行框架不少部分就體如今配表中，配表最終是要被程序代碼讀取的須要足夠精確，包含有足夠多的細節。

配表是遊戲程序中最終必定要有東西，若是更早肯定。那麼部分的策劃案內容就不要了，甚至自己就能夠做爲策劃案的一部分；許多口頭交流也避免了，由於配表中已提供最精確的信息。

把策劃案和口頭交流做爲策劃和程序交流功能需求的兩個層次，策劃案就是極佳的中間層次。雖然其造成須要必定的思考和交流，但這些代價沒法避免。而若是做爲一種交流工具來看，自己可以對交流起到極大的促進做用，減小花在策劃案和口頭交流的時間。

程序或策劃負責配表的優勢與缺點

策劃最早、最準確知道遊戲功能需求，配的表天然符合本身控制遊戲運行及使用方便的兩大需求。

策劃配的表，可能不利於程序讀取，甚至有些功能，有些策劃不知道怎樣配表來控制遊戲。

程序配的表，必定能讓程序代碼讀取以實現相應功能。

程序配表可能由於一開始對功能需求理解不清楚而無從下手、理解誤差而配錯，還有可能不便於策劃填表使用。

誰應該負責配表？

根據本身的經驗和思考，自認爲不管誰負責配表均可以，但策劃和程序都應該參與，都應該才第一時間檢查配表的合理性。能夠按照如下步驟：

（1）策劃在編寫策劃案時，應編寫必定的基礎表：能夠是完整表（策劃負責配表）；能夠留下不會的給程序；能夠把自認爲程序能直接補全的部分給程序（程序負責配表）。這個基礎表做爲策劃案的部分或補充。

（2) 程序在看過策劃案，開過需求會後，在理解模塊需求的第一時間把配表的剩餘部分補全，把表中不便於代碼處理的部分進行修改，有疑問沒法補全的，或者自認爲可能補錯的地方標出。而後反饋給策劃，並能夠做爲找策劃口頭溝通的工具。

（3）程序和在策劃的進一步溝通中完成並確認配表。

這一過程起碼要在測試開始測以前完成。當配表完成時最終完成時，結合以前的策劃案，口頭交流。大部分的遊戲功能模塊需求在程序和策劃之間基本就比較一致了。