如何寫好遊戲系統策劃案？

寫在前面的話：

文件（策劃案）是幫助策劃沉澱想法，管理者評估和對接人執行的依據，是策劃行使權責的證據，具有不可替代的價值。因此除非“敏捷開發”思想下先做後補文件的工作流，其餘情形均需寫文件。

而策劃可以藉助通用模板統一格式，降低閱讀成本，更能形成一種工業化的思考流程，將系統的全貌思考清楚，以此保證系統品質的高下限。同時隨著經驗增長，策劃可將需注意的點補充完善進模板，從而提高自己思考的深度和廣度。

而在文件之前，策劃最好將備選方案寫在XMind思維導圖上（設計案），與上司確定最終方案後再寫正式文件（執行案）。根據系統規模，設計加執行案花費的參考時長如下：

• 小型系統（紅點，公告，選角，設定等）2-3天；
• 中型系統（抽卡，商城，技能等）5-7天；
• 大型系統（交易行，自由捏臉，裝備框架，戰鬥框架等）1-3周，甚至更長。
  

時長包含與上司確定最終方案並返回修改所消耗時間。根據專案進度，系統方向可能轉變，策劃需及時同步到文件中，並標註修改日期。

• 注意1：文件重要的是思考得出的具體方案而不是字數/措辭或格式，勿喧賓奪主。
• 注意2：文件更注重功能的最終效果，實現方式推薦弄清楚但不強求。
  

文件的開頭：

記錄文件的修改情況，方便自己對比修改內容。


模板的正式內容：

一、總覽

1.1 設計目的

此係統存在的目的，需要策劃站在遊戲大方向上客觀評價該系統對遊戲體驗/目標玩家/自家專案產生了什麼作用或意義。

舉例：1）XX系統在特定條件下能給玩家帶來某體驗，符合專案大方向的需要，比如新增每日資源玩法，利用隨機buff選擇功能降低其他日常單一刷圖的枯燥感。或者當前遊戲環境存在問題需要需透過XX系統改進，如大世界跑路太麻煩需要新增便捷傳送功能，對戰卡牌競技場套路單一需引進ban/pick機制等。

2）付費玩家關卡體驗容錯太低，為降低其挫敗感增加付費復活機制。或者MMO里老服務的新玩家需要限時的成長補償機制來跟上大部隊進度等。

3）滿足專案組的KPI需要，如為了增加收入/拉新/迴流/維持市場熱度而新增輪換的運營活動等。

（注意：設計目的不涉及遊戲內的具體概念，以防文件閱讀者不理解或撰寫者沒思考清楚大方向）

另外，目的能生效需要遵循設計前提，即做方案時絕對不能違背的標準。分為兩類：

• 專案要求：專案已成立的結論和上司對系統設計的總體要求。比如專案定位輕度大眾化，所有功能規則都需要簡單明瞭避免抽象並高度符合直覺。或上司認為方案一定要在市面上找到原型，則設計目的就需要考慮已有成熟案例。
• 專案型別的設計原則：不同遊戲型別鼓勵和避免的點不一樣。比如給MMO制定玩法就需鼓勵玩家社交組隊獲得的收益高於單人體驗。或動作競技遊戲型別需考慮怎樣讓玩家主動相遇併發起衝突，或是對局失敗後有途徑轉移挫敗感。
  

1.2 系統概述

• 簡略描述幫助閱讀者快速瞭解方案是什麼，分為幾個階段（最好有粗略的流程圖），但不包含細節描述。
• 該方案是因為什麼才可以達到設計目的。
• 如果系統有改動，分段闡述捨棄，保留，新增了哪些設計，改動原因和日期。（為方便對比，過往所有的記錄都不能刪除）
  

*粗略的流程圖：只列舉功能拆分為哪幾個基礎模組（橙色方塊）和旗下的子功能（紫色方塊），並展示基礎模組和子功能的流程關係。舉例如下：


1.3 系統定位

此係統在遊戲整體框架上扮演怎樣的地位，它的出現會對其他系統產生哪些影響（比如出一個資源流轉圖）。系統定位更多從系統資源迴圈和玩法體驗上著手，並使用遊戲內的具體概念進行闡述。舉例：為達到刷裝體驗有起伏有驚喜不枯燥的目的（設計目的），新增裝備屬性隨機功能（具體方案），其屬性強度上限高下限低，玩家擊敗精英怪獲得，平均機率為中低強度，低機率獲得上限（系統迴圈中的定位），體驗上為假隨機有保底機制，給予玩家一段時間內的強度加速體驗。（玩法體驗上的定位）

系統定位由設計目的分解和推導而來，是實現目的的具體落地方案，單獨開一欄是為了讓撰寫者和閱讀者審視方案是否可以達成目的。比如：ACT遊戲中設計夥伴助戰系統的其中一個目的是新增養成線延長遊戲壽命，那麼系統定位上就要思考夥伴是第幾重要的養成點，屬性給多少，資源如何流轉，其養成節奏，玩法體驗是怎樣，對玩家遊戲目標是否會造成衝擊，不同付費的玩家獲取的方式是怎樣等諸多在遊戲環境中的具體問題。如果邏輯衝突，閱讀者能很快發現從目標到定位的推導有問題，需要修改。

1.4 名詞解釋

對程式/美術/其他策劃可能看不懂的術語或詞彙進行解釋，以幫助其閱讀文件。需注意名詞儘量控制在個位數。

舉例：【隨機裝備】含有最多4條隨機詞條的裝備，擁有獨特的物品貴重等級。強度定位上下限與通用綠裝持平，上限較高相當於金裝，但出現率低。

【系統】：由不同獨立部分組成的，並且能夠相互聯絡和協作的一個有明確輸入和輸出的整體。

【功能】：組成系統的，對系統完整運作產生影響的獨立部分。

1.5 擴充規劃

一般指以下幾點，如沒有可以不寫：

• 系統往往不是一次性做完，如果有迭代計劃可以寫在這，標註大致啟動的節點日期。
• 該系統需要配合哪些配套功能可以更好地實現設計目的，但暫時無排期計劃的，可列出功能名稱，概述和原因，以供閱讀者參考。
• 該系統是否有備用方案，如有則可以簡單提及名稱，概述和原因，僅供閱讀者參考 。
  

二、功能實現

2.1 詳細流程圖

將概述中拆分好的所有模組分解為最小單位的子功能，並以前後流程的形式展示。此張大的流程圖包含前後端要處理的所有邏輯，便於程式把握功能整體。（注意：外部功能與本系統的聯動也需要用虛線標出來，例如跳轉至某個介面）

2.2 基礎模組一

2.2.1 子功能一

簡潔敘述此功能的大致流程和規則，並貼出該功能的UI介面或UE互動圖，需標註數字序號。

如果有多張介面圖，需標註相互之間的跳轉關係。


2.2.1.1 開啟規則

• 此模組的開放/結束的時間點：玩家角色XX級/具體年月日/某個前置系統的變化如任務完成等。
• 功能開放持續時間：部分系統或玩法會有時間限制，從X時到Y時結束。
• 開放/重新整理/重置頻率：部分系統或玩法每天/周/月/永久開啟/限制使用X次。
• 位置和表現：UI或NPC入口在哪，是否有開放預告功能，開放時是否會有特效動效過場等展示。
  

2.2.1.2 介面元素規則

• 數字標識處的前端功能的定義和詳細規則：介面元素的排序優先順序/重新整理時機/運作流程/計算公式等。
• 該資料的獲取途徑：表格/寫死/玩家輸入；初始資料填什麼，完整資料的預期效果如何。
• 極端狀態下的處理情況和對應的介面顯示：空態/有資料時的普通狀態/封頂狀態。
• 不同尺寸終端的適配規則：一般為四周貼邊，非四周居中。
• 前端效能需求：在妥協後的美術表現下的FPS最低幀數；多人同屏是否自動隱藏其他人以平衡效能等。
  

2.2.1.3 特殊規則

系統在特殊或極端情形下的固定規則，以避免BUG或塑造更好的體驗，只能靠策劃積累的經驗來定奪。

• 組隊狀態：單人劇情關卡，有玩家未解鎖時的處理方法，獎勵如何分配；進入關卡前有不滿足條件的成員處理方法；組隊狀態被邀請參加其他事情等。
• 離線狀態：斷線處理或重連機制，資料如何恢復；疊加組隊狀態下各成員狀態怎麼顯示。
• 特殊激勵：首次通關時的額外獎勵，玩家執行某個行為會有彩蛋內容等。
• 容錯率：玩家在誤操作比如誤點選離開關卡按鈕後需要二次提示；脫離卡死；揹包容量不夠後獲得的獎勵放入郵件等功能；策劃填表有錯誤ID如何提示；加入公會設定冷卻時間防止重複領取獎勵等。
• 與其他系統的聯絡：系統之間相互關聯，某個系統狀態的改變可能會引起其他系統的BUG，寫文件時需提前對可能發生的問題給出解決方案。比如：公會有排行榜，如果公會解散則排行榜需要立即撤下其排行並對排名進行重新整理，如果沒考慮到則解散時可能公會仍停留在榜單上，但是顯示名稱為undefined。
  

2.2.1.4 後端需求

涉及資料的來源，儲存和流轉，有餘力可以考慮清楚（出現BUG時可以更快定位），沒空時也可全權交給後端安排。部分專案需要策劃案前後端需求分開，可按需求將流程圖分別做一份前端的和後端的。

• 資料的流轉：該系統中，資料在前端的哪個階段傳送給伺服器。顯示時，前端在何時收到後端資料，如果沒收到資料，介面該如何顯示。
• 資料的儲存：該資訊儲存在客戶端還是伺服器；資料來源是什麼，是否需要做驗證；資料儲存的最大條數，資料溢位時的處理方法。
  

2.3全域性功能需求

系統存在一些共同的功能需求，推薦在做每個系統時都逐個思考檢視一遍，完善系統體驗。

2.3.1 紅點需求

某種情況下，需要在以下介面如圖處增加紅點，以提醒玩家執行某種行為。

注意紅點屬於負反饋，與遊戲核心收益相關的部分可設定，其餘可不加或使用視覺上弱化的橙點。

2.3.2 便捷功能

• 引導玩家認知的功能。檢視道具時的【獲取來源】資訊；幫助玩家決策的資訊【99個1級寶石可合成X個5級寶石】；檢視相關係統資訊時的【跳轉介面】按鈕；重要決策時的【二次確認】按鈕等。
• 預測玩家行為的功能。選擇數量時的【MAX】；副本中的【再次挑戰】或【下一層】；缺少材料時的【快捷購買】；領取多個獎勵時的【一鍵領取】等。
  

2.3.3 新手引導

需要引導玩家操作的部分寫在這。推薦核心系統使用強引導（必須點選正確位置才能觸發下一步），次要設定使用弱引導，玩家主動點選時才觸發引導，一般為圖文介面。

2.3.4 行為監測

• 為防止BUG的條件檢測。如進入關卡前的揹包容量檢測，隊友網路訊號強度等。
• 新舊賬號資料衝突時的相容性處理。
• 特殊資料的異常值檢測。比如移速，視距，CD等容易開掛修改的屬性，可觸發反外掛手段；亦或者每日資源獲取上限，如果超過臨界值時需鎖定收益並提醒專案組。
  

2.3.5 控制開關

• 程序開關：運營活動或玩法類常見，能在緊急狀態時（運營事故/不可抗力/重大BUG）關閉功能的顯示或可互動性，甚至可以強制中斷使用該功能的玩家行為。
• 功能開關：系統給到玩家不同體驗的可選項，一般統一放在設定介面中。比如MOBA型別的智慧/手動施法切換，MMO的是否自動播放世界頻道的語音訊息等。
  

2.3.6 後端資料打點

本功能的哪些資料在什麼情況下需要在後端記錄。一般是有：

• 驗證功能中使用率，玩家留存情況，方便專案組驗證設計的情形。
• 監控伺服器特殊資源產出的多少，並在超過上限時提供預警，方便排查BUG。
  

2.3.7 智慧排序

所有表格中有字串輸入的地方推薦增加自動排序，常見的有高品質物品在前，低品質在後。表格ID從小到大等。此類自動排序可避免手動填錯，根據實際情況可選擇是否引用此功能。

2.3.8 Tips提示&公告

此功能有某種技巧或者功能需要玩家知道，一般顯示在loading介面中。

玩家的某種行為可觸發公告，並顯示在世界聊天頻道/跑馬燈播報/手機推送資訊中。

2.3.9 GM命令

輸入指令可方便測試系統全貌的功能。

三、資料庫

功能需要哪些表格，表格之間如何關聯，表格中每個欄位的含義是什麼，都可以在這裡看到。

功能總表：XXXX；模組和子功能表格：XXXXX


四、其他策劃需求

4.1 系統：設定需求

一般是新增道具的需求，及舊道具如何修改。


4.2 數值：產耗需求

• 產出：產出道具的種類/爆率/獲得限制等，及不同付費的玩家的標準獲取量。
• 消耗：回收道具的途徑種類/消耗量和時間分佈情況，及不同付費的玩家的養成曲線等。
• 屬性：功能產出的角色屬性強度收益；敵人的屬性強度等。
  

最後貼出數值配套詳細文件地址：XXX

4.3 關卡&戰鬥：玩法需求

• 敵人角色：怎樣的形象，什麼數量，需要怎樣的技能，爆出的東西是關卡給還是怪物獨立掉落。
• 場景和互動物：需要多少關卡，其尺寸和承載的戰鬥大致體驗是什麼等。
  

最後關卡配套需求文件地址：XXX

4.4 文案：描述需求

系統如何與遊戲劇情大綱/世界觀設定結合起來，包括：系統名稱和文字；背景故事；道具概念包裝；相應角色和場景等。

五、美術需求

美術需求欄位寫多少取決於美術團隊的地位，以及合作者是否希望加入自己的設計想法，可靈活增減美術需求點。如果策劃沒有太多美術基礎建議全權交給美術團隊，只寫名稱/需求和參考圖。


六、驗收進度表


七、遊戲或資料引用

展示撰寫人方案的原型，方便閱讀者審查或溯源，也可以擴充其他策劃的思路。有時間的話推薦寫寫，可積累閱歷。

示例：功能原型來自——《暗黑破壞神3》萃取系統：

萃取”功能是透過消耗日常任務材料，將特定裝備的特殊效果詞條轉變為玩家被動技能的過程。玩家最多可在3個不同部位上攜帶其中一種效果。（最新版本取消了部位限制）。該功能幫助當時的遊戲環境擴大build的組成思路，並縮短了新角色前中期打寶過渡的時間。

寫在後面的話：

模板的最終意義是幫助策劃思考得更加全面，希望大家多多積累，不斷完善自己的思維，做出質量上乘的作品。


來源：遊戲設計研究所