——本文只是自己從業(yè)以來對自己工作的經(jīng)驗總結，有些方式方法可能不一定先進，但代表了我這幾年的經(jīng)驗，之后也會不定期改進。

? 一個項目立項的原因可能性非常多，有可能是公司拿到一個好的IP，也有可能是幾個負責人有個很棒的idea，亦或是老板的夢想是做一個XX類型的游戲，這邊不做過多的討論。

? 立項過程中應該包含市場調查和產(chǎn)品定位，需要分析當前市場并且預測未來市場趨勢，同時還要知道產(chǎn)品面對的對象以及這些對象應該有的特征、消費習慣等等。

2.1 核心玩法

——此處核心玩法多指核心戰(zhàn)斗，部分不存在戰(zhàn)斗的游戲未在討論之內。

? 對策劃來說，開發(fā)初期最重要的是核心玩法的確立，只有確立了核心玩法，后續(xù)的工作比如核心數(shù)值以及核心系統(tǒng)循環(huán)才能展開。

? 在初期確立核心玩法時，一定需要足夠長的時間和精力去推敲，因為如果核心玩法存在問題，意味著你盲目展開的后續(xù)工作除了美術之外都可能需要面臨很大的調整或者重做。

2.1.1 核心玩法是什么

? 在我看來，所謂核心玩法，即是一個游戲最本質的內容，是用戶花費大量時間沉侵在你的游戲的原因。

? 它是你的游戲整個戰(zhàn)斗UI界面的所有東西，包括血條、藍條、生命、攻擊鍵等，甚至還包括戰(zhàn)斗界面上看不到的技能、屬性等。

? 整體上核心玩法應該是可以用一句話來概括的游戲規(guī)則，譬如《QQ飛車手游》的核心玩法就是競速，駕駛不同特性、維度的賽車先到達終點的玩家獲勝；而《王者榮耀》，《英雄聯(lián)盟》的核心玩法應該是控制不同技能的角色摧毀敵方水晶。

2.1.2 如何確立核心玩法

? 核心玩法往往是基于立項所要做的游戲方向、IP、題材等因素分析該類型的游戲核心點后歸納、提煉后再由策劃內部多輪討論——推翻——再討論后得出的。

? 核心玩法會根據(jù)團隊內部實力、經(jīng)驗等因素方向也會有所偏向；2D或3D，寫實或Q版都會有所講究。

? 拿我們之前做的定制IP的游戲來說來說，在拿到這個IP的時候我們是需要根據(jù)IP適合改編的游戲類型去建立的，在決定做ARPG的時候我們就需要根據(jù)市面上的ARPG分析，去決定我們的ARPG是橫版/豎版、操作機甲/適格者、追求像真三割草式或者是火影忍者那樣連擊式、通關條件的等等各方面在戰(zhàn)斗界面出現(xiàn)元素的建立。

? 記住，任何出現(xiàn)在你界面上的元素都是應該有存在價值的，否則就意味著它有可能被刪掉，被別的部門、老板或是玩家，刪掉意味著這部分的工作全部=0。

2.1.3 其余工作

? 在策劃內部討論通過之后或者在討論之時就會叫上前后端主程和主美一起討論。切記控制會議人數(shù)，人數(shù)太多很容易導致結論難產(chǎn)。

? 所以私以為項目組在前期招聘時應盡快落實策劃團隊，而程序美術有核心成員就足夠了。

2.2 Demo

? 在確定核心玩法之后應該盡快完成Demo，Demo只要包含最核心的玩法或者是最核心的游戲體驗，不需要過多的制作方式和制作規(guī)范限制，不需要華麗的畫面或者完善的數(shù)值。

? Demo的作用是驗證策劃前期討論的核心戰(zhàn)斗是否可行：例如ARPG有幾個技能、大招釋放是減少藍量還是攢怒釋放、橫版3D還是斜45°等等問題，亦或是在回合制游戲增加主動手操、瞄準滑動等操作，這些都是策劃討論出來未經(jīng)驗證是否可行的想法。

? 在Demo階段應完成對核心玩法的驗證，團隊內部應該討論確定這個方向可行或者不可行，不可行—重做—驗證直到可行或者推翻重頭來過。

? 在Demo完成占大多數(shù)團隊成員認可這個Demo方向之后，此時作為PM應根據(jù)項目現(xiàn)有情況以及外部因素等多種情況規(guī)劃好整個項目的開發(fā)周期以及各階段的初步開發(fā)時間，以及下一階段（即原型階段的詳細開發(fā)周期以及優(yōu)先級）。

? 大體上真正的項目開發(fā)應該會有3~4個階段：原型階段——核心階段——迭代階段——調整階段（這里并不包括刪檔測試以及之后的系列測試），后期再根據(jù)游戲框架以及核心開發(fā)內容細分階段。

4.1 原型階段

4.1.1 世界觀&題材

——此部分指的是包含世界觀的游戲。

? 好的游戲應該包含相對完整符合邏輯的世界觀，一個完整的世界觀可以幫助策劃更好的完成設計，知道什么樣的設計應該有什么樣的設計不應該存在，譬如：三國的世界觀出現(xiàn)機甲或者冷兵器時代的故事背景出現(xiàn)手槍。

? 世界觀應包含：故事背景、人物設定、經(jīng)濟&能力水平等等，可以理解為是一個小型的小說框架。

4.1.2 游戲框架

? 在核心玩法建立后，策劃內部應該對建立初步的游戲框架，包括系統(tǒng)框架、數(shù)值框架（主要為核心玩法數(shù)值）、主要玩法設計等一系列大綱。

? 完整的游戲框架應該包含明確的設計目的以及重要程度和階段目標以便于安排版本計劃。

? 此處的游戲框架只是一個雛形，打算做一個XX系統(tǒng)，這個系統(tǒng)的定位是什么，目的是什么以及與程序制作相關的初步的完成方式（實時or離線、幀同步or狀態(tài)同步等），為了盡快推進到下一階段而不應該包括比較詳細的系統(tǒng)設定。

4.1.3 程序

? 程序需要根據(jù)策劃的游戲框架提取技術難點，并且根據(jù)團隊的現(xiàn)有實力，選擇對應開發(fā)語言以及所用的程序編寫工具，搭建開發(fā)環(huán)境和底層框架。

4.1.4 美術風格&制作標準

? 而美術則需要根據(jù)策劃提供的世界觀，以及第一版的需求文檔，確定美術風格以及制作標準。

? 制作標準需要程序、策劃和美術的共同討論得出，在制作上需要兼顧性能、性價比以及感觀接受度等方面的因素，通常會采用重要的部分或者付費系統(tǒng)采用精度或者完成度較高的美術表現(xiàn)，而比較不重要的部分則會采用簡單精致的美術表現(xiàn)。

4.1.5 開發(fā)準備

? 通常程序會協(xié)助項目其他成員完成開發(fā)所用的客戶端/服務器搭建以及SVN服務器地址的搭建，也需要決定項目采用的版本管理工具（包括任務以及BUG等）。

? 主管級別的崗位也需要配合制作人在開始就明確項目的開發(fā)流程，包括模型、動作、UI等美術資源的提交流程，預制體的制作規(guī)范，任務、BUG的流程，美術資源、策劃資源在工程的存放規(guī)范，美術資源、策劃配置表命名規(guī)范等問題。

? 如果你的項目還打算在海外發(fā)布，則還需要考慮海外版本的轉化，海外資源的存放路徑及規(guī)范問題。

? 還是那一句話：流程可以精簡，但絕對不能省略！

4.2 版本計劃該更新了

? 游戲框架有了，知道了游戲大概需要的開發(fā)內容，相比初期毫無根據(jù)的版本計劃，此時應該能夠列出一套較為完整的版本計劃，應該包括初步的每個階段應該完成的核心內容以及次級內容，以及可能預估到的項目延期及緩沖時間。

? 只是因為此階段游戲的核心開發(fā)內容的不確定性，所以只能給每個階段定一個大致目標和開發(fā)周期。

4.3 核心階段

4.3.1 開發(fā)重點

? 核心玩法確定后，策劃應該可以從這個核心玩法中提取幾個關鍵詞，而這幾個關鍵詞就是接下來游戲開發(fā)周期的核心工作內容。

? 這幾個關鍵詞將決定游戲開發(fā)的重心偏向以及人力分配，一般來說這幾個關鍵詞分別對應：基礎戰(zhàn)斗（核心玩法）、玩法深度、核心系統(tǒng)循環(huán)以及核心數(shù)值。

? 每個關鍵詞都會包含很多工作項內容，確定開發(fā)重點可以讓PM更好的進行周期安排和人員重點分配。

4.3.2 基礎戰(zhàn)斗

? 常見的游戲都會有戰(zhàn)斗場景，只是重要性和復雜程度的不同。

? 動作類的游戲基礎戰(zhàn)斗顯得極為重要，往往要在基礎戰(zhàn)斗中下很大的功夫去調試，而且步驟環(huán)環(huán)相扣，如果前面的環(huán)節(jié)沒有調整好，往往會導致后面環(huán)節(jié)的工作混亂，找不出問題所在。

? 動作類游戲往往十分強調打擊感，這就跟看電影喜歡去電影院看IMAX因為從視覺、聽覺上來說都會有不一樣的沉浸感。

? 以 ARPG游戲為例，ARPG游戲的基礎戰(zhàn)斗往往要先從移動、鏡頭開始調試：

l 移動是否需要增加慣性？慣性需要多大？

l 移動時鏡頭是否跟隨？

l 移動到場景末端時鏡頭是否繼續(xù)跟隨移動？

l 轉向時鏡頭是否移動？

這些可以在紙上形成方案，但是要想做得好都是需要在場景中一步步調試出來的。

? 在基礎的移動、鏡頭等調試到一個相對舒服的體驗之后再加入普通攻擊、攻擊轉向等等，調試完畢后再不斷加入譬如：動作拆分、動作取消、skill01_end接skill02（或者skill02_start）動作銜接等功能。

l 例如多個動作斜接就需要調整前置動作的收招，既保證動作看起來足夠自然，又要保證玩家觸覺與視角的一致性，即按鍵即響應。

? 再往后再加入更加高階的操作和表現(xiàn)來提升真實感和表現(xiàn)力，譬如受擊表現(xiàn)、特效、音效等。

4.3.3 核心玩法

? 基礎戰(zhàn)斗是核心玩法的基礎，相對于基礎戰(zhàn)斗實打實的調試，核心玩法更多是設計項的內容。

? 如果說《英雄聯(lián)盟》的核心玩法控制不同技能的英雄摧毀敵方水晶，那么控制角色摧毀水晶是基礎戰(zhàn)斗，核心玩法設計即是不同技能的英雄設計。怎么樣設計豐富、有趣、互動性強、成就感鮮明的技能來讓玩家在長期的重復競技中保持樂趣就是重中之重，當然還會有召喚師峽谷的策略，裝備，符文等一系列的系統(tǒng)來充盈保持樂趣的目的，但這些都屬于玩法深度的內容了。

4.3.4 玩法深度

? 一個游戲往往需要玩法來滿足玩家對于策略、技巧、時機、深度等多方面的追求。例如：格斗游戲常見的爆氣是滿足對于時機的追求，《QQ飛車手游》漂移以及雙噴、WCW噴、斷位漂移等則是滿足玩家對于技巧的追求，而《英雄聯(lián)盟》的符文則是滿足了玩家對于策略的追求。

? 一個好的游戲一定要給玩家足夠多的思考或者追求空間，玩家在游戲中的時長越長，積累的經(jīng)驗技巧越多，越容易幫助玩家獲得勝利，這樣玩家才會持續(xù)留在游戲。

? 游戲深度是從核心玩法中延伸出的某個針對性的玩法設計用以滿足玩家對于某方面的長線追求。

4.3.5 核心系統(tǒng)循環(huán)

? 養(yǎng)成系統(tǒng)的存在通常可以滿足之前所說玩家對于玩法深度的多種要求、增加用戶粘性，同時階段性的成長不僅可以給玩家?guī)黼A段性的目標、成就/驚喜/新鮮感，同時也是拉長游戲生命周期、增加營收/活動投放的重要部分。

? 所有系統(tǒng)養(yǎng)成的目的都應該回執(zhí)于核心戰(zhàn)斗，但不一定是回執(zhí)于核心數(shù)值，因為也有可能部分養(yǎng)成只是單純的回執(zhí)于戰(zhàn)斗表現(xiàn)。

? 核心系統(tǒng)循環(huán)通常與核心玩法、玩法深度息息相關，因為只有在游戲最重要的地方增加養(yǎng)成和付費，才會獲得更多玩家的投入，不管是時間還是金錢。

? 通過玩法【產(chǎn)出】→養(yǎng)成【消耗】→玩法【驗證實力/產(chǎn)出】構建的閉環(huán)，可以讓玩家不斷追求游戲所設計的內容。

? 而系統(tǒng)的設定通常多種多樣，不同時期玩家對游戲的理解水平不同，學習成本也不相同，最終設計的系統(tǒng)滿足你的設計目的就是一個好的系統(tǒng)。

4.3.6 核心數(shù)值

? 核心數(shù)值分為戰(zhàn)斗數(shù)值和經(jīng)濟數(shù)值，數(shù)值服務于系統(tǒng)和玩法，根據(jù)系統(tǒng)和玩法的需求提供對應的游戲體驗。

? 戰(zhàn)斗數(shù)值往往是根據(jù)戰(zhàn)斗體驗、理解成本和數(shù)值可控性等多方面決定的。

? 而經(jīng)濟數(shù)值除了根據(jù)游戲內部因素外還需要根據(jù)游戲的生命周期進行時間與定價的轉換，花1RMB=X 戰(zhàn)斗力= 時間，即時間——價值——戰(zhàn)斗力。

4.4 版本計劃該更新了

? 有了游戲框架，知道了開發(fā)重點，在進入正式迭代前應該制定好詳細的版本計劃。

? 此時的版本計劃應該分為兩部分：

4.4.1 整體計劃

? 根據(jù)此時項目的整體情況以及各種外來因素確定游戲上線的最終期限。

? 根據(jù)最終期限計劃好每個版本的最終開發(fā)期限、核心目標以及次級目標。

? 不要對自己和團隊過于自信，制定整體周期的時候給每個版本增加適當?shù)木彌_時間以防止意外情況發(fā)生，而且是一定會發(fā)生意外情況。

4.4.2 周期計劃

? 制定詳細的工作條目，包括各部門成員需要完成的工作條目，任務優(yōu)先級，該條目負責人，以及通過時間安排來體現(xiàn)條目的制作流程。

? 增加緩沖時間以及延期記錄，便于安排進下個版本，同時也可以重新評估某個成員的能力。

4.5 開發(fā)規(guī)范

? 開發(fā)過程中很多工作往往是并行的，在開發(fā)初期定義開發(fā)規(guī)范可以節(jié)省在開發(fā)過程中很多不必要的返工和混亂。

? 還是要說一句，這些是我的經(jīng)驗總結，項目不同有些經(jīng)驗也不適用，而且肯定也會有更先進的開發(fā)經(jīng)驗，僅供參考。

4.5.1 任務&BUG流程

? 任務首先由制作人（或主策）創(chuàng)建，之后由主策分配給對應的負責人編寫策劃文檔，在策劃文檔驗收通過后創(chuàng)建程序、美術兩個分支分別指派給對應主程、主美，由主程、主美決定是否要拆分并分配下去并附上驗收時間，由對應的執(zhí)行人負責完成任務。

? 任務創(chuàng)建人

l 之所以由負責人創(chuàng)建任務一是節(jié)省主程、主美時間，更重要的是任務完成后需要負責人了解清楚并且驗收，中間省去一些步驟。

? 優(yōu)先級

l 任務和BUG的創(chuàng)建除了基本的元素之外，包含優(yōu)先級會讓解決人更好的安排工作，也可以在版本節(jié)點讓PM更清晰的明白任務量。

? 解決版本/驗收時間

l 解決版本/驗收最后時間的加入可以讓測試明確知道該版本需要驗收的內容，同樣也可以在版本節(jié)點讓PM更清晰的明白該版本延期內容以及下版本需要額外增加的工作內容。

? 備注

l 備注可以讓執(zhí)行人即使不在也可能不需要聯(lián)系執(zhí)行人其他人員也能了解大概情況。

4.5.2 程序字

? 工程中最好有一張表用于管理一些只是說明并沒有實際用途的程序字

? 如果你的項目打算做多語言版本，同樣也需要一張程序字表，在項目開始的時候就把所有的程序字提取出來是最好的辦法，后期再做一來工作量大，二來容易遺漏。

4.5.3 美術資源存放規(guī)范

? 這一塊規(guī)范一般會以程序作為主導，除了最基本的同類型文件存放規(guī)范外，一般UI資源會將動態(tài)加載資源與靜態(tài)資源分開存放，優(yōu)化IOS性能開銷的同時因為動態(tài)加載資源會經(jīng)常批量替換，單獨存放比較好管理。

? 在開發(fā)過程中UI可能會替換好幾版資源，如果美術資源存放規(guī)范可以在替換的過程中節(jié)省很多時間并且減少很多沒用的美術素材，在需要剔除無用素材時也會更便于查找。

? 在做海外版本時也會涉及到資源替換（內嵌式多語言則涉及資源存放）也會需要大量的資源替換，好的規(guī)范可以節(jié)省時間。

4.5.4 預制體制作

? 預制體同樣需要一張表格來管理和查閱各預制體。

? 預制體的制作規(guī)范也是極其重要，這會讓你的界面從工整和統(tǒng)一性方面看出很明顯的差別。

? 在制作界面時，在美術風格定版后，策劃和UI應該共同制定一套界面用字規(guī)范，包含幾種類型的標題、正文、說明文字、強調文字所用色值和大小等規(guī)范，在拼界面時應該嚴格執(zhí)行規(guī)范，包括程序字也同樣需要遵守。

? 要做好界面，在從UI出效果圖到界面拼接都應該嚴格遵守統(tǒng)一性的原則，甚至要求界面拼接通過臨摹的方式實現(xiàn)。

? 在制作的同時應該盡量考慮到界面的復用性，將一些界面通用化并提取成單獨的預制體采用調用的方式實現(xiàn)。

4.5.5 配置表&模塊編號

? 配置表本身有一定的規(guī)范限制，在配置表命名之后增加中文注釋可以讓別人更容易找到需要的配置表。

? 同時在制作功能模塊配置表時應給每個模塊定義一個唯一的模塊編號，用一張獨立的模塊表維護，用于做模塊之間的索引，同時便于管理并且與程序定義統(tǒng)一性。

? 同時配置表應該增加一條索引表，用于注釋配置表之間以及系統(tǒng)與配置表之間的關聯(lián)性。

? 定義配置表字段時應嚴格定義字段使用者，一味的貪圖方便都使用cs會給后期辨別增加很大麻煩。

4.5.6 命名規(guī)范

? 好的命名規(guī)范可以節(jié)省開發(fā)過程中不必要的時間浪費，美術資源命名、模塊命名、配置表命名甚至是配置表中的字段命名都應該做到盡量強的辨識度。

? 如果周期允許，應該在前期盡量做好模塊的英文命名，保持開發(fā)的統(tǒng)一性語言。

? 設想一下，地圖命名一種方案是根據(jù)制作順序從map001~map100依次命名，另一種方案則是map_city_001，很明顯第二種方案能夠區(qū)別出地圖是城市還是農(nóng)村等等，這邊只是一個簡單的例子，會根據(jù)項目不同有不同的講究。

? 比如配置表命名增加模塊編號便于分類查找，增加中文注釋便于理解；場景地圖增加風格編號、模塊編號等等。

? 一般來說策劃應該做好命名規(guī)范，而美術或者程序內部可以簡化命名節(jié)省時間，但是到最后提交到項目工程的時候需要保證命名與規(guī)范是一致的。

? 另外有一個統(tǒng)一并且執(zhí)行下去的命名規(guī)范，對于開發(fā)人員查找也會帶來極大的便利。

4.6 迭代階段

? 如果項目順利過渡了前面的階段，現(xiàn)在有了制作標準，有了開發(fā)規(guī)范，還有了明確的方向和制作方法，該把以上的內容變成一個完整的游戲了。

4.6.1 快速迭代

? 在初期定義好制作標準和游戲方向后，在迭代階段往往是快速的生產(chǎn)過程。如果初期定義好的規(guī)范有執(zhí)行下去，對于這個階段應該會省掉很多的工作量和溝通解決成本。

4.6.2 總結

? 在每個版本結束后留一段時間，用于總結一下在這個階段碰到的問題并及時討論解決，同時看看目前的產(chǎn)品，存在什么問題，有什么不足的地方。然后在下個周期安排改進流程和產(chǎn)品，動態(tài)的調整每個階段的目標。

4.6.3 策劃先行

? 其實策劃先行應該是貫穿項目開發(fā)的整個階段的，但是在迭代階段顯得猶為重要，每個階段保證策劃工作至少提前一周，這樣既可以讓策劃內部有規(guī)劃意識，也可以保證其他部門在任務量提前做完的時候可以有一部分提前量，同樣也可以防止突發(fā)變化導致某部分功能不開發(fā)的時候不至于無事可做。

4.6.4 迭代原則

? 因為游戲不是每個系統(tǒng)都是獨立的存在，合理安排好迭代順序也可以節(jié)省一部分“暫代開發(fā)”的時間，同時也會讓整個開發(fā)更合理、規(guī)范。

? 基礎優(yōu)先，核心優(yōu)先

l 大模塊遵循基礎優(yōu)先，核心優(yōu)先，基礎功能做好才能往上疊加功能，而核心功能的開發(fā)往往是貫穿整個開發(fā)前中期的，需要長期的思考和沉淀。

? 關聯(lián)系統(tǒng)

l 關聯(lián)系統(tǒng)可以安排在同期做或者按玩游戲流程的先后順序做，這樣不至于導致一個功能完成后可能都不能完成測試亦或是無法構成循環(huán)，而再之后返回來有可能部分結構已經(jīng)遺忘了。

? 通用模塊開發(fā)

l 開發(fā)中有很多系統(tǒng)涉及到的彈窗或者提示往往在其他模塊也需要用到，需要協(xié)調好避免重復開發(fā)或者混亂使用；當然也可以將通用模塊單獨作為一個小開發(fā)項排進版本。

? 當然版本計劃會有很多不確定性和針對性，以上只是基本安排思路，實際還是需要根據(jù)項目本身去做合適的排期。

4.7 調整階段

? 當項目過渡完迭代階段時基本上所有的功能開發(fā)完畢游戲有一個完整的生態(tài)循環(huán)，如果運氣好在項目上線測試前還會有時間進行測試調整，主要針對包體大小的資源精簡；游戲的性能優(yōu)化以及對BUG的深度測試，譬如規(guī)則漏洞導致的刷分，以及程序通信漏洞導致的刷獎勵。最常見的通過截包后重復發(fā)包、修改包大小等方式重復發(fā)包欺騙服務器獲得多次或者更高額的獎勵。

? 而對于游戲本身的調整和優(yōu)化則是貫穿整個游戲開發(fā)周期的，在臨近上線階段再做大規(guī)模的調整

4.8 測試階段

? 測試如果順利會分為多輪測試，通過每輪測試的數(shù)據(jù)針對性的調整資源投放以及關卡難度，調整新手引導難度節(jié)奏，調整玩家每日在線時長以及各功能占比。

? 而上線前準備同樣還有很多細微的事情需要處理，例如版號過審、游戲名稱以及ICON、游戲資料等需要提供給運營游戲相關資料以做準備。同樣也有可能需要增加部分運營活動在游戲上線初期保證最大化的營收。

4.9 尾聲

? 因為工作的關系，前后花了不少時間去寫這一份總結，所以斷斷續(xù)續(xù)的，有些地方可能接不上或者不夠嚴謹，本來是打算離職后專心去寫的。

? 很多說法不一定對或者不夠先進，但是代表自己對開發(fā)的理解，之后也會抽空給自己多點時間去改進總結。

? 對于怎么做的總結也許偏少，可能以后會單獨總結。