青龍，亦作“蒼龍”，古代神話中的東方之神。龍是中華民族的圖騰，自黃帝授命于天，威澤四方，龍就成為中華民族乃至整個中國的象征，而比較明確的定形是在漢代，從大漢朝開始，龍就被確定為皇帝的象征與代表。在東方傳說中，青龍身似長蛇、麒麟首、鯉魚尾、面有長須、犄角似鹿、有五爪、相貌威武，而在西方神話里，龍更像是長翅膀的蜥蜴。 　　 　　白虎，古代神話中的西方之神。形體似虎，白色，兇猛無比，因此成為尊貴的象征。同時白虎也象征著威武和軍隊，所以古代很多以白虎冠名的地方都與兵家之事有關，例如古代軍隊里的白虎旗和兵符上的白虎像 　　 　　朱雀，亦稱“朱鳥”，形體似鳳凰，古代神話中的南方之神。因其形似鳥狀，位在南方，火屬性，所以在游戲中經常以鳳凰的形狀出現。但其實朱雀和鳳凰是兩種不同的生物，鳳凰是百鳥之王，而朱雀卻是天之靈獸，比鳳凰更稀有尊貴，破壞力也更強。在**的漫畫和游戲里，朱雀都是作為強力召喚獸或者妖獸出現的，比如漫畫《幽游白書》和根據漫畫改編的同名游戲。 　　 　　玄武，也叫“真武”，俗稱“真武大帝”，是道教所奉的神。相傳古凈樂國王的太子，生而神猛，越東海來游，遇天神授以寶劍，入湖北武當山修煉，經四十二年而功成，白日飛升，威鎮北方，號玄武君。但宋朝忌諱玄字，因而改稱真武。玄武又相傳本身是北海一只大龜，此龜曾經被當作柱子支撐整個蓬萊仙山，因其靈性深覺，歷經多年的聽道聞道，終于修得正果。所以帝王陵寢多有馱碑之龜，正是以此暗寓玄武。另外玄武又叫玄冥，故又稱北冥，聽到這個名字估計不少讀者又聯想起北冥歸海，還有金庸老先生筆下人物逍遙子的《北冥神功》。

測試方案屬于軟件工程的范疇，對于策劃人員來講是測試游戲的主力軍。好象沒聽說過哪個策劃將測試過程描繪的很愉快，因為測試本身是一個非?？菰锖屯纯嗟氖虑?。一套合理的測試方案可以盡可能減少測試人員的工作量，也能夠讓測試出的問題能夠盡快解決，這就需要測試方案的制訂人員對游戲開發有全面的了解，并能夠掌握好測試的進度，其中的難度可想而知了。

　　測試是游戲開發一個極為重要的組成部分，其所需要的時間一般要占去整個開發周期的1/3左右。測試貫穿于整個開發進程，小規模的模塊測試是由程序人員自行完成的，對策劃來講，如何完成最終的產品測試才是真正需要關心的。按照軟件工程的理論，測試方法主要有兩種：黑盒測試與白盒測試。所謂黑盒測試就是把要測試的對象當作一個黑盒子，不需要知道里面是怎么處理的，只要對輸入和輸出數據進行測試就可以了；而白盒測試正好相反，測試者必須對測試對象的內部處理過程非常了解，對里面所有的分支和循環進行實驗從而達到測試的目的。黑盒測試與白盒測試都是最基本的測試方法，屬于低層的測試理論，實際的測試方案都是在這兩種測試方法基礎上產生出來的。

　　對于游戲的測試，也不外乎這兩種測試方法。基于黑盒測試所產生的測試方案屬于高端測試，主要是在操作層面上對游戲進行測試；基于白盒測試所產生的測試方案屬于低端測試，是對各種設計細節方面的測試。黑盒測試中不需要知道里面是如何運行的，也不用知道內部算法如何設計，只要看游戲中戰斗或者情節發展是否是按照要求來進行的就可以了。這種測試可以找一些對游戲不是很了解的玩家來進行，只要寫清楚要干什么，最后達到什么樣的效果，并記錄下游戲過程中所出現的問題。而白盒測試就需要知道內部的運算方法，比如A打B一下，按照A和B現在的狀態應該掉多少血之類都應當屬于這種測試。白盒測試需要策劃人員自己來完成，因為內部的算法只有開發人員自己才清楚，而且發現問題策劃是最容易知道如何解決該問題的人。由于測試的工作量巨大，合理安排好測試和修正BUG的時間比例非常關鍵，否則很容易出現發現了問題卻沒有時間改正或者問題堆在一起無法解決的矛盾。測試設計應當在開發的設計階段就要完成，如果開發初期沒有給安排出合理的時間，那么最后的結果肯定是不停的跳票！

　　在測試方案中，設計人員要根據需要把黑盒測試、白盒測試有效的結合在一起，并且按照步驟劃分好測試的時間段。根據游戲開發過程，測試大致可以分成單元測試、模塊測試、總體測試和產品測試幾個部分。單元測試一般集中在細節部分，主要是在游戲引擎開發階段對引擎的構造能力和完善性進行檢測。該部分的工作要求細致嚴禁，因為任何一點小的紕漏都可能導致后期大量的BUG產生。這時要求程序開發人員與策劃達到無隔閡的交流，策劃人員要清楚該引擎任何一個功能單元的使用方法和效果，這樣才能夠保證測試中能即使發現問題并指出問題的所在。模塊測試是在游戲開發進程中按照階段進行的，每當一個模型產生后就需要對該部分進行一次集中測試，從而保證系統的堅固和完善。模塊之間的接口測試也屬于該部分的工作，就是說各個游戲模塊之間如何實現過度，數據如何進行交換都要進行嚴格的測試。往往在模塊內部測試時一切正常，把模塊拼裝在一起后反而問題百出，這就需要在階段性模塊測試中及時解決！總體測試屬于比較高層的測試，在游戲的DEMO基本完成后，要從宏觀上把整個游戲合成在一起，這時就要求有全面控制進度的能力。最終的產品測試是游戲質量保證的最后一道關卡，要求大量的非開發人員介入進行地毯式轟炸！產品測試往往也會伴隨一些市場活動，這就不是我們現在要討論的范疇了。

　　我們已經知道了測試過程分成幾個階段，下面就一起來看看具體要包括那些內容：

1、 測試的時間分配：測試時間如何分配會直接影響到開發的進度，它包含測試時間、測試結果匯總時間以及修改錯誤的時間等幾個部分。一般來說，開發人員只認為測試時間才是需要分配的，其實合理的安排測試總結和修改BUG等工作占用的時間才是更多的！如果不進行測試情況匯總，項目管理者就無法弄清到底是哪些部分出了問題；不馬上對發現的問題進行修改就會導致更多的問題發生。所以定期測試、發現問題、解決問題才是最合理的，把整個開發周期劃分為幾個階段定期測試是對產品質量的根本保證！科學安排測試的時間能夠用最少的代價解決最多的問題，否則把測試都堆積在最后結果只會是一團糟！

2、 測試人員的安排：測試人員的選擇和調配對游戲質量來講是非常關鍵的。測試人員盡量不要選擇游戲的開發人員，只有對游戲沒有任何了解的人才能真正的發現程序或設計中的問題，雖然他可能對程序和游戲設計一點都不懂。如果能有一支專門的測試隊伍當然是最好的，在經費和人員實在緊張的情況下把其他非開發部門的人借調一下不失為一個好辦法。

3、 測試內容清單：這部分要求測試方案設計人員精心的考慮計算，盡量把測試內容精確到操作級。意思就是說最好細化到某測試人員點擊鼠標幾百次這種程度，因為測試人員是對你的游戲內容一點都不了解的，只有你把任務全都明確后才可以收到預期的效果。只規定某人去玩這個游戲然后給予反饋是不負責任的做法，這種測試方案只能當作垃圾給丟到廢紙桶里面去！要對每個測試人員的工作明確下去，用測試表格的形式進行填寫測試報告并簽字寫清楚測試時間，才算是合格的測試方案。

4、 測試結果匯報：最終測試報告匯總上來，策劃人員要對全部方案進行評估并進行分類，把測試中發現的問題確定解決優先級然后反饋給相關部門。問題特別嚴重的要敢于要求返工，任何一點小問題也不能放過，嚴格的測試才能帶來高質量的游戲產品，這個法則適用于任何產業，游戲也不例外！

5、 調整開發進度：由于測試發現的問題所帶來的進度影響要及時反饋給上級領導，然后馬上更新項目進度表，并注明更改原因。因為開發進度的調整關系到很多部門的工作，所以最好在早期設計進度時就把測試時間預算進去，但實際上大多數情況下開發進度的變化是非常頻繁的。如何休整進度還不影響到游戲完成的最終時間，對于任何項目管理人員來說都是一個挑戰！

　　測試方案一旦確立，剩下的就是煩瑣和枯燥的機械工作了。測試是最痛苦的，但沒有測試游戲是不可能成為產品，這也是國內大多數趕工期的游戲BUG百出的問題所在?？茖W的制訂測試方案并協調好各部門之間的進度，對任何一個項目來說都是至關重要的事情，對于剛入門的策劃來講，學會寫測試方案是必修的課程之一。

　　測試工作的全面完工，標志著項目開發的結束。但對于策劃來說，你的工作還沒有完，接下來你就要開始教給玩家如何玩這個游戲，讓我們來看看如何完成游戲手冊吧！

對于游戲的熟悉程度，估計沒有哪個開發人員會比游戲策劃更清楚了。大到游戲框架，小到界面熱鍵，一點一滴都需要策劃人員進行詳細的描述和設計，也只有策劃才能對游戲的實現情況進行全面的把握。所以一旦策劃和其他開發人員發生溝通上的障礙，整個項目的進展就會受到極大的影響；如果策劃能夠協調好各部分的工作，那么項目進展就只需要看個人能力了。而在現實開發中，策劃人員由于自身的個性或者其他條件所限，往往在溝通這個環節上出現一些致命問題導致進度的延誤。如何把握好自己的情緒，從大局觀出發是成為一個成熟策劃人員的關鍵所在。

　　文檔不管寫的多詳細，對其他人來講仍然會存在理解上的錯誤或漏洞。策劃經常把注意力都放在了如何把游戲設計的更完善上，而忽視了別人的理解能力和感受。因為對任何一件作品來講，每個人的看法都是不同的，策劃應該知道如何去聽別人的意見并吸收到自己的設計中來。這并不是說堅持自己的立場是錯誤的，而是在大多數情況下策劃本身容易把自己的設計當作一個孤立的個體，對其他外來的思想用全部拋棄的態度來對待，這是極其危險的。就算是別人的意見是多么的滑稽可笑，你也應該認真的聽完并加以分析，任何渠道的意見對你的設計來說都是有益的。

　　在前面講過如何書寫流程圖和安排工作進度，在這些設計過程中和其他部門的溝通都是非常重要的。我不提倡大規模的定期會議，因為這樣會影響其他人員的開發進度，而且會導致很多問題的擴大化。公眾場合下不適宜對個人問題進行討論，大量的溝通和談話應該以私人或者小型會議的形式來進行。大部分開發人員不喜歡開會，尤其是這種針對性不是很強的例行會議。所以如果確定要召開會議，那么就一定要先確定這個會議要解決哪些問題，需要哪些人來參加，最后要達到什么樣的效果。純粹為了開會而開會，尤其是一些例行會議是沒有必要的，這樣只會增加別人對你的厭惡情緒，導致關系間的不協調。如何盡可能減少大規模會議，通過單獨會談來解決問題是溝通的一個有效手段。

　　如果你想知道其他人員對你的策劃方案是否有意見，單純的把文檔發送給程序或美術不是一個好辦法。無論你的文檔多詳細，別人都很難完整的理解你的意思，利用好黑板和紙筆通過講課的方式進行溝通，可以一次性讓大量的相關人員了解你的設計。在講解完畢后讓大家以發表見解的方式來發現并解決問題才是有效的解決手段，你所要做的只是把你的想法表述給大家，而不是爭吵。在你的講解過程中要以聽為主，對于一些核心內容進行強調，認真做好筆記，在會議后對別人的意見進行總結，讓別人知道他的看法你是很重視的。只有對別人尊重別人才會尊重你，想處理好與他人的關系首先就是讓別人感覺到你對他的意見是重視的。

　　在完成了第一次講解后，就不要再召集這種大規模的會議了。剩下的工作你就應當找對應的工作人員進行單獨會面，只和他談有關他這個方面的設計問題。對程序就是描述游戲流程以及一些需要確認的技術實現問題，而和美術則應該談界面實現以及整體效果等問題。

　　給程序員交流要求你能跟的上他的邏輯思路，就是說你要對計算機的編程有個大概的了解。起碼你應該知道程序流程是通過條件分支、循環以及函數等組成的，而且要對面向對象的C 語言有一些了解，否則他會認為你的思路太混亂而產生很多理解上的概念混淆。最好你是拿著一個游戲設計流程圖來和他交流，這張圖應該類似于程序設計的流程圖，由幾種基本的圖形和線條來實現。這樣一邊描述你的思路一邊給他指出需要完成的模塊，發現問題進行記錄并修正你的文檔就能夠讓雙方都保持清醒的頭腦，而不是產生做出來產品后和你所想象的完全是兩個東西。這時經驗就會起到非常關鍵的作用，如果策劃本身就是程序員或者做過程序員就完全不用考慮這個問題了，可如果你對程序一竅不通或者根本就不知道那些東西是怎么實現的，那你最好去找本介紹編程基礎的書看一下。多和主程交流應該是最省事的辦法，只要交代給他哪些工作需要在多長時間完成就可以了，但很多情況下是主程和策劃一樣固執，這時他會不經過考慮就告訴你很多想法都是不能實現的。你要拿出詳細的解決方案才可以說服他，或者讓他提出一種合適的解決方案?？傊贸绦虻乃悸穪砗统绦騿T進行交流是最好的解決辦法，給程序員一份詳細的流程圖要比給他一份幾百幾千頁的文字說明要管用！

　　給美術人員交流更困難。因為每個人的美術風格都不相同，要求幾十個美術人員畫同樣一副圖你所獲得的結果肯定千奇百怪！通過主美進行協調是一個好辦法，這樣可以減少你很多口舌的。在你寫策劃方案時，不要對美術做太多的要求，而應該先和主美術確定好游戲的整體美術風格。美術方面具體的人員安排和工作量限定等事情都交給主美術或者美術總監去處理，除非說你對美術非常精通能夠把握住整體風格，否則你的工作只是描述你需要什么樣的東西就可以了。當美術完成樣品后，一起和主美術進行審查，風格一旦確定就不要再修改了，否則這對美術人員來說完全是種摧殘！美術人員工作量往往是最大的，美術風格的改變可能會造成大部分工作的重做，從而嚴重影響工程進度。把交流的事情交給美術方面的負責人，這是最好的同美術人員的交流方法。

　　保持好自己的心態，用積極的態度來解決問題，不要抱怨多聽別人的想法是一個策劃人員需要掌握的基本方法。只有溝通順暢才能夠讓項目按計劃進行，擴大自己的知識面，多和主程與主美交流，少開大規模會議，用私人交談的方式來解決問題。把握好上述幾點，項目的完成就只是時間上的問題了。