遊戲企劃必修課：如何寫好「系統企劃書」？

「企劃的企劃書」系列

今天來聊聊遊戲企劃新人最想知道的問題。

「遊戲企劃書究竟該怎麼寫？有範本或規定嗎？」

這個系列就讓我們來聊聊遊戲企劃該如何「寫企劃書」還有「開需求」吧。

哈利波特裡的「怪獸的怪獸書」筆者一直很想要收藏一本（笑）

企劃是什麼？企劃書又是什麼？

一樣還是從最根本的定義來討論。

所謂的「企劃」，指的就是在「實施手段，達成目的」前，一系列設計和研擬的動作。

例如規劃旅遊路線，或是思考如何行銷產品、安排活動節目等，這些都是企劃的一種。

而「企劃書」存在的目的，在於「溝通」，也就是如何「把達成目標的過程，拆解並分析給實作的人吸收」。

因此，根據「溝通的對象」，企劃書的內容和形式會有很大的不同。

在遊戲設計師的實際工作範圍中，大概會碰到幾種不同的企劃需求。

• 高層設計/高層概念（HLC，High Level Concept）
  （或稱HLD，High Level Design）
  高層設計的閱讀受眾是「投資人」。
  所謂高層設計是指在實作階段之前，一種概念性的系統整理，通常會包含例如「產品定位」、「市場調查和市場戰略規劃」、「實作可能性評估」、「成本評估」等等，簡而言之，就是老闆會想在研發產品之前看到的報告書。所謂的 Pitching（計畫彙報）就是類似的概念，設計者或產品供應商會向金主們報告產品內容，吸引他們挹注投資。
  在遊戲設計中，HLC 通常是用來明確核心玩法、客群和市場定位，一般來說是由製作人或主企劃負責，對整個遊戲產品定義大方向的初期企劃書。
• 系統設計（功能企劃案/企劃書/功能需求）
  系統設計的閱讀受眾是「執行者（通常是工程師）」。
  撰寫系統設計的需求是企劃最常遇到的，常見的「功能需求案」、「遊戲企劃書」之類的其實都是系統設計需求。
  設計師需要在系統企劃書內詳述系統的規則和需求，讓工程師和其他職能有辦法按照設計製作出遊戲產品。
• 表現設計（表現案/表現需求/界面和UI動效需求）
  表現設計的閱讀受眾是「執行端美術人員」或是「客戶端工程師」。
  有些時候表現設計需求會被整合在系統需求內，但遇到大型系統或是大量美術需求的時候，表現規格書就需要獨立出來。
  交互設計師設計的動畫特效、系統界面的按鈕與流程、或是遊戲內的「圖標」等需求，就是由表現設計文件來規範的。
  例如筆者以前參與的專案中，一個完整的系統就由兩個企劃負責設計，一個撰寫系統需求，一個撰寫表現需求，分別和工程師以及美術人員對接，專門追蹤進度和提供產出反饋。
• 說明規格書（使用說明書/規格書）
  說明規格書的閱讀受眾是「使用者」，但須留意，在遊戲產品中，這個「使用者」通常不是指玩家，因為玩家的教學內容是放在遊戲內的。這裡的說明書是給「業主」或是「營運方/代理商」看的文件。
  例如業主出資外包給你的團隊，要製作一個完整的遊戲產品，產品完成後交付給業主，這份規格書就是說明遊戲機制、背後的系統內容以及營運工具的操作等等細節的說明文件。
  遊戲研發商授權給營運公司代理遊戲的時候，通常也要附上這類規格書，當然最方便的方法是直接讓研發人員當「人體說明書」到代理公司提供協助。

額外補充

在英文中，計畫（Plan）和企劃/提案（Proposal）是不同的。

Plan 指的是有完善的規劃和目標，可實行的完整內容，也就是針對「How to do？」的設計。

Proposal 則是可以天馬行空，有點像是上面提到的 HLC，不必拘泥在細節，可以自由發想，也沒有嚴謹的格式。是針對「What to do？」的設計。

系統企劃書是屬於 Plan 的範疇，需要有完整的規劃和可實行細節。

從系統企劃書開始說起…

以上這四種，是在遊戲產業中比較常見的企劃書類型。

今天我們要來談的就是最常見的「系統企劃書」，這通常是遊戲企劃最常見的工作內容。

系統案的架構

一般而言系統企劃書大概分為幾個部份：

1. 文件的基本資訊
   包括「文件目的」、「負責人和修改紀錄」、「目錄大綱」等等，其中修改紀錄是相當重要的，文件就跟軟體一樣會有不同的版本，把每個版本更新的內容以及修改人記錄下來，之後有問題才知道要找誰討論。
2. 數值需求（配置表需求）
   這個項目主要是給工程師看的，將功能所需的數據類型和表單列出，方便工程師快速理解整個架構。
3. 系統功能需求
   這是企劃書最重要的部份，需要詳述這個功能的所有需求細節，搭配表格、流程圖等，讓工程師和QA方便實作和測試。
4. 美術表現需求
   是例如「UI」或「特效」、「動畫」等需求。
   也常見美術需求和功能需求一起寫的作法，但個人認為如果內容量比較多，美術需求還是分離出來，或乾脆額外獨立一個文件比較好。
5. Log埋點需求
   電磁紀錄的設計相當重要，連網類型的遊戲，伺服器是不會把玩家做過得事情儲存下來的，需要工程師額外設計紀錄點，例如玩家的登入時間，在遊戲中購買的道具紀錄等等。
   如果沒有事先規劃這塊，就無法掌握玩家的行為，就像一間密室中沒有裝置攝影機一樣，如果發生消費糾紛，就變得很難處理。
   越有經驗的企劃越能在初期就提出完備的Log紀錄方案，省去未來有可能的麻煩。
6. 測試相關需求
   這部份算是額外加分的，主要是簡化測試門檻和增加效率的需求。
   例如添加此系統相關的快捷指令（GM指令），或是針對系統的測試提供更快速的測試方法，像是轉蛋系統，如果需要做反向驗證，是否能提供一次性轉一萬次結果給QA確認的功能等等。
   如果能附上測試用例（TestCase，註一）會更好。
7. 防作弊或資安相關需求
   這個通常是寫在測試需求後面，用來限制相關功能（例如GM指令僅開放給公司內網使用，外網不能執行）等等，或是資料同步類的需求。
   也可以直接寫在系統需求裡面。

註一：測試用例（TestCase）
通常是指測試工程師在正式測試之前，針對要測試的功能範圍、以及研發單位提供的說明文件，整理出來的測試要點。例如針對一個按鈕，測試用例有可能會列出「外觀是否正常」、「互動方式是否正確」或是「點擊後的預期結果」等等，整理好的測試用例能方便後續同一個功能快速測試，或是移交給其他測試員來進行。
在一些研發團隊中，也有看過QA在研發初期就加入討論，和企劃一起撰寫TestCase（或是由企劃負責撰寫）這樣的作法。

以下會以「玩家帳號功能」的製作為範例，來看看功能需求要怎麼開比較好。

「玩家帳號功能」的「系統企劃書」

一、企劃書修改紀錄

修改紀錄大概需要有這些資訊

更新文件的時候，新增的內容也可以先標紅色字，方便辨識，下一個版本修改時，舊版的內容再標回黑色，然後新增的部份再用紅色標出，依此類推，方便讓追加功能的實作程式或美術理解哪裡是新增內容。不然光靠修改紀錄很難快速定位新增需求。

二、功能目標

此系統功能案的目標為

讓玩家可以使用「唯一」的帳號在遊戲中遊玩。

功能點包括：

• 玩家要能在進入遊戲時創立帳號
• 若不創立帳號，可以使用遊客帳號登入遊戲
• 可以使用與社群平台綁定的帳號登入遊戲
• 玩家創立的帳號由UID辨別，角色暱稱可以重複
• 需有違法字元判斷，暱稱不可含有違法字元
• 額外功能：隨機產生角色暱稱的系統

所謂的「功能目標」，有點類似敏捷開發中強調的「User Story」，也就是以使用者角度列出「需要有哪些功能」。
通常提出功能需求的都是製作人或主企劃，然後再由執行企劃或一般企劃實際給出詳細的需求規格。

三、目錄

此處略。

目錄的功能其實是為了讓閱讀者「預先知道文件架構」以及「快速查找對應區塊」時的索引功能，只要能滿足這兩點就可以了。

四、數據需求

篇幅關係，這邊列兩個最簡單的需求。

（數據需求可以參考這篇文章：了解「配置表」）
通常都是直接用表格方式呈現，方便理解。
如果有特殊需求，也都要列在這裡。

五、設計內容

1.功能流程概要

玩家開啟遊戲後，判斷是否已為登入狀態，是的話可以直接進入遊戲。

若沒有登入，讓玩家選擇用遊客帳號或社群平台帳號登入。

簡易版本的功能流程圖

建立帳號時，須符合「字元數量」以及「不含非法字元」的條件。

建立角色暱稱時的判斷流程

2.特殊狀況處理

• 玩家遺失帳號時，如何找回？
• 當玩家正在遊戲，此時另一台設備使用同一帳號欲登入時？
• 當玩家想將帳號與社群平台綁定，但該社群平台已經被綁定時？
• 當玩家想用社群平台登入，但該社群帳號沒有綁定帳號時？
• 帳號從一個設備移轉到另一個設備時？
• 長久時間沒上線，帳號是否做封存處理？
• 非法字元庫的判斷是如何進行的？

設計功能的部份就是將遊戲系統的流程詳細的列出，讓工程師製作時有個依據參考。
更重要的就是「各種狀況的處理」，這些處理方式在企劃書中都要盡量列舉，避免真的出現「例外」，造成系統的不穩定因素。
除此之外，像是軟體報錯顯示的文字、特定時間點的存檔或資料同步等等，以及多人遊戲時多個設備的考量，都盡量要考慮到。

六、UI 與動效需求

界面流程圖

簡易版本的界面流程圖

好的界面流程圖要包含
1.所有按鈕或交互控件的功能解釋
2.界面彈出和收起的動畫類別
3.例外狀況的彈窗等訊息提示
也因為這些內容其實用流程圖不太好表達，現在越來越多企劃或UX設計師是直接用Adobe XD或是墨刀這類輔助軟體，快速建立Mockup模型（點我看解釋），工程師直接看樣品，可以快速理解界面的特效和表現方式，省去溝通的時間。

七、Log埋點

1.玩家登入和斷線的紀錄

玩家登入和斷線的時間、IP和設備別都很重要。第一行為格式，下面為範例。

2.玩家帳號與第三方登入的綁定狀態

筆者並不是很確定第三方的綁定方式，姑且當作是用一個KEY來判斷。

Log紀錄的設計要點就是「你想知道玩家做了哪些事」。
例如營運方會很想知道玩家關閉遊戲前最後一個停留的畫面或功能，作為流失點的判斷。
Log紀錄除了能解決消費糾紛外，對於玩家生態的解析也是非常重要的。營運一款遊戲，需要很多資料來了解玩家的消費習慣和傾向。
因此設計這部份功能時，讓有營運經驗的同仁來處理，能省下很多功夫。

八、測試需求

須額外實作以下功能，方便QA測試。

• 開通GM功能的設備，可以直接登入指定的帳號。方便測試帳號衝突以及帳號找回等功能。
• 快速產生大量隨機帳號，方便做伺服器壓力測試以及提供QA測試帳號。
• 提供一定數量的Google和FB測試用帳號。
• 提供可以直接查看當前帳號UID的功能（部份遊戲是不允許查看的，需要特別給QA一個顯示的地方）

根據測試的需求，有時候會需要提供非常強大的指令或功能，如果這個功能被玩家取得或是不小心洩漏出去，會出現大麻煩，因此在設計時要特別注意。
另外，「用指令測試」還是和「真實情況」會有差異的，畢竟工程師寫的指令和原本的功能邏輯可能是不同的，因此過度仰賴也不是好事，需要妥善規劃測試方式會比較好。

九、防作弊與外掛/資安相關需求

承上一點，關於GM功能和產生隨機帳號的功能，有以下規範。

1. 開通GM功能的設備須做二次驗證，須滿足「設備編號白名單」與「網路環境是公司內網」兩個條件，方能使用GM相關功能。
2. 產生隨機帳號的功能，後台需要能辨識哪些是公司系統自動生成的，而非玩家帳號。
3. 為防止工作室刷錢大量創建帳號，系統須能夠自動辨別流水號類型的暱稱帳號。
4. 為防止消費糾紛，販售帳號等行為，消費者合約內一定要列入相關條目，避免玩家因為交易帳號引起的問題。

除了避免GM工具淪為有心人的武器外，防止「外掛」或是「工作室創造大量帳號」也是很重要的事情。此外數字交易網等遊戲常見的問題也需要一併考量。

範例先到這邊

回歸到一開始的出發點：「企劃書是寫給實作或使用的人看的」。

因此依照專案的需求、實作人員的時間或技術門檻，設計適合的系統就非常重要，這些都仰賴平時的累積和實戰經驗。

當然，如果專案的規模沒那麼大，甚至是單人獨立製作，那這些文檔就可以簡化不少了。只是考量到專案人員的流動或是擴編，平常養成把研發內容記錄下來，也是很重要的喔。

好的，那麼今天就先到這邊。

我是水狼，我們下次見。

也可以到臉書追蹤我喔： 粉絲專頁連結

最後，請多利用我的個人文章列表，會持續更新：

水狼的遊戲設計文章列表