終點，也是起點
隨著《BOOOM 賞玩會特別節目》 這期推出，今年的 Booom 暴造活動算是正式落下帷幕。對於我來說，這次，也是第一次參加 Booom 的經歷給我留下了很深刻的印象。在這趟旅程的結尾，我想在此衷心感謝所有玩家的時間、機核的各位老師給出的評價以及我們團隊的另外兩名成員所付出的努力！
因此，我想通過本文來複盤我們的項目 《The Revolver》 從零至一的開發過程，從走過的彎路到踩過的坑，以及我們從中所學到的最重要、最寶貴的經驗與收穫。
《The Revolver》 是一款不那麼一樣的第三人稱射擊遊戲。在遊戲中，玩家需要磨練自己換彈的熟練度，配合自己的瞄準能力，最終通過所有關卡。
Link： The Revolver | 機核 GCORES
概念階段 | Concept Phase
今年 Booom 的主題相較於往年更簡約——前綴“RE” 。在得知活動的主題後，我們便進行了頭腦風暴。由於線上協作的需求，我們選擇使用 MIRO 作為我們這次項目的主要協作工具。選擇 MIRO 主要有兩個原因：一方面基於小型團隊規模，我們不想使用過於重型和繁瑣的項目協同工具；另一方面，MIRO 在我的工作中也被大量使用到，它的靈活性以及易用性留給我很深的印象。
本次項目中團隊的 Miro Board
我們的團隊包括我在內由 3 名成員組成，都是入行不久的遊戲人。遊戲自我們的學生時代起便在我們的生活中佔據了重要的部分，而作為一個十分喜歡射擊遊戲類型的我，在畢業後也十分幸運，能夠進入一家知名的公司，並且做自己喜歡的第一人稱射擊項目。
因此，在看到 “RE” 這個主題後，我的腦海中第一個出現的詞就是 “Reload” ，換彈。在經歷了若干輪討論後，我們覺得基於這個想法，可以衍生出一個比較有趣，並且完整的玩法；同時，我們也突然發現，左輪手槍， Revolver，恰巧也是以 RE 作為 Prefix，進而聯想到西部牛仔對決的畫面。
在大多數射擊遊戲中，換彈一直是一個簡化的過程，往往玩家只需要在鍵盤或者手柄上按下一個按鍵便可完成。而從擬真的角度考慮，遊戲中的換彈顯然少了那麼一點意思。這就要說到一個另我印象很深刻的設計，來源於遊戲《逃離塔科夫》：不同於傳統的射擊遊戲，玩家在遊戲中除了需要考慮射擊的目標之外，還需時刻主意自己的彈藥管理，若是出現需要填充空彈夾的情況，甚至需要等待子彈一發發 Reload 的過程於時間。
Brain Storm
在想法確定後，我們則快速進入了項目管理和規劃的階段。在遊戲的開發管線中（特別是歐美的遊戲開發管線），通常會具有幾個階段：Concept，Pre-production，Production，and Release。各個階段有各自的交付目標，基於此便可以設置對應的里程碑（Milestone），配合 Sprint 開發模式進行開發。
針對這一套開發模式，可以參考：
- 網站： How We Make Games | Ubisoft
- 書籍：《Game Design Workshop》（書籍，《遊戲開發夢工廠》）
Project Management
預製作階段 | Pre-production Phase
在預製作階段，我們密切配合去製作各種 Mockup（小樣）來驗證我們的想法，確定遊戲最核心的交互與 3C。下方的圖片展現了我們從最開始的草圖，到 Editor 內使用粗糙模型做的 Placeholder，再到最終遊戲內的效果圖的過程。
Pre-production Process
預製作階段最重要的目標就是確定遊戲核心，而最有效的便是交付垂直切片（Vertical Slice）。垂直切片就像是蛋糕中的一小塊，雖然內容量不大，但是卻包含了蛋糕的每一層；換言之，我們通過垂直切片來表現遊戲最核心的玩法流程。
製作階段 | Production Phase
進入製作階段後，核心玩法流程已經確定。在這個階段，我們基本上以擴展關卡的數量，提升素材的質量以及打磨整體的遊戲品質為主。 隨著關卡製作的推進，整個遊戲變得越來越完整和清晰，然而隨之而來的還有大量的 Bug 以及問題。
Production Process
製作遊戲看上去很美好，但是...
開發遊戲過程中，只有 5% 的時間你會感到順利，而剩下的 95% 的時間你會感到 “IT SUCKS” ，—— 往往那 5% 發生在項目的最開始，而後者卻是常態。
我曾經看到過這樣一句話，已經忘記是在何處看到，而這句話卻深刻的記在我的腦海裡揮之不去。每一個新項目的開始，往往總是興奮的，彷彿有無數的創意從腦海裡迸發而出，而隨著項目的開發，創意的驗證，很多問題會不斷暴露出來，以至於讓我們懷疑自己，甚至放棄。
其中一個壓力源，來自於項目本身。例如我作為遊戲設計師，在設計過程中往往會面臨無數的設計決策（Design Decisions）需要被確定。例如，我們是否需要將遊戲做成實時戰鬥？是否要做成自動瞄準？要給予玩家多少的子彈？每一發子彈的傷害應該如何確定？等等。隨著項目的深入以及系統的數量，這些設計問題會越來越多。
另一個壓力源在於預期與結果的對比。在我們的開發中，由於一些客觀情況，如工作壓力，線上協作以及日常的突發事件等等，很大程度上都在打亂我們的開發規劃。若對比我們每個階段的最終交付日期和當初計劃的日期，它是這樣的：
項目管理管線最大的敵人就是開發規劃與實際的開發能力偏離，最終造成項目的拖延，甚至失敗；而顯然，我們的項目管理離優秀還差很大的一段距離。為了趕上項目提交的最後日期，我們只能砍內容，我相信這也是很多團隊遇到過的經歷。
設計與開發的反思
- 儘早，併合理地確定項目範圍 核心系統宜少不宜多
- 項目範圍（Project Scope）確定了項目的大小，需要考慮到項目目標，自身能力，客觀條件限制等情況。在我們這次的項目開發中，一個 “3D 射擊遊戲” 對比我們的開發帶寬來說，其體量過於龐大，以至於在項目後期我們感到開發十分乏力——系統很多，但是來不及優化和打磨
- 儘早進行 Playtest 驗證核心玩法，絕大部分時間留給打磨
- Playtest 能夠收集更多的反饋與數據，並及時進行設計方向上的調整。結合第一點，能夠儘早地做出可玩版本並給玩家進行測試。
- 在開發的過程中，最大部分的時間應該留給 Production 階段。而在這次開發中，我們留給 Production 的時間反而是最短的。而由於項目範圍過於龐大，這就導致了我們後期對於打磨的內容量難以掌控。
- 不要以自身去預設玩家的體驗
- 從我自身來說，豐富的射擊遊戲經驗在設計上帶來了難度認知偏差，即：將自己的體驗預設為玩家的體驗。因此，儘早的測試十分重要，而測試玩家的類型也需要做特定的篩選和分類。
- 以記錄的形式追蹤每一個任務，Bug 和反饋
- 由於我們這次設計的系統數量並不少，因此在開發的過程中探索一套合理且規範的項目管理體系，去追蹤這些任務顯得尤為重要。然而，我們號稱自身追求敏捷和快速，卻忽略了項目追蹤的重要性。項目敏捷度不單單是減少某些工作，而應該是追求一種更合理和更有效的開發管線 —— 我想這也只能在一次次踩坑中總結別迭代吧。
- 創建中文遊戲標題
- 參加國內的 Game Jam 活動，一箇中文的遊戲標題非常重要。下圖是一個很明顯的例子，英文標題在眾多遊戲中會嚴重增加玩家的理解難度：
風雨過後才見彩虹
正是有了開發地獄（Development Hell），才能凸顯出看到成果後的寶貴。我想，每一個完成的作品背後，都是經歷過風雨的開發者。而在他們背後，總會有一道彩虹指向目標的遠方。
最後，無論各自的彼岸何在，一起加油吧。