策劃怎麼做：遊戲開發如何量化（商業化向）

【前言】

我們將研發分爲四個階段：立項、開發、測試、上線，這四個階段分別需要採用一些開發製作方法來確保項目的成功率，我們將其羅列量化，用來指導各項目組開發。

下文主要針對立項、開發、測試三個階段。
以下內容主要針對商業化遊戲，對於獨立遊戲來說並不適用，但多瞭解一下也是好的。

【立項調查】立項階段

從市場調查中找到了“用戶需求”和“自身的產品差異化”嗎？（A、調查非常清楚和準確；B、比較清楚和準確；C、一般清楚和準確；D、完全沒找到；）
- 闡述你做了哪些調查以及調查結果
- 方法建議：
  - 瞭解產品，通過App Store、Google Play、TapTap、硬核聯盟、應用寶等渠道排名定位需要了解的產品；
  - 分析市場，通過收集到的信息，分析市場行情、發展趨勢、品類數量、玩法特點、收入規模、排名變化等；
  - 分析報告，通過網絡收集近幾年的產品調查和分析報告；
  - 日常關注，通過包括但不限於以下幾個網站，瞭解最新的行業和產品動態、資訊：小黑盒、騰訊開發社區、遊戲大觀、遊戲陀螺、173等等（網站更新頻繁，不一一列舉）。
  - 總結提煉，通過這些信息發現這類產品市場規模、用戶需求、產品特色、產品差異化等。
  - 產出報告，針對你想做的產品做出詳細的“市場調查報告”，這個將作爲你產品方向決策的依據之一。
- 評估建議：
  - 調查報告的內容是否全面詳盡；
  - 調查報告的結論是否有數據支撐；

找到了用戶喜好和特點嗎？（A、用戶喜好和特點非常清楚和準確；B、比較清楚和準確；C、一般清楚和準確；D、完全沒找到；）
- 羅列和描述你找到的用戶喜好和特點，並加以說明
- 方法建議：
  - 體驗產品，和玩家們打成一片，深入玩家羣體；（非常關鍵）
  - 日常記錄，日常遊戲體驗和感悟隨手記錄；（非常關鍵）
  - 關注論壇，關注包括Steam、TapTap、App Store、Google Play、九遊論壇、各大渠道論壇；
  - 關注社羣，關注遊戲論壇、遊戲評價、遊戲微信羣（QQ羣）、貼吧等玩家的留言和討論內容；
  - 提煉總結，通過但不限於以上方式，提煉總結出來這些玩家的需求、喜惡、共性；
  - 產出報告，通過以上方式製作出“用戶調查報告”，這個將作爲你產品設計思路的參考決策依據之一；
- 評估建議：
  - 找到用戶喜好和特點的條目數量；

這個產品有競爭力嗎？（A、很有競爭力；B、比較有競爭力；C、有些競爭力；D、完全沒競爭力；）
- 將競品與自己產品進行橫向對比
- 方法建議：
  - 體驗競品，深度體驗同類爆款競品，理解這些遊戲的核心玩法體驗；
  - 分析競品，自己分析競品，或通過各種渠道尋找競品的分析報告；
  - 關注社羣，關注遊戲論壇、遊戲評價、遊戲微信羣（QQ羣）、貼吧等玩家的留言和討論內容；
  - 橫向對比，將這些競品與自己的產品設計進行橫向對比，分析出優劣和差異化；
  - 產出報告，通過以上方式製作出“競品分析報告”，這個將作爲產品方向確定、設計思路的參考決策依據之一。
- 評估建議：
  - 橫向對比分析的內容細緻程度（對比產品數量、對比項數量、內容豐富度等）

有自己的特色和亮點嗎（有創意嗎）？（A、很有特色和亮點；B、比較有特色；C、有一些特色；D、完全沒特色；）
- 闡述你產品的特色和亮點，最好能用一句話描述出來，然後說明爲什麼你會定義這個爲你的產品特色
- 方法建議（示例）：
  - “修仙XXXX”，最大特色是：按照休閒小說原樣打造（開啓修仙新模式）；
  - “氪金網友XXXX”，最大特色是：快速升級，直接PK（一刀999級）；
  - “我的世界”，最大特色是：超高自由度，打造任何你能想象出來的世界（我就是創世神）；
  - 參考以上案例定義出來自己產品的核心特色和亮點；
- 說明：遊戲特色，也是遊戲的最核心的賣點之一，是吸引用戶關注並進入產品的利器。我們在明確這個特色時，不僅要從核心目標用戶羣的本質需求出發，還要知道如何利用這個特色吸引玩家加入。

風險預測和解決思路靠譜嗎？（A、評估和對應解決方案很完善；B、比較完善；C、不怎麼完善；D、沒考慮）
- 講述你們對團隊和項目的風險預測，以及提出你們的解決思路，也可以提出尋求幫助

方法建議：

以月爲單位定期進行風險評估，並尋求幫助。
風險包括：
- 遊戲策劃的設計方向
- 團隊的完整性和穩定性
- 市場變化
- 美術風格市場接受度
- ……等等
如何定位風險？
- 調查，通過市場調查、競品分析瞭解更多產品和市場動態；
- 提問，通過提問法從玩家、運營、渠道等多個角度提問並解答；
- 溝通，通過公司立項評審會等方式多找人溝通和指導建議；
- 驗證，通過核心玩家試玩、工具檢驗、數據驗證等方法驗證；

評估建議：
- 風險預測以及解決思路的條目數量

【遊戲設計】立項階段、開發階段

一句話描述這個遊戲玩什麼？（A、玩法非常有趣好玩；B、玩法比較有趣；C、有點意思；D、沒什麼樂趣；）
- 一句話描述的遊戲的核心體驗
- 方法建議：
  - 用第一性思考的方法提煉出來你的核心體驗
  - 用模型化方法構建體驗內容
  - 核心玩法的爽點是什麼？玩家會因爲什麼沉迷？
  - 核心追求是什麼？
  - 目標感很強？
  - 策略性足夠豐富嗎？
  - 自由度很高？
  - 表現力很強？

遊戲設計規劃是什麼？（A、規劃十分清楚； B、比較清楚； C、不夠清楚； D、沒有規劃；）
- 講述你們這個版本爲何如此規劃，想要達到什麼目的？

方法建議：
- 統籌、規劃、設計，都需要先宏觀、再微觀。
- 遊戲設計的思考，首先要考慮用戶的本質體驗。
- 有設計遊戲全局性的系統框架嗎？

玩家的成長感規劃了嗎？
遊戲的系統定位有說明嗎？
遊戲的資源產銷關係有梳理清楚嗎？
遊戲的功能開啓節奏有梳理清楚嗎？
遊戲的玩法活動時間有規劃清楚嗎？
有將遊戲的爽點和體驗感受描述出來嗎？
這些規劃是圍繞遊戲的核心玩法和體驗來進行的嗎？
有從玩家、運營、渠道的角度不斷給自己產品提問嗎？

評估建議：

從方法建議的問題中是否找到答案

遊戲特色是否爲核心體驗服務？（A、遊戲特色和核心體驗非常貼切；B、比較貼切；C、有些關係；D、完全沒關係；）
- 方法建議：
  - 核心玩法哪些點是直接或者間接突出遊戲特色的？
  - 世界觀背景是圍繞核心體驗和玩法而設計的嗎？
  - 系統定位是圍繞核心體驗和玩法而設計的嗎？
  - 商業化包裝思路符合他的核心玩法嗎？

遊戲有自運營能力嗎？
- 方法建議：
  - 商業化活動內嵌到遊戲裏變成系統玩法和功能。
  - 自動循環和自動調整的商業化活動功能。
  - 人工智能自動識別用戶需求，同時智能推送對應的玩法、商品、提示、攻略等。
  - 智能客服可以7*24小時解決用戶疑問，無需人工客服。
  - 建立健全的用戶反饋流程和機制，促使用戶自動自發的反饋遊戲問題。
  - 遊戲內建立類似論壇、貼吧式的功能供玩家參與討論。
  - 在遊戲內做好完善的埋點數據收集。

【美術設定】開發階段

美術品質高嗎？
- 方法建議：
  - 畫面中材質效果是否明顯？
  - 是否區分了金屬皮革石頭等基礎材質的特徵？
  - 是否有適當的HDR暈光效果？
  - 角色模型質量是否高級？
  - 場景模型質量是否高級？
  - 有沒有不同區域的光影區分？
  - 有沒恰當的陰影光照？
  - 是否有環境效果？（落葉打雷下雪腳印角色走過草地被踩雪地留下腳印等等）
  - 是否有日夜交替光照系統？
  - 是否有物理系統？
  - 低中高配置切換後畫面是否有明顯的區別？
- 評估建議：
  - 從感官上判斷是否好看
  - 從方法建議的問題中是否找到答案

美術製作規範嗎？

方法建議：
- 是否做到人景分離，突出角色？
- 角色在場景中是否有瑣碎的複雜結構？
- 角色與場景物品的比例是否合適？
- 場景樹木或高模是否遮擋角色？
- 裝飾物是否過於誇張以至於喧賓奪主？
- 角色和場景風格是否統一，是否有違和感？
- 角色外形進階是否明顯？
- 特效是否過於搶眼？
- 長時間玩遊戲是否有視覺疲勞感？
評估建議：
- 從方法建議的問題中是否找到答案

美術有風格和特色嗎？
- 方法建議：
  - 在不個性的前提下是否有眼前一亮的風格展現？
  - 是否有性格鮮明的角色怪物設計？
  - 角色怪物的戰鬥方式是否有特色？
  - 角色死亡是否多樣化？
  - 角色怪物的動畫是否個性鮮明？
  - 特效是否與青果早期產品一樣？
  - 你身邊的朋友玩這種風格類型的遊戲多嘛？
  - 這種風格味道做的純正嘛？還有繼續提升的空間嘛？
- 評估建議：
  - 從感官上判斷是否有特色
  - 從方法建議的問題中是否找到答案

【程序開發】開發階段

客戶端：

玩起來卡嗎？
- 方法建議：
  - 幀率是否平穩？
  - 所有可運行的手機設備幀數控制在25幀以上？
  - 場景的D數量是否超標？
  - 角色的骨骼數量是否超標？
  - 是否擺放了大量場景特效？
  - 是否出現了大量全屏特效？
  - 場景小物件擺放是否過多？
  - 加載全部使用異步加載
  - Code-Review是否發現有新的導致卡頓的情況
  - 是否有重複使用GetHeight的情況
  - 技能釋放過程，人物和怪物創建過程可以平穩完成
  - 切換場景能快速啓動讀條，讀條時間不超過5秒（Dod除外）
  - 玩起來發熱耗電嗎？
    - 是否進行過多人同屏測試發熱的問題
    - 遊戲能否持續進行2小時不充電
  - 內存峯值是否安全？
    - 使用內存用量曲線監控內存使用情況
  - 同屏顯示是否超標？
    - SceneD數量是否超標
    - MD數量是否超標
    - 粒子數量是否超標
    - 粒子D是否超標
    - alpha疊加顯示是否金燦燦
  - 是否進行垃圾回收？
    - 沒有純用於計算的臨時變量，應使用全局變量
    - 平跑沒有引擎變量數量變化

遊戲穩定嗎？
- 方法建議：
  - 消耗流量嗎？
  - 使用流量監測工具檢查多人環境下流量並提供數據
  - 基本邏輯是否正常？

遊戲包體夠小嗎？
- 方法建議：
  - 圖片是否壓縮，安卓版本除透貼資源以外轉ETC？
  - 出版時，是否將Bmp格式轉爲JPG，是否將TGA格式轉爲1/4的PNG？
  - 音頻是否壓縮？
  - 視頻是否壓縮？
  - 是否使用貼圖合併技術？
  - 是否不同設備使用不同的紋理貼圖，分層顯示？
  - 貼圖是否使用2的n次冪大小？
  - 是否祛除多餘的alpha通道？
  - 是否採用分包的方式？
  - 是否採用靜默更新的方式？
- 評估建議：
  - 初始包體ARPG類在200M左右，非ARPG類在100M左右；

服務端：

服務器架構合理嗎？
- 方法建議：

擴展性高嗎？
可維護性高嗎？
是否有設計服務器架構圖？是否清楚的說明服務器結構、進程模型、網絡結構、數據庫、緩存等模塊？
是否有設計重要功能流程圖？是否清楚的說明網絡通信流程？
是否有設計服務器水平擴展模型？是否清楚的說明是滾服模式還是大服模式？是否可以快捷的新增和替換服務器？
是否有服務器單點故障問題？如果有，是否有快速解決方案？
是否有快捷的玩家數據備份和回滾機制？
是否有快捷的服務器代碼熱更新機制？

服務器性能高嗎？
- 方法建議：

有延遲嗎？
是否有預估服務器承載在線玩家人數？
是否有機器人進行壓力測試，模擬玩家正常行爲，併產生測試報告？測試報告是否包含在線人數對應的各進程連接數、內存、CPU使用率、網絡延遲的趨勢圖？
是否通過壓力測試測試出值在線總人數？是否通過日誌記錄各函數的執行次數和平均時長找出性能瓶頸代碼模塊？

服務器穩定嗎？

方法建議：
- 有崩潰嗎？
- 有內存泄露嗎？
- 是否通過測試服務器連續運行7天以上，通過機器人和真實玩家模擬正常遊戲，服務器穩定無卡死和崩潰的情況？
- 是否通過測試服務器連續運行72小時以上，通過機器人和真實玩家模擬正常遊戲，併產生測試報告？測試報告是否包含運行時間對應的各進程內存佔用量的趨勢圖？
- 是否通過日誌記錄各進程、各地圖、各連接引用的對象數量等方式找出內存泄漏代碼模塊？
- 代碼目錄結構是否清晰明瞭？是否在項目根目錄下增加文檔對目錄結構進行清楚的說明？
- 代碼目錄、文件、變量、函數、註釋的命名規範是否統一？
- 對新加入團隊的技術成員，是否一天之內可以快速熟悉項目代碼結構並上手？

服務器有安全漏洞嗎？
- 方法建議：

是否通過防火牆限制了服務器開放端口？數據庫、Redis等是否限制了只能本機或內網訪問？
是否對來自客戶端的網絡連接需要進行認證校驗，並超過一定時間未認證的連接自動斷開？
是否對世界聊天、好友聊天等功能增加服務端CD和MD5強驗證，防止刷消息？
是否對商業化活動、交易、揹包操作等功能檢查服務端代碼邏輯，對參數進行強制檢查，防止刷道具？

服務器對接完整嗎？

方法建議：
- 可以快捷的獲取產品的測試、運營數據並進行產品分析嗎?
- 可以快捷的獲取產品的收入數據並進行對賬嗎？
- 是否按青果大數據後臺日誌規範進行接入，並通過後臺數據測試？

【項目管理】開發階段

團隊開發效率高嗎？

講述你們團隊採用哪些方法確保高效執行，並且通過一些資料、版本規劃和結果來證明。

方法建議：
- 統籌，採用項目統籌文檔的管理方式。
- 量化，採用量化的管理方法，將所有的開發任務進行拆分、分配、追蹤、彙報。
- 溝通，版本和功能進行會議溝通和私下的反覆溝通，通知到位。
  - 是否以周爲單位進行全體會議，同步團隊和項目情況？
  - 是否通過各種會議溝通、單獨溝通對員工進行表彰和批評？
  - 是否不斷的通過會議宣揚團隊文化？
  - 是否有定期的和團隊每一位員工溝通？
  - 是否有通過溝通了解每一位員工的目標追求和成長瓶頸？
  - 是否在發現員工有懈怠和問題的情況下及時進行溝通？
  - 是否在員工主動反饋和提問的時候積極響應？
- 流程，如：引擎更新流程、遊戲更新流程、遊戲合服流程等，並以郵件形式同步。流程圖，制定包括各部門的溝通、對接流程圖。
- 規範，如：文檔/郵件/文件命名規範、項目QQ羣、微信羣管理規範、渠道提審規範。
- 模板，如：日誌模板、會議紀要模板、週報模板、策劃案模板、SVN提交模板、派單管理器下單模板、BUG書寫規範、賬號權限申請模板等等。
- 制度，如：簽字制度、考試製度。
- 檢查項，如：策劃、美術、程序、測試、出包、更新等檢查表。

評估建議：
- 統籌文檔更新和同步頻次（每日3次爲佳）
- 量化拆分的任務數量（任務量越大越細緻）
- 各種會議的溝通頻次（版本會、週會、私下溝通）
- 團隊日均完成的任務數量

研發經驗是否有積累？
- 講述你們在研發積累上做了哪些事情，並用成果展示來證明這些積累的價值

方法建議：
- 研發日誌
- 運營日誌
- 會議紀要
- 郵件流程
- 月度總結
- 項目覆盤
- 向公司內外有經驗、有能力的朋友學習
- 通過以上文檔不斷的提煉總結工作方法
評估建議：
- 用積累的文檔數量評估

【項目檢驗】測試階段

檢驗方法是什麼？
- 方法建議：
  - 進行Checklist列表檢查
  - 美術資源檢查工具
  - 用機器人壓測檢驗服務器壓力
  - 戰鬥力成長檢驗
  - 各渠道上線評審規範檢查
  - 錄屏觀察分析（找小白玩家來體驗遊戲並錄製視頻）
  - 遊戲感受量化分析（爽點統計、訓狗理論、難度曲線、成長曲線、興趣曲線）
  - 用戶行爲數據埋點分析（分析玩家行爲、智能玩家）
  - 遊戲生態數據統計分析（數據分析改進遊戲）
  - 遊戲運營數據統計分析（各項運營指標，如1~90日LTV、1~90日留存、付費率、ARPU、ARPPU、創建、激活等）

測試工作計劃是否合理？
- 方法建議：
  - 工作計劃是否覆蓋了本版本所有待測內容？
  - 工作計劃是否詳細進行了測試需求分析，將版本內容進行拆分細化？
  - 工作計劃是否包含了未在版本內測試工作？
  - 工作計劃是否包含了版本風險分析和解決方案？

BUG生命週期管理是否健全？
- 方法建議：
  - 提交BUG描述是否包含了BUG出現的版本號，操作環境，重現步驟和預期結果？
  - 不規範的BUG描述是否佔據了總BUG的5%以上？
  - BUG平均修復時間是否統計？
  - 是否定期進行BUG彙總總結？
  - BUG總結是否詳盡，是否總結到問題出現的詳細原因，和以後的規避措施？

測試用例完善嗎？
- 方法建議：
  - 用例格式是否統一，是否包含了用例的維護修改記錄，用例相關文檔地址，用例相關人員？
  - 用例是否包含了前置條件，測試步驟，預期結果和用例結果？
  - 用例的覆蓋率是否在95%以上？
  - 測試用例設計是否包含了邊界值，等價類，錯誤推測，場景分析，因果圖等方法？
  - 測試用例是否經過用例評審？
  - 測試用例的可執行性是否高？用例執行步驟描述是否有歧義？執行用例時是否經常需要跳出用例找其他文檔？

測試報告內容是否完善？
- 方法建議：
  - 測試報告格式規範是否統一？
  - 是否可以讓人清晰瞭解到測試執行結果？
  - 是否全面記錄了測試過程中遇到的問題？
  - 所有問題是否在派單管理器上進行記錄？
  - 測試報告是否對版本質量進行了分析？
  - 是否提出了優化版本質量的解決方案？
  - 測試報告是否包含了當前版本的風險分析？
  - 測試報告是否對當前版本遺留問題進行說明和分析？

上線工作準備充分嗎？
- 方法建議：
  - GM後臺的對接
  - 運維後臺對接
  - 準備各種物料內容，例如：遊戲名字、宣傳視頻、十圖設計、各種遊戲iCON、遊戲logo等
  - SDK對接，登錄、充值、廣告、通過率監控、渠道對接
  - 提前在TapTap平臺上線，早點和玩家產生互動。
  - 利用身邊的資源，尋找一些核心用戶玩家來公司體驗遊戲和溝通訪談。

【項目展示】

展示的內容和版本規劃是否一致？（A、完全一致； B、大部分一致； C、少部分一致；D、此處無說明，不清楚；）
- 得想辦法讓參與評價的人搞清楚你的演示和版本計劃是否一致，包括規劃的內容本身以及是否是圍繞核心玩法和體驗進行的
- 方法建議：
  - 在演示之前將即將演示的內容清單羅列，並且和版本規劃對應上；
  - 簡述此次版本如此規劃的原因，讓大家理解；
  - 演示的內容一定是和上面的“設計解說”以及“版本計劃”是一致的；
  - 演示內容一定要真實呈現出這些內容和遊戲核心玩法和體驗的一致性；
  - 針對羅列的清單簡述已完成的內容進展；
  - 上面標記顏色的是重中之重，重要的事情說三遍！

演示過程是否順利？（A、非常順利；B、出了點小問題；C、耽誤大家太多時間了；D、沒有演示；）
- 爭取整個演示過程一氣呵成、清晰直觀，沒有任何的拖沓。
- 方法建議：
  - 提前準備好資料，提前準備好ipa和apk包，多準備幾部手機；
  - 在演示之前提前去會議室演練一遍，將各種可能導致演示失敗的問題都模擬一遍；
  - 預備一套演示方案；

【用戶體驗】測試階段

你感覺很好玩嗎？

方法建議：
- 全場表達不要出任何問題，一氣呵成！
- 展現的內容清晰直觀；
- 直奔主題，將遊戲自身的特色充分表達；
- 展示超高品質又符合開發需求的內容
- 從用戶體驗的角度出發，遊戲的開發和展示圍繞“爽點”來進行呈現和表達；
- 使用對比法，將當前的進展和過往的或者競品的內容進行品質對比；
- 讓現場評價者一起參與互動；
- ……等等

玩起來爽嗎？
- 方法建議：
  - 角色、場景、UI、模型、特效等設計都很精緻嗎？
  - 遊戲的特色非常鮮明，與衆不同？
  - 音樂、音效品質高嗎？
  - 劇情文字精煉、有趣嗎？故事有吸引力嗎？
  - 遊戲整體體驗足夠流暢嗎？
  - UI操作反饋絲滑嗎？
  - 戰鬥操作手感舒適嗎？
  - 不像一眼就看出來是氪金遊戲吧？
  - 是否有強烈的樂趣感？