遊戲企劃必修課:如何寫好「系統企劃書」?
「企劃的企劃書」系列
今天來聊聊遊戲企劃新人最想知道的問題。
「遊戲企劃書究竟該怎麼寫?有範本或規定嗎?」
這個系列就讓我們來聊聊遊戲企劃該如何「寫企劃書」還有「開需求」吧。
企劃是什麼?企劃書又是什麼?
一樣還是從最根本的定義來討論。
所謂的「企劃」,指的就是在「實施手段,達成目的」前,一系列設計和研擬的動作。
例如規劃旅遊路線,或是思考如何行銷產品、安排活動節目等,這些都是企劃的一種。
而「企劃書」存在的目的,在於「溝通」,也就是如何「把達成目標的過程,拆解並分析給實作的人吸收」。
因此,根據「溝通的對象」,企劃書的內容和形式會有很大的不同。
在遊戲設計師的實際工作範圍中,大概會碰到幾種不同的企劃需求。
- 高層設計/高層概念(HLC,High Level Concept)
(或稱HLD,High Level Design)
高層設計的閱讀受眾是「投資人」。
所謂高層設計是指在實作階段之前,一種概念性的系統整理,通常會包含例如「產品定位」、「市場調查和市場戰略規劃」、「實作可能性評估」、「成本評估」等等,簡而言之,就是老闆會想在研發產品之前看到的報告書。所謂的 Pitching(計畫彙報)就是類似的概念,設計者或產品供應商會向金主們報告產品內容,吸引他們挹注投資。
在遊戲設計中,HLC 通常是用來明確核心玩法、客群和市場定位,一般來說是由製作人或主企劃負責,對整個遊戲產品定義大方向的初期企劃書。 - 系統設計(功能企劃案/企劃書/功能需求)
系統設計的閱讀受眾是「執行者(通常是工程師)」。
撰寫系統設計的需求是企劃最常遇到的,常見的「功能需求案」、「遊戲企劃書」之類的其實都是系統設計需求。
設計師需要在系統企劃書內詳述系統的規則和需求,讓工程師和其他職能有辦法按照設計製作出遊戲產品。 - 表現設計(表現案/表現需求/界面和UI動效需求)
表現設計的閱讀受眾是「執行端美術人員」或是「客戶端工程師」。
有些時候表現設計需求會被整合在系統需求內,但遇到大型系統或是大量美術需求的時候,表現規格書就需要獨立出來。
交互設計師設計的動畫特效、系統界面的按鈕與流程、或是遊戲內的「圖標」等需求,就是由表現設計文件來規範的。
例如筆者以前參與的專案中,一個完整的系統就由兩個企劃負責設計,一個撰寫系統需求,一個撰寫表現需求,分別和工程師以及美術人員對接,專門追蹤進度和提供產出反饋。 - 說明規格書(使用說明書/規格書)
說明規格書的閱讀受眾是「使用者」,但須留意,在遊戲產品中,這個「使用者」通常不是指玩家,因為玩家的教學內容是放在遊戲內的。這裡的說明書是給「業主」或是「營運方/代理商」看的文件。
例如業主出資外包給你的團隊,要製作一個完整的遊戲產品,產品完成後交付給業主,這份規格書就是說明遊戲機制、背後的系統內容以及營運工具的操作等等細節的說明文件。
遊戲研發商授權給營運公司代理遊戲的時候,通常也要附上這類規格書,當然最方便的方法是直接讓研發人員當「人體說明書」到代理公司提供協助。
額外補充
在英文中,計畫(Plan)和企劃/提案(Proposal)是不同的。
Plan 指的是有完善的規劃和目標,可實行的完整內容,也就是針對「How to do?」的設計。
Proposal 則是可以天馬行空,有點像是上面提到的 HLC,不必拘泥在細節,可以自由發想,也沒有嚴謹的格式。是針對「What to do?」的設計。
系統企劃書是屬於 Plan 的範疇,需要有完整的規劃和可實行細節。
從系統企劃書開始說起…
以上這四種,是在遊戲產業中比較常見的企劃書類型。
今天我們要來談的就是最常見的「系統企劃書」,這通常是遊戲企劃最常見的工作內容。
系統案的架構
一般而言系統企劃書大概分為幾個部份:
- 文件的基本資訊
包括「文件目的」、「負責人和修改紀錄」、「目錄大綱」等等,其中修改紀錄是相當重要的,文件就跟軟體一樣會有不同的版本,把每個版本更新的內容以及修改人記錄下來,之後有問題才知道要找誰討論。 - 數值需求(配置表需求)
這個項目主要是給工程師看的,將功能所需的數據類型和表單列出,方便工程師快速理解整個架構。 - 系統功能需求
這是企劃書最重要的部份,需要詳述這個功能的所有需求細節,搭配表格、流程圖等,讓工程師和QA方便實作和測試。 - 美術表現需求
是例如「UI」或「特效」、「動畫」等需求。
也常見美術需求和功能需求一起寫的作法,但個人認為如果內容量比較多,美術需求還是分離出來,或乾脆額外獨立一個文件比較好。 - Log埋點需求
電磁紀錄的設計相當重要,連網類型的遊戲,伺服器是不會把玩家做過得事情儲存下來的,需要工程師額外設計紀錄點,例如玩家的登入時間,在遊戲中購買的道具紀錄等等。
如果沒有事先規劃這塊,就無法掌握玩家的行為,就像一間密室中沒有裝置攝影機一樣,如果發生消費糾紛,就變得很難處理。
越有經驗的企劃越能在初期就提出完備的Log紀錄方案,省去未來有可能的麻煩。 - 測試相關需求
這部份算是額外加分的,主要是簡化測試門檻和增加效率的需求。
例如添加此系統相關的快捷指令(GM指令),或是針對系統的測試提供更快速的測試方法,像是轉蛋系統,如果需要做反向驗證,是否能提供一次性轉一萬次結果給QA確認的功能等等。
如果能附上測試用例(TestCase,註一)會更好。 - 防作弊或資安相關需求
這個通常是寫在測試需求後面,用來限制相關功能(例如GM指令僅開放給公司內網使用,外網不能執行)等等,或是資料同步類的需求。
也可以直接寫在系統需求裡面。
註一:測試用例(TestCase)
通常是指測試工程師在正式測試之前,針對要測試的功能範圍、以及研發單位提供的說明文件,整理出來的測試要點。例如針對一個按鈕,測試用例有可能會列出「外觀是否正常」、「互動方式是否正確」或是「點擊後的預期結果」等等,整理好的測試用例能方便後續同一個功能快速測試,或是移交給其他測試員來進行。
在一些研發團隊中,也有看過QA在研發初期就加入討論,和企劃一起撰寫TestCase(或是由企劃負責撰寫)這樣的作法。
以下會以「玩家帳號功能」的製作為範例,來看看功能需求要怎麼開比較好。
「玩家帳號功能」的「系統企劃書」
一、企劃書修改紀錄
更新文件的時候,新增的內容也可以先標紅色字,方便辨識,下一個版本修改時,舊版的內容再標回黑色,然後新增的部份再用紅色標出,依此類推,方便讓追加功能的實作程式或美術理解哪裡是新增內容。不然光靠修改紀錄很難快速定位新增需求。
二、功能目標
此系統功能案的目標為
讓玩家可以使用「唯一」的帳號在遊戲中遊玩。
功能點包括:
- 玩家要能在進入遊戲時創立帳號
- 若不創立帳號,可以使用遊客帳號登入遊戲
- 可以使用與社群平台綁定的帳號登入遊戲
- 玩家創立的帳號由UID辨別,角色暱稱可以重複
- 需有違法字元判斷,暱稱不可含有違法字元
- 額外功能:隨機產生角色暱稱的系統
所謂的「功能目標」,有點類似敏捷開發中強調的「User Story」,也就是以使用者角度列出「需要有哪些功能」。
通常提出功能需求的都是製作人或主企劃,然後再由執行企劃或一般企劃實際給出詳細的需求規格。
三、目錄
此處略。
目錄的功能其實是為了讓閱讀者「預先知道文件架構」以及「快速查找對應區塊」時的索引功能,只要能滿足這兩點就可以了。
四、數據需求
(數據需求可以參考這篇文章:了解「配置表」)
通常都是直接用表格方式呈現,方便理解。
如果有特殊需求,也都要列在這裡。
五、設計內容
1.功能流程概要
玩家開啟遊戲後,判斷是否已為登入狀態,是的話可以直接進入遊戲。
若沒有登入,讓玩家選擇用遊客帳號或社群平台帳號登入。
建立帳號時,須符合「字元數量」以及「不含非法字元」的條件。
2.特殊狀況處理
- 玩家遺失帳號時,如何找回?
- 當玩家正在遊戲,此時另一台設備使用同一帳號欲登入時?
- 當玩家想將帳號與社群平台綁定,但該社群平台已經被綁定時?
- 當玩家想用社群平台登入,但該社群帳號沒有綁定帳號時?
- 帳號從一個設備移轉到另一個設備時?
- 長久時間沒上線,帳號是否做封存處理?
- 非法字元庫的判斷是如何進行的?
設計功能的部份就是將遊戲系統的流程詳細的列出,讓工程師製作時有個依據參考。
更重要的就是「各種狀況的處理」,這些處理方式在企劃書中都要盡量列舉,避免真的出現「例外」,造成系統的不穩定因素。
除此之外,像是軟體報錯顯示的文字、特定時間點的存檔或資料同步等等,以及多人遊戲時多個設備的考量,都盡量要考慮到。
六、UI 與動效需求
界面流程圖
好的界面流程圖要包含1.所有按鈕或交互控件的功能解釋2.界面彈出和收起的動畫類別3.例外狀況的彈窗等訊息提示也因為這些內容其實用流程圖不太好表達,現在越來越多企劃或UX設計師是直接用Adobe XD或是墨刀這類輔助軟體,快速建立Mockup模型(點我看解釋),工程師直接看樣品,可以快速理解界面的特效和表現方式,省去溝通的時間。
七、Log埋點
1.玩家登入和斷線的紀錄
2.玩家帳號與第三方登入的綁定狀態
Log紀錄的設計要點就是「你想知道玩家做了哪些事」。例如營運方會很想知道玩家關閉遊戲前最後一個停留的畫面或功能,作為流失點的判斷。Log紀錄除了能解決消費糾紛外,對於玩家生態的解析也是非常重要的。營運一款遊戲,需要很多資料來了解玩家的消費習慣和傾向。因此設計這部份功能時,讓有營運經驗的同仁來處理,能省下很多功夫。
八、測試需求
須額外實作以下功能,方便QA測試。
- 開通GM功能的設備,可以直接登入指定的帳號。方便測試帳號衝突以及帳號找回等功能。
- 快速產生大量隨機帳號,方便做伺服器壓力測試以及提供QA測試帳號。
- 提供一定數量的Google和FB測試用帳號。
- 提供可以直接查看當前帳號UID的功能(部份遊戲是不允許查看的,需要特別給QA一個顯示的地方)
根據測試的需求,有時候會需要提供非常強大的指令或功能,如果這個功能被玩家取得或是不小心洩漏出去,會出現大麻煩,因此在設計時要特別注意。另外,「用指令測試」還是和「真實情況」會有差異的,畢竟工程師寫的指令和原本的功能邏輯可能是不同的,因此過度仰賴也不是好事,需要妥善規劃測試方式會比較好。
九、防作弊與外掛/資安相關需求
承上一點,關於GM功能和產生隨機帳號的功能,有以下規範。
- 開通GM功能的設備須做二次驗證,須滿足「設備編號白名單」與「網路環境是公司內網」兩個條件,方能使用GM相關功能。
- 產生隨機帳號的功能,後台需要能辨識哪些是公司系統自動生成的,而非玩家帳號。
- 為防止工作室刷錢大量創建帳號,系統須能夠自動辨別流水號類型的暱稱帳號。
- 為防止消費糾紛,販售帳號等行為,消費者合約內一定要列入相關條目,避免玩家因為交易帳號引起的問題。
除了避免GM工具淪為有心人的武器外,防止「外掛」或是「工作室創造大量帳號」也是很重要的事情。此外數字交易網等遊戲常見的問題也需要一併考量。
範例先到這邊
回歸到一開始的出發點:「企劃書是寫給實作或使用的人看的」。
因此依照專案的需求、實作人員的時間或技術門檻,設計適合的系統就非常重要,這些都仰賴平時的累積和實戰經驗。
當然,如果專案的規模沒那麼大,甚至是單人獨立製作,那這些文檔就可以簡化不少了。只是考量到專案人員的流動或是擴編,平常養成把研發內容記錄下來,也是很重要的喔。
好的,那麼今天就先到這邊。
我是水狼,我們下次見。
也可以到臉書追蹤我喔: 粉絲專頁連結
最後,請多利用我的個人文章列表,會持續更新: