我寫這篇文章最主要的目的，是想跟大家分享一下這么多年從事主策劃工作的一些經(jīng)驗和知識。讓一些剛剛成為主策劃，并真心想開發(fā)出一款游戲的人能夠得到一些指引和幫助。畢竟，目前大多數(shù)介紹游戲開發(fā)、游戲策劃的書籍所介紹的該方面知識和技術(shù)要么流于表面形式，過于形式和膚淺；要么則過于深奧，鉆研的是關(guān)于策劃思想和理念方面的東西。而真正關(guān)于一個策劃（特別是主策劃）在項目開發(fā)過程中，該做些什么，該學些什么卻很少提到。
而之所會寫 “未入門、新手策劃、手游策劃、棋牌策劃、WEB游戲策劃不在此列”，也完全是基于領(lǐng)域不同技術(shù)不同的原理，不想從事這些領(lǐng)域的策劃們被我的帖子所誤導。
這里需要再次說明一下：我并不是說所有的主策劃在開發(fā)一款游戲中都需要做到這些事。但是這里面很多知識都是需要主策劃去了解、去研究的。所以，也許當你看到一些內(nèi)容，如果產(chǎn)生“如果我有一個好程序搭檔，這樣的事就不需要我去做”這樣的想法，那么你完全可以無視我的觀點，直接跳過。這一篇寫給那些沒有或不能確定自己有優(yōu)秀團隊、優(yōu)秀搭檔，但又想獲得項目成功的人。
另外，還有一些人會說，為什么我提到的更多的是跟程序、美術(shù)和策劃下屬打交道溝通的事，相反會忽略策劃的一些本職工作呢？在我看來，策劃的一些本職工作：例如寫策劃案、寫劇情案等等，是個策劃就會明白，而我寫這文章的目的主要目的是交流一些容易被人忽視被人冷落的工作環(huán)節(jié)，讓沒有注意到的人能有一個方面。
下面，我就針對我帖子中提到的每一個技術(shù)點進行詳細分析——用來說明為什么主策劃需要了解并運用這樣一些知識。
是否建立過項目計劃表？
是否每周定期召開策劃會議？
是否要求每個策劃每天提交工作日志？
這三點，是一個主策劃對策劃團隊管理的基本方法。作為一個專業(yè)的游戲開發(fā)團隊的負責人，為了確保項目的實施進度和效率，這樣的管理方法是必不可少的。一個人包攬所有的開發(fā)任務或者是所有人全部都自由發(fā)揮的團隊，開發(fā)一兩個手游、WEBGAME或許還行，要開發(fā)一個大型的MMORPG，這樣的主策劃專業(yè)技術(shù)再強，也不可能成功。
是否有規(guī)范策劃文檔（包括策劃案、邏輯圖、進度表、圖量表、元素表、UI設(shè)計圖、測試工具、BUG提交工具等）的規(guī)范寫法？
我們寫策劃案是干什么？給自己看？還是給你的上司看？——都不是。是給其他部門（程序部、美術(shù)部、測試部）作為參照和依據(jù)。如果不對這一塊進行規(guī)劃，那么你寫出來的每一個案子是不是都必須要你親自去向執(zhí)行者解釋一遍，并陪同他全程開發(fā)才能實現(xiàn)？即便是這樣，如果沒有規(guī)劃，當你想修改你的策劃文案時怎么辦？改完了，直接用RTX傳到別人那里？然后告訴它某某地方改了，讓他馬上進行修改？對于一個只有少數(shù)人參與的項目，這樣做或許比規(guī)范文檔看起來省事些，但是如果你面對的是一個大型項目、一個大型團隊。你這樣做將極大的損害整個團隊的開發(fā)效率，最通常的一個結(jié)果就是：開發(fā)到一定階段時，無法再獲取到原始策劃文檔，無法再了解到原始的策劃意圖。
是否與客戶端程序討論過底層圖象引擎的構(gòu)架，從而確定該游戲用哪種動畫表現(xiàn)形式（圖片、FLASH）更合適？
作為一個2D游戲，最占內(nèi)存資源和游戲容量的恐怕就是游戲中動畫的播放了。不要指望你的主程序員一開始就會去思考這個問題——因為他不需要對這個東西負責，他的責任是把策劃的需求實現(xiàn)，但是在這個需求中你會不會提到你做的游戲準備有一個多大的客戶端？準備用多少內(nèi)存來處理動畫渲染和播放？如果你做了，恩——那你當我是在說廢話，但我相信絕大多數(shù)國內(nèi)策劃還達不到這么高的水準。所以，并不是讓你一開始就去做這樣一件極具技術(shù)性的工作，只是讓你跟客戶端程序員去討論，讓他給你建議，讓他預測一下如果按你的思路這款游戲該用怎樣的表現(xiàn)形式更為妥當——如果是一個小游戲，游戲中動畫不怎么多，當然用圖片比較好，因為內(nèi)存調(diào)用速度比較快，技術(shù)也比較簡單；如果是一個大型游戲，那么你就得考慮了——用FLASH或強大的圖片壓縮技術(shù)比較能減小客戶端的容量，但是相對的，內(nèi)存讀取速度會慢一些，動畫加載時間也稍微久一點。不要說，你絲毫不關(guān)心客戶端的容量，是的，這并不影響你游戲的質(zhì)量，但是你想想如果你開發(fā)出來的一個網(wǎng)游，要別人下一個星期才能下下來，還要占掉人家一大半的硬盤，別人會不會愿意去玩？
是否研究過，針對不同規(guī)模的設(shè)計需求，使用哪一種界面控件更有效？或者是干脆就直接調(diào)用圖片？
界面與圖片一樣，如果不注意，會是一個十分占資源的東西。如果你只是一個小游戲，就那么幾個界面，那么OK，直接調(diào)圖片省事。但如果你是一個MMORPG，界面多如牛毛，此時你調(diào)圖片？那你的游戲就提前完蛋了！因為，光是加載這些界面圖片，以現(xiàn)在的內(nèi)存處理速度可能就要處理上半個小時到一個小時。這樣的游戲誰愿意玩？好吧，你說這個問題不歸你考慮，那么你讓誰考慮這個問題？你的主程序員？——他怎么知道你要用多少界面？他怎么知道你的界面與界面之間有什么關(guān)系？他怎么知道你要提供哪樣一些界面功能？然而，這些問題如果不搞清楚，就算他是比爾•蓋茨，他也不知道該給你寫或者提供怎樣一個控件！
是否研究過，客戶端程序使用哪種字體控件？或者說，設(shè)計的字體控件是否滿足游戲風格需求？
你準備讓游戲界面顯示哪種字體？宋體？——很好，你可以去做MUD了。當你看到你的全宋體字體游戲時，你可以對你的程序和表現(xiàn)策劃說說：“我希望用一種很漂亮的、很華麗的字體”，但是這個時候你的主程也許告訴你：“對不起，因為這一塊涉及到底層字體控件，要改可能會修改游戲底層，而且可能無法支持矢量字庫！”好了，一個休閑Q版游戲，只好頂著宋體（如同關(guān)羽拿著燒火棍）沖向了戰(zhàn)場。
是否熟知你們游戲的服務器以及客戶端加密格式？
這個東西也比較專業(yè)。雖然這個東西與我們游戲的可玩性關(guān)系不大，雖然即便你不加密就把你的游戲推向市場，照樣可以有模有樣的運營一陣子，可是接下來——你的游戲就會像盜版光碟一樣變得一錢不值。你的圖片也好、你的源代碼也好，完全裸露在任何一個下載了這個游戲的玩家手上?！斑@個俺確定，俺主程說他會做！”是啊，如果你主程是你鐵哥們或者是你親兄弟，你可以暫時不用擔心這個問題。可萬一人家是挖來了，或高薪聘來的，結(jié)果一公司又毫無聲息的把他給挖走了，你可就連哭都來不及——加了密，鑰匙還在他老人家那里呢！幸好，現(xiàn)在的程序員們都還比較厚道，據(jù)我了解還沒有誰是加了密不還鑰匙的，不過乘機撈一把的程序哥們我倒是見過。
對于需求，我的看法是：狹義的需求是指對項目本身的需求，就是項目需要設(shè)計出怎樣的效果、需要表達怎樣的邏輯。我剛說過，策劃不是神，而是人，所以要求策劃在開發(fā)時無所不知或者在項目開始前就對項目的所有設(shè)計環(huán)節(jié)都能一錘定音這都是不太實際的想法，何況即便策劃主觀上有這樣的能力，但客觀上很多因素都將左右項目設(shè)計需求的方向——比如：新的市場環(huán)境、新的技術(shù)因素、新的運營條件等等。所以，要想這樣去要求需求的明確性，只能是教科書上出現(xiàn)的理想狀況。但是，這并不是說需求是無法明確的——這里所說的需求是廣義的需求，除了項目的設(shè)計需求以外，更重要的是團隊需求——團隊的溝通需求、團隊的適應力需求、團隊的協(xié)調(diào)性需求、團隊的應變能力需求等等。而這些需求一旦明確，你會發(fā)現(xiàn)項目的設(shè)計需求所存在的不足，將會被團隊需求的明確所補足。比如：當你們在確定一種設(shè)計需求之前，你如果和你的策劃們坐下來，聊一聊，溝通一下，討論這個需求需不需要帶有一定的擴展性？需不需要做一個錯誤反饋接口？需不需要更多的注釋點？需不需要多層嵌套處理以應對可能出現(xiàn)的需求變化？在滿足了這種溝通需求之后，你會發(fā)現(xiàn)，設(shè)計中需求的不完善性將被徹底的暴露出來，一些可能出現(xiàn)在開發(fā)過程中的漏洞將會被很輕松的被彌補掉。
