策劃體驗遊戲和掌握策劃技能這兩者不沖突。
策劃應該怎麽玩遊戲
玩遊戲建議確定兩種就行。
一種是偏單機化的產品。
一種是有完整產出消耗迴圈，以及pvp和gvg的產品。
至於產品本身是slg、mmorpg，或者是卡牌回合制
——這些具體品類其實不重要。策劃玩遊戲應該提煉通用設計思路而不是簡單copy內容。
策劃應該掌握的技能
技能其實沒有多少可以學的。
我大概列舉了一些，可能有缺少的部份，但是基本上完整。
需求文件
預期目標、功能簡介、系統概述、UI互動、數值或產出規劃、數據埋點需求，視情況可以加入驗收過程和最佳化記錄。
axure
產品原型圖。可以最終生成一個html檔，給到ui和客戶端一個非常直觀的界面需求互動過程。
流程圖
其實這個是需求文件裏需要涵蓋的內容，但並非每一項功能文件都需要用到。視功能情況復雜，傾向於讓伺服端理解策劃的功能判斷邏輯。
數值驗證
透過Excel的函數模擬戰鬥過程，尤其是新增了pve關卡後。這個如果不會，也可以用最笨的辦法。在內部測試服裏模擬當前玩家外網的實際帳號強度，去生成一批內網測試角色，自己實際打一遍增加的pve關卡，驗證難度是否合理。
產出和消耗關註
這個主要透過後台或者伺服端logo日誌去做整理分析。很多遊戲敗就敗在消耗崩了但是不自知。
美術需求
這一塊涉及角色、場景、特效、建築、原畫模型等。但其實一般來說角色模型和場景（地圖）需求是大頭。因為這裏面涉及到需要用到多少具體動作模組。比如受擊、倒地、普通攻擊、技能施放、受傷反饋等。但這些模組並非每個專案都需要全部用到。但一旦框架確定後，美術成本就無可避免需要在一開始定義的框架上疊加，
而場景（地圖）需求，玩家或者理解粗淺的從業者會不理解，為什麽率土like跟二次元開放世界遊戲都屬於「沙盒遊戲」，因為兩者的地圖需求都是其重點，雖然前者服務於戰鬥策略，後者服務於地圖探索及劇情，但是兩者共同點都是地圖需要有非常龐大的路線分支以及巧妙的策略或劇情觸發點。
剩下其他環節的美術需求，無非就是需求描述以及尋找參考物件上。
思維導圖
這個是用於拆解遊戲。但實際上是傾向於給自己找出分析一個遊戲應該關註的內容先後順序以及重點。對於閱讀者來說，這並不是太友好的東西。
客戶端預制使用和維護
現在主流客戶端引擎應該還是unity。如果專案組有TA（技術美術）會幫你分擔部份事情，但是沒有的話就需要策劃自己動手，沒辦法指望非TA的美術能夠幫忙將資源匯入進遊戲。如果讓客戶端匯入……看策劃個人的溝通能力吧。但是至少一些關卡如果是透過預制拼接的話，那策劃自己需要掌握關於前端引擎如何維護的基本操作。
配置表結構
這一塊單獨拎出來的意義不大。因為功能文件編寫過程足夠清晰的話，配置表其實不會淩亂。但是實際操作中，很多策劃的配置表依舊是七零八落，需要中途進行各種補全，甚至由於多個人交叉維護，還會出現檔彼此覆蓋的低階情況。這些其實更多不是考驗能力，而是責任心（比如逢送出前，請務必先更新本地SVN）。
ABTEST驗證
這個主要是驗證核心系統是否符合預期而作的一種驗證方式。但由於很多公司並不知道什麽是abtest。很多功能直接就由專案組憑感覺和經驗就直接放出去，QA沒有驗收出bug就全服更新同步。但是結果做出來的東西很可能是負最佳化，結果遊戲就因為自己的更新給做崩了。
結語
這些技能如果要入門，三到五個月就可以從0~1了。
但如果要精通，我意思是指「指哪打哪」做什麽都符合市場預期的那種，那很抱歉，我不覺得有策劃能說自己的產品必定能成功，如果遇到打包票能成功的，基本上都是：
——我偏不說 是什麽 ？主要懂的都懂。
可能會有人覺得我說的很粗淺。
但是我主打一個有來有回，有人看我再針對性做補充。
沒人看我還不如繼續寫段子自娛自樂呢。
